## 3D on the Sega Genesis is possible

Announce (tech) demos or games releases

Chilly Willy
Very interested
Posts: 2845
Joined: Fri Aug 17, 2007 9:33 pm
r57shell wrote:
Chilly Willy wrote:See, (b^2 + b)x1y1 is multiplying THREE terms, not two. Ditto for the rest.
lol . 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:
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

gasega68k
Very interested
Posts: 139
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
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):

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::)

Stef
Very interested
Posts: 3034
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:
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
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):