3D on the Sega Genesis is possible

Announce (tech) demos or games releases

Moderator: Mask of Destiny

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Apr 10, 2014 6:30 am

r57shell wrote:
Chilly Willy wrote:See, (b^2 + b)x1y1 is multiplying THREE terms, not two. Ditto for the rest.
lol :D. b is shift. in our case (16.16) it is b = (1<<16).
For examlple, if x1*y1 = d0 then b*x1*y1 = swap.w d0
so, you have to calculate: x0y0, x1y1, and (x1 − x0)(y1 − y0)
Yes, but only one term uses b, the others use (b^2 + b) and (b + 1). You can break those out into separate shift and adds, but now you're talking multi-precision shifting and adding. You'd really need to write this out in assembly to get an idea for the actual instruction cycle count for the whole routine.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Thu Apr 10, 2014 12:42 pm

I didn't say that it's must be faster. I just said that it's simple.
Check out: http://pastebin.com/UVN8KPXW

Edit: there is problem with calculating (x1-x2)*(y1-y2) or (x1+x2)*(y1+y2) because (x1-x2) can overflow. So here is new version.
http://pastebin.com/E197YnEG
Image

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Thu May 08, 2014 11:28 pm

Hello
Something more than a month ago I was dedicated to improving the code for filling polygons, and also trying to make a new method to make use of DMA to transfer the buffer to VRAM. At first, I thought of doing this just changing the code for filling polygons, but got a way to do it, just changing a little, the code filling polygons and the method of transfer buffer, in this way, the worst case is Like the "normal" method of 628 cycles.
The downside is that to use this method, I have to use the two planes to form the image, so to make the background, I'd have to do it using sprites, another aspect is that you need twice the VRAM memory, but this is not a big problem, because two buffers are typically required, and in this case the buffer is completely transferred in about 100 lines, during forced blanking.
This is how I do it:
As I said, I use the two planes, then the tiles are ordered as follows: tile0 = planA, tile1 = planB, Tile2 = planA, tile3 = planB ... etc, from left to right and down.
Then AutoInc reg is set to 32 when using dma to be transferred, thus four pixel of each tile is drawn, and one of the two planes is moved -4 pixels (with scroll), and thus a continuous line from left to right is obtained, and to transfer the buffer completely, it is divided into 8 blocks of 2560 bytes.
Using this method, a continuous line equal to the "normal" method is achieved, and only need to change a bit codes to draw textures, lines and polygons, at least in my case only using small tables.
I made two videos to show the differences between the "normal" method and the method using DMA, (of course with the DMA method has no background):
https://www.youtube.com/watch?v=YUZpF2JLF4s
https://www.youtube.com/watch?v=oHLc0AzD85g

Here are the roms starfox3d demos of both methods (both use hint and have the code for faster filling polygons), also in the file I included the previous version to compare::)
http://www.mediafire.com/download/2guav ... 3d_new.rar

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Fri May 09, 2014 6:59 pm

Again, that is really impressive gasega68k ! You finally found a way to use the DMA to transfer the 3D rendering buffer without too much modification on the rendering code itself. The draw back is that it requires to use 2 plans to work but that i not surprising... It would be nice to use sprites instead of one of the plan to keep one for the background but then you won't be able to display any HUD. Hehe anyway having 30 FPS with some polygons displayed on screen is definitely a impressive result.
On my side i tried to rework my 3D rendering code, restarted it severals time but honesty i was not satisfied with the result (barely better in some case but code was more complex !). So i think i will stick with the older one and just make some minors tweaks on it ;) Still i am far away from your results with DMA !

Mills
Interested
Posts: 34
Joined: Fri Apr 11, 2014 11:09 pm

Post by Mills » Sun May 11, 2014 11:02 am

gasega68k wrote:Hello
Something more than a month ago I was dedicated to improving the code for filling polygons, and also trying to make a new method to make use of DMA to transfer the buffer to VRAM. At first, I thought of doing this just changing the code for filling polygons, but got a way to do it, just changing a little, the code filling polygons and the method of transfer buffer, in this way, the worst case is Like the "normal" method of 628 cycles.
The downside is that to use this method, I have to use the two planes to form the image, so to make the background, I'd have to do it using sprites, another aspect is that you need twice the VRAM memory, but this is not a big problem, because two buffers are typically required, and in this case the buffer is completely transferred in about 100 lines, during forced blanking.
This is how I do it:
As I said, I use the two planes, then the tiles are ordered as follows: tile0 = planA, tile1 = planB, Tile2 = planA, tile3 = planB ... etc, from left to right and down.
Then AutoInc reg is set to 32 when using dma to be transferred, thus four pixel of each tile is drawn, and one of the two planes is moved -4 pixels (with scroll), and thus a continuous line from left to right is obtained, and to transfer the buffer completely, it is divided into 8 blocks of 2560 bytes.
Using this method, a continuous line equal to the "normal" method is achieved, and only need to change a bit codes to draw textures, lines and polygons, at least in my case only using small tables.
I made two videos to show the differences between the "normal" method and the method using DMA, (of course with the DMA method has no background):
https://www.youtube.com/watch?v=YUZpF2JLF4s
https://www.youtube.com/watch?v=oHLc0AzD85g

Here are the roms starfox3d demos of both methods (both use hint and have the code for faster filling polygons), also in the file I included the previous version to compare::)
http://www.mediafire.com/download/2guav ... 3d_new.rar
Hey, well done, Do you have any vgm from the starfox theme? I made one myself. I'm not a musician and the song has some transitions missing, but here it is: https://dl.dropboxusercontent.com/u/757 ... rneria.vgm

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Mon May 19, 2014 8:28 pm

Although this method can not have a bacground, at least you can switch to another method by changing the table I mentioned, so the same code can run both methods, just change the table and method for transferring to the vram. Perhaps you could implement something like this in SGDK, Stef. :)
Mills wrote:Hey, well done, Do you have any vgm from the starfox theme? I made one myself. I'm not a musician and the song has some transitions missing, but here it is: https://dl.dropboxusercontent.com/u/757 ... rneria.vgm
Yes, I had made ​​a version that included Corneria theme in .tfd done by Toddo (page 1 of this topic), but thanks anyway. :)

Post Reply