The trick of these games is that you just take a 2D image and scale the image based on scanline number. The upper scanlines get scaled less, which produces "distance" and the lower scanlines get scaled more, producing "foreground".
Combine that with fast integer rotation and you've got faux 3d perspective.
(note, everything I know about these modes I learned from a few YT videos)
I think 90's Wacky Wheels is slightly more advanced than that maybe.
The floor is not one bitmap. It's actually a bunch of 32x32 pixel tiles.
There is a byte array map that says what kind of tile goes where.
I've copied this approach here...
I do have a distance to floor array for each scanline though, so it's similar in that respect...
Just thinking about going from 320x200 to 640x400...
If better coding and faster clock works as hopes, should be able to go to bufferless display, like Baggers did for Wolf on P1.
Then, can also think about 5:6:5 encoded graphical elements. So, it's words instead of bytes, not too bad a penalty.
I'm glad to find again two really useful instructions: RGBEXP and MULPIX.
These should allow fast expand to 24 bits and then easy darkening.
We could then work in 24-bit color mode and ditch the palette...
Frame rate up to 37 fps using one cog for rendering with P2 Eval at 250 MHz.
Here's the code.
Did you notice any jitter effects on the display at this lower VGA resolution ?
Besides the 2MHz PFD solution of /10 then *125, you can also get 250MHz with /2 then *25, for higher PFD of 10MHz & less jitter.
Ray, do you have the textures for the demo (or were there licensing issues with them? Would you be so kind as to provide us expected dimensions, other info for them to find alternatives if so)
Thanks a lot for putting the code for this up!
Textures are in zip file. I don't there are any license issues.
The textures are more or less an 8bpp copy of the original.
The only trick is that they all have the same 256-color palette...
Oops. They are not in the zip file... I'll fix that...
jmg: It's actually signaled as 640x480, I'm just putting out the pixels 1/2 as fast and with two copies of each row... A trick to get 320x240 effective resolution.
Frame rate up to 37 fps using one cog for rendering with P2 Eval at 250 MHz.
Here's the code.
Hi @Rayman, sounds great. Had a very brief look but when I get a chance I hope to dig though this code further and try to get my head around it. But just quickly, do you expect the rendering algorithm used is readily amenable to splitting over multiple cogs in order to hit over 60fps, and to also improve frame rate for any lower clocked systems?
Ray, what are you using to assemble this? PNut_v32i is a no go. I fought through the length of variable names, cast several things as floats, but gave up once it was griping about COG IDs.
There is pnut v32j which has more label space. I cannot recall how pnut responded when it ran out of label space so it may possible be the same problem.
Everyone should be using 32j.
Finally was able to combine USB with this so can use USB keyboard's WASD keys to move around!
This took some work... Thanks to ersmith for providing a version of fastspin that works for this (in the zip file).
Moved from pure ASM to Spin + ASM, although the Spin mostly just starts the ASM...
Each driver is in it's own Spin file now.
This still isn't very optimized yet in terms of using more cogs to make it faster. That might be next...
And, of course thanks to garryj for the USB code (and getting it into 1 cog)
I know I've seen this problem before when using this small VGA display... Can't remember if there was a simple fix or if it's just that this display is limited in its abilities. The displays states: 640x480 @ 60Hz.
This version of Chip's spiral VGA code does seem to work:
I'm comparing the code differences, but have not yet diagnosed what would cause this. I attached Chip's code example for review.
Comments
I've attached it to the first post for anyone who may be trying to figure this out...
Ultra Rayman-Kart. *lol*
https://tcrf.net/Proto:Wacky_Wheels/Wacky_Kart
And, the background is only a few pixels tall. That's a big memory savings...
Combine that with fast integer rotation and you've got faux 3d perspective.
(note, everything I know about these modes I learned from a few YT videos)
The floor is not one bitmap. It's actually a bunch of 32x32 pixel tiles.
There is a byte array map that says what kind of tile goes where.
I've copied this approach here...
I do have a distance to floor array for each scanline though, so it's similar in that respect...
If better coding and faster clock works as hopes, should be able to go to bufferless display, like Baggers did for Wolf on P1.
Then, can also think about 5:6:5 encoded graphical elements. So, it's words instead of bytes, not too bad a penalty.
I'm glad to find again two really useful instructions: RGBEXP and MULPIX.
These should allow fast expand to 24 bits and then easy darkening.
We could then work in 24-bit color mode and ditch the palette...
Here's the code.
Did you notice any jitter effects on the display at this lower VGA resolution ?
Besides the 2MHz PFD solution of /10 then *125, you can also get 250MHz with /2 then *25, for higher PFD of 10MHz & less jitter.
Thanks a lot for putting the code for this up!
Cheers,
Jesse
The textures are more or less an 8bpp copy of the original.
The only trick is that they all have the same 256-color palette...
Oops. They are not in the zip file... I'll fix that...
Should be able to compile now with Fastspin.
Notte: For PNut, some labels are too long and have to be shortened...
Hi @Rayman, sounds great. Had a very brief look but when I get a chance I hope to dig though this code further and try to get my head around it. But just quickly, do you expect the rendering algorithm used is readily amenable to splitting over multiple cogs in order to hit over 60fps, and to also improve frame rate for any lower clocked systems?
Only downside is that the code will become harder to follow as improvements are made...
P30=right
P22=left
P46=forward
It's not perfect but if you touch the pin plus 5V and ground all with one hand, it sorta works...
Everyone should be using 32j.
But did get it to work on p123 with pnut after fixing labels and floats...
Ray, time for me to take a look at fast spin
--Terry
Just remove the ".txt"
This took some work... Thanks to ersmith for providing a version of fastspin that works for this (in the zip file).
Moved from pure ASM to Spin + ASM, although the Spin mostly just starts the ASM...
Each driver is in it's own Spin file now.
This still isn't very optimized yet in terms of using more cogs to make it faster. That might be next...
And, of course thanks to garryj for the USB code (and getting it into 1 cog)
VGA basepin set to P0, USB keyboard basepin set to P16.
Top post now has a Spin2+Pasm2 version that compiles with latest FlexSpin.
Now uses scancodes from USB keyboard for movement.
Much smoother and allows multiple keys to be down at same time now...
Ray,
I know I've seen this problem before when using this small VGA display... Can't remember if there was a simple fix or if it's just that this display is limited in its abilities. The displays states: 640x480 @ 60Hz.
This version of Chip's spiral VGA code does seem to work:
I'm comparing the code differences, but have not yet diagnosed what would cause this. I attached Chip's code example for review.
dgately