Genny and 3D

Shiru · Post by **Shiru** » Fri May 11, 2007 6:00 pm

Stef wrote:The goal is to have a 3D flat engine capable of making game like Starwing (SNES) with acceptable frame rate.

I'm not sure that it is possible for SMD. To make Starfox-like game you need to render many polys per second - same or more than in Virtua Racing, it's about 5000-10000 for 15 fps (minimal acceptable framerate, Starfox has 15..25 fps depending from game situation). And besides of poly rendering, you also need to make some computations - even if you plan to store level as vertex animation, you still need to have collision detection for player/background; player/bullets; bullets/enemy.

Stef · Post by **Stef** » Fri May 11, 2007 6:17 pm

Shiru wrote:
Stef wrote:The goal is to have a 3D flat engine capable of making game like Starwing (SNES) with acceptable frame rate.
I'm not sure that it is possible for SMD. To make Starfox-like game you need to render many polys per second - same or more than in Virtua Racing, it's about 5000-10000 for 15 fps (minimal acceptable framerate, Starfox has 15..25 fps depending from game situation). And besides of poly rendering, you also need to make some computations - even if you plan to store level as vertex animation, you still need to have collision detection for player/background; player/bullets; bullets/enemy.

Starwing is far inferior to Virtua Racing ! less polygone, smaller ones.. it's why i take it as exemple.
When it display larges polygones, the frame rate drop to 15/10 FPS... honestly i thin it's possible to get something close without additional hardware on genesis

5000-10000 polygones by frame ???
i think you surestimate these old game :p
starwing is probably at 100-150 polygones per frame, virtua racing maybe 200-250.

Shiru · Post by **Shiru** » Fri May 11, 2007 7:02 pm

Stef wrote:5000-10000 polygones by frame ???
i think you surestimate these old game :p
starwing is probably at 100-150 polygones per frame, virtua racing maybe 200-250.

5000-1000 per second. Divide by fps, it's only 200..400 for 25fps; 350..650 for 15fps. Only one Starfox ship has ~40 polys; there some ships onscreen, also shots made from some polys each, etc.

Shiru · Post by **Shiru** » Fri May 11, 2007 7:16 pm

About fast flat-shaded poly rasterisation on SMD. I have raw idea, how to make linear frame buffer in VRAM, to speed-up drawing horizontal lines of poly. We must use two BG planes and VSCR. BG buffers must be filled like this (example for only screen line):

BG0: 1010101020202020...
BG1: 0101010102020202...

0 is always transparent tile, 1..X is frame buffer tiles. BG1 shifted 1 pixel up from BG0. Each VSCR column scrolled by 2 pixels up from prev. column (mod 4). So we get line 0 of tile 1 in tileX=0; line 1 of tile 1 in tileX=1; line 2 of tile 1 in tileX=2..

I wonder if it will work, and if so, is it used somewhere?

Fonzie · Post by **Fonzie** » Fri May 11, 2007 8:25 pm

I used it to speed up my mode7 engine ;D It effectively work...
However, I found a better method that consist of rendering the display by vertical lines instead of horizontal lines.

I place the tiles like that in the plane

0 5 10 15 20
1 6 11 16 ...
2 7 12 17
3 8 13 18
4 9 14 19

So, if i write one pixel (byte) and increase the adress per 0x4, i go the next pixel to draw immediately (without bmp2tiles calculus).
So, if you render display verticaly instead of horizontaly, it is very fast.
AND if you add the method you talked about (interlacing planeA & B), you can reach even faster rates

Lol, I "radote", i "radote" but ... seems nobody understand what i mean ^^

And yeah

I think that an engine like F15 Strike Eagle 2 is as good as starfox engine because dawing bigger polygons... Of course, the field of view is still a bit small...

Shiru · Post by **Shiru** » Fri May 11, 2007 8:42 pm

For poly rendering and mode7-like rendering it's better to have linear horizontal-aligned buffer. In case with poly's you'll need bigger min-max buffer (because screen's width bigger than height); in case with mode7-like perspective render (F-Zero, etc) you'll need to do perspective correction each pixel instead of each line.

Fonzie · Post by **Fonzie** » Fri May 11, 2007 9:57 pm

Ha.. true about the screen ratio... But still ^^ I don't know how you can seek & fill faster lines without using the vertical method :/

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sat May 12, 2007 5:00 pm

Maybe use MDs VDP write increment reg ? One freaky idea I had is to put a huge increment value there, and get kind of like linear frame buffer effect...

Fonzie · Post by **Fonzie** » Sat May 12, 2007 5:28 pm

Yeah, but in that case, you must write in words into the VRAM (one word = 4pixels)... And the VRAM access is slowdowned during retrace...

Stef told me to use RAM instead and then , do DMA to VRAM, it is a bit faster than writing imediately in VRAM, nice!

cdoty · Post by **cdoty** » Sun May 13, 2007 4:45 am

I just saw the video of Resident Evil on the GBA (http://www.youtube.com/watch?v=-htyTk-Ij3M&NR=1), I wonder if something like this could be done on the Genesis? It's just a 2D background with a 3d character.

Shiru · Post by **Shiru** » Sun May 13, 2007 9:30 am

cdoty wrote:I just saw the video of Resident Evil on the GBA (http://www.youtube.com/watch?v=-htyTk-Ij3M&NR=1), I wonder if something like this could be done on the Genesis? It's just a 2D background with a 3d character.

GBA has ARM7 @16.8 MHz (32bit RISC), lower resolution, and bitmap videomodes.

And this type of games is slightly complicated than just a 2D background with 3D character. Also note that simplest model of man is ~100 poly (even simpler than in Alone in the Dark). And in RE-type game you need to have >3 characters onscreen.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Sun May 13, 2007 11:56 am

Fonzie wrote:Stef told me to use RAM instead and then , do DMA to VRAM, it is a bit faster than writing imediately in VRAM, nice!

I'll keep that in mind... I'll try to write a raycaster which is based on my 100% QB raycaster that is really $h1tTy, but runs 200FPS on P166...

Shiru · Post by **Shiru** » Wed May 16, 2007 12:22 am

Fonzie wrote:I used it to speed up my mode7 engine ;D It effectively work...

Are you sure that you used same method which I describe? I made some experiments, and seems my idea can't work. It works fine for single line of screen, but it's impossible (seems so, I can't find solution) to make it work for all lines without using 'screensplit' tricks - modifying scroll offsets every line, on HINT. And then it's need to modify whole VSCR table every line, which also seems to impossible, even if 'screensplit' itself is possible on SMD.

Fonzie · Post by **Fonzie** » Wed May 16, 2007 9:56 am

Damn, i thought i already tried your method..; sorry.
Btw, i confirm, with your method, exept a in addition of a complex HINT+VerticalScroll madness, it is not possible to draw more than one horizontal line :/

I thought I did same method because, one time, I interlaced planes A&B in order to write vertical lines of bytes to VRAM (writing words with upper byte set to 0).

Sorry...
Its funny they didn't added a ram mirroring with bmp2tiles adress lines transformation, mad them ^^ (and mad us ^^ LOL)

cdoty · Post by **cdoty** » Fri May 18, 2007 6:23 pm

Shiru wrote:GBA has ARM7 @16.8 MHz (32bit RISC), lower resolution, and bitmap videomodes.

And this type of games is slightly complicated than just a 2D background with 3D character. Also note that simplest model of man is ~100 poly (even simpler than in Alone in the Dark). And in RE-type game you need to have >3 characters onscreen.

The 2D background is stationary, check out the video. All you have to do is DMA the tiles and map. Granted, it changes as you move from area to area, but updating the screen and tiles doesn't have to be done at 30/60 fps.

Rendering the 3D characters to layer B is possibly the only time consuming thing. You may have to mask the character against the background, but a pseudo z-buffer could easily be created with each screen. And, depending on the scene, it could be a simple mask/don't mask bit per pixel.