Oh sorry DogP. I meant Reality Boy, no Red Dragon. Yes I was talking about the paralax, the affine world appears with different viewpoints so its 3D, but the kart appears to be kinda floating or so. It should have the same paralax offset distance as the floor where the tires are touching it. I suppose this is because of the emulator, and if not I suppose it will be very easy to change that paralax because the kart always at the same distance from the viewpoint (so its just a constant value). Anyaw, awesome work. I hope you will make the source code available once you release your work and/or the constest finishes.
Btw, does the VB have enogh power to do a lot of affine transformations? Because if it has it, it would be awesome to have a track made of 32x32 sprites deformed so you can use them as polygons. You could even make a tombraider game like that, with a lot of blocks making a textured 3d world.
[edit] having a closer look at the 3d effect (I use crossing my eyes with RB) it looks like the track comes nearer from far away but suddenly at the high of toads top of the head it start going further way again. Lol, very strange and maybe its just the emulator.
[Edit 2] Ok, it was kinda my fault. I had to swap the displays because I was seeing the image for the right eye with the left eye and so on. So now I see it alright toad appears to be under the track (when you are on the sand you can tell). So he just needs to have to pop out a little bit more :D (if this is not just the emulators fault)
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.
Are you using floating points on you mario kart? And how many matrix do you need to convert a plain sprite into perspective? Ah and how big can the circuit be? Cause there is a size limit on bgmaps, or do you use more worlds for the circuit.
Bruno schrieb: Are you using floating points on you mario kart? And how many matrix do you need to convert a plain sprite into perspective? Ah and how big can the circuit be? Cause there is a size limit on bgmaps, or do you use more worlds for the circuit.
when you load it in red dragon and use its debug features, you'll see that the track is made of 2 x 2 bgmaps.
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 2x2 bgmaps, although you can use more if you want bigger tracks.
Wow, it's been a while since I visited the page. A programming competition huh? Hmm... I might have to start putting some ideas down on paper. (And reading through some documentation.)
Looks like DogP is going to win at this rate.
Just out of curiosity, what if we don't have the hardware to test our software? So for example, it looks great in an emulator, but not so great on the system?
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.
USA
Deutschland
Wow, it's been a while since I visited the page. A programming competition huh? Hmm... I might have to start putting some ideas down on paper. (And reading through some documentation.)
