Heh, 50 FPS might be a dream for the current system. I modified it to use my USB link adapter (it does about 3-5 FPS) using the link about 1/3 of the time (and VB processing the other 2/3). So even doing no processing, it’d only get ~9-15 FPS. But he may be able to do other optimizations to bump that up.

But even at just a few FPS, that’s is really cool that you can render 3D stuff on the PC and view it in 3D on the VB.

DogP

Yup… I’ll be posting the source code fairly soon… I want to look at getting the raycaster engine working, and possibly do a few small mods to improve both of them… but it won’t be much.

DogP

There used to be quite a few pages that showed how to do it… I can’t seem to find them now, but this one sorta shows it: http://www.allyourbaseonline.com/forum/viewtopic.php?p=184370&sid=b4e0571748c77b918c08baeee173a9e4 . Basically you take a pen, melt the tip, stick it onto a screw head while it’s still melted, let it harden so it forms to the shape of the screw, then turn it like a screwdriver. Let us know how it works out.

DogP

Yeah, I just did everything by drawing directly to the framebuffers. Luckily since a raycaster works by drawing vertical lines, this is VERY efficient on the VB because vertical lines are consecutive bits/addresses in the framebuffer. And for textures, I’d suggest just adding it into the direct screen drawing code to look up what texture it’s drawing and set the proper bits in the framebuffer at draw time.

You may actually be able to trick Affine into creating the textures for you, and then moving them out of the framebuffer before they actually get displayed. This would let the hardware do the texture scaling, and all you’d have to do is copy the framebuffer from that location to the correct place in the framebuffer… but that’d probably be a little more complex and take some tricky coding.

DogP

If you’re interested in a Raycaster you may want to look at GBA Caster… I ported that last year, but it runs REALLY slow because it uses floating point… I started to convert it to fixed point, but screwed something up, then lost interest :-P.

There’s also another one I was looking at just the other day… maybe I’ll try porting it sometime soon (should be a quick job).

DogP

Mama always told me not to look into the eye’s of the sun
But mama, that’s where the fun is.

😉

DogP

Yup… that’s the typical flex cable problem where the cable that attaches the display to the motherboard begins to peel away from the display PCB. Unfortunately there’s no simple fix… the best way I’ve come up with is opening the system up, removing the display, sticking it in the oven to re-melt the adhesive, and reassemble.

It’s not a difficult procedure, except that the typical security bit can’t get to the deepest screws on the VB, so you either need a modified bit, or modify a screwdriver.

I’ve got a how-to on my site: http://www.virtual-boy.org/projectvb/projects/DisplayFix.htm , and if you look at other posts on this forum you’ll see MANY other posts with similar problems, and quite a few of them have had good luck using the oven trick.

DogP

RunnerPack and Fwirt: Yes, there definitely are good uses for OBJs (and I was also going to mention particle effects), and I didn’t mean to imply that they’re useless… I was just making a suggestion that if you’re just starting out, most “beginner” apps/games don’t need to make use of OBJs since they’re typically more complex/difficult to work with, and have fewer well documented examples of using them.

If you’re wanting to use them just for the sake of learning how to use OBJs, or if you have a specific reason that you want to use OBJs, that’s great… and just you bringing this up caused RunnerPack to update the Wiki with some good info… so thanks for that! I just wanted to make sure you’re not making it more complex than you needed to by thinking that BGMaps could only be used for Backgrounds.

DogP

I wouldn’t mess w/ using OBJs yet… BGMaps are easiest to use since you can set up a BGMap of large or small sizes, and move the entire image around by just changing a few parameters. OBJs are kinda a pain as you have to individually handle each 8×8 character, so if you have a 16×16 image in OBJs, to move it you have to individually move all 4 8×8 characters. The real advantage is that you can control many objects individually (1024 IIRC), where if you use BGMaps, you can only have 32 worlds, so it’s inefficient to waste a whole world on very small objects. But if you need less than 32 different things on the screen, and the images are larger than 8×8, then I’d recommend using BGMaps.

One type of game I could see OBJs being useful would be something like Robotron. This would have a lot of small characters (8×8 or less, and more than 32 of them) all individually going their own directions. A game where it wouldn’t be as useful would be something like the TMNT arcade game. This would have relatively few large characters (~64×32 and less than 32 on a screen at a time). That would be much easier to set each Turtle to it’s own world, and use a world or two for the scenery, and use the rest for enemies (it’d be limited to ~25 or so enemies at a time). It’s also inefficient to chunk that many OBJs together anyway, since with a max of 1024 OBJs, a 64×32 character would waste 32 (8×4) OBJs, which is just as limited as using the worlds (max of 32).

DogP

Huh? The first link is a direct link to the file played on the front page ( http://www.vr32.de/intro.wav )… can’t you just download that file?

DogP

I believe this is it: http://www.vr32.de/intro.wav .

Edit: BTW, you can download individual mp3s of various sounds by going to the page of each game, click multimedia, and at the bottom is a section for Audio (like Red Alarm: http://www.vr32.de/modules/games/index.php?type=released&sec=multimedia&id=10 )

DogP

I think it’s all based on votes, so if it looks good in the emulator, and we vote for it, I think it could win 😉 . Of course it’d be nice for it to work on real hardware, but I’m sure there’s not enough differences between the HW and emu that with a little help you couldn’t figure out why it’s not working right on HW.

And really… I hope I don’t win… I’m going to put a lot of effort into this, but my goal here is to release a game people would actually want to play, and if someone else makes something better, then that means hopefully we have two or more new games that people (including me) would actually want to play.

And even though this is a competition, if anyone has any questions or needs any sample code… I’d be glad to help out any way I can. Of course I’m not gonna give out the source to my game, and I’m not gonna write a game for someone else to submit, but I’d be glad to give out skeletons programs to get someone started, or chunks of code to help someone add something specific. I think it’d be really cool to see a bunch of new games pop up… even if they are just simple games.

DogP

I don’t use any floating point anymore… initially I used floating point to get it looking correctly, but then converted it to fixed point to get it running full speed (and all the affine hardware is fixed point anyway). You need one affine table per affine world… the table size depends on the size of the world. And yeah… I use 2×2 bgmaps, although you can use more if you want bigger tracks.

DogP

So is nobody else participating? Does that mean I get 1st, 2nd, and 3rd place prizes for submitting this? 😉

DogP

Yeah, there’s 1KB cache. ROM (with the default wait states) takes 3 cycles, RAM takes 2 cycles, and cache takes 1 cycle… so it’s definitely faster. You could also change the ROM wait states to 1 to get ROM access down to 2 cycles… that would probably be fine since most of the flash ROMs are faster than 100ns (at least the ones that I’m using).

Anyway, for the code, you can either use the asm in the code, or I use a #define and do CACHE_ENABLE and CACHE_DISABLE:

Enable:

asm("mov 2,r1
	ldsr r1,sr24"
	: /* No Output */
	: /* No Input */
	: "r1" /* Reg r1 Used */
	);

#define CACHE_ENABLE	asm("mov 2,r1 \n	ldsr r1,sr24": /* No Output */: /* No Input */: "r1" /* Reg r1 Used */)

Disable:

asm("ldsr r0,sr24");

#define CACHE_DISABLE	asm("ldsr r0,sr24")

So, my code looks like:

CACHE_ENABLE;
while (something)
{
    //do lots of stuff
}
CACHE_DISABLE;

BTW, I believe you need to have the tabs in there (you usually need them in asm), and there’s a tab after the \n in the CACHE_ENABLE line (you can’t do multi-lines w/ a ‘\’ in the newest gccvb without making some changes). I think you can use \t instead of tabs if you’d prefer as well.

Edit: There’s a ‘\’ before the n in the CACHE_ENABLE line (if you quote it in the reply it’s there correctly, but in the post it disappeared).

DogP

I just checked on real hardware… I’m pretty sure the parallax problem is in the emulator since it looks pretty close to perfect on hardware, and obviously bad in the emu.

The VB can do more than one affine transform… how many it can handle before it starts dropping frames… I’m not sure (no more than 32 though, since there’s only 32 worlds, and you can’t do affine on OBJs). Affine stuff can be CPU intensive as well though, since you have to compute the affine table. Simple transformations are quick to compute, but complex transforms can take a long time since multiplication and division take much longer than others, and if you use floating point, that slows it to a crawl.

DogP

Ah… I looked on DT’s site and the newest he has is 0.82.1… I didn’t think to check here. This version works better 🙂 . I’m not sure about the parallax now though… this version does do parallax in affine, but reading the readme he says it’s not perfect… and I’m pretty sure I tweaked it on hardware to look correct. But, it has been a while since I’ve run it on hardware, and I have made a lot of changes since I looked at that specifically, so who knows 😛 .

DogP

Bruno: Which version of Red Dragon are you using? In .38 on my PC I get a very ugly misdrawn track… and Reality Boy .82 crashes when I use multiple Y BGMaps.

I do still have some tweaking to do w/ the camera and kart position, but I’m not sure what you’re explaining… are you talking about the parallax? If so, you need to try it on real hardware… I think the parallax is correct (or at least close)… the emulators don’t do parallax correctly on affine worlds (the track is actually 3D w/ the distant parts further away, and the closer parts closer). In the emulator (at least RB), the entire track is drawn at the same parallax.

DogP

[DogP]

Cool… what enhancements are you planning for Blox 2?

Anyway, here’s the link to my current Kart version: http://virtual.boy.home.comcast.net/VB/kart.zip … I did password protect it, but I guess it’s not a big deal if it gets out… it’s pretty crappy right now, so people that waste their time downloading it expecting a “game” are the ones that really lose out 😉 . That said, please don’t send it to any of the ROM sites… of course a version which will hopefully be much better and playable will released by the end of the competition, which is why I’d like the beta versions to stay just in the VB community. The password is Beta_Kart.

So… anyone else have a preview, or at least want to chime in and say what you’re working on?

Edit: BTW, this doesn’t work properly in the emulators (AFAIK)… it partially displays, and then crashes Reality Boy when you turn a little bit (at least the version I’m running), and Red Dragon doesn’t display the Affine stuff correctly. Plus, there’s audio… so, basically… run it on a flash cart 😛 .

DogP

• This reply was modified 16 years, 8 months ago by DogP.

BTW, I finally got around to adding the resistors for multiple brightness levels on the VGA output, so I made a video showing VGA mode: http://www.youtube.com/watch?v=04urRZjkEr4 . It’s not perfect (still have some bugs to work out), but you can see it does 2D, or 3D w/ shutter glasses or red/blue glasses, and runs at 800×600@100Hz or 50Hz (in case the monitor can’t handle 100Hz).

It still works with the TV, and supports the same shutter glasses or red/blue glasses, although of course the picture on the VGA monitor is much better, especially for anaglyph (since NTSC color bandwidth is so low).

DogP