Genny and 3D

[Shiru]

The 2D background is stationary, check out the video.
...

I know how this type of games work, and I also like Resident Evil-like games and played many of them.

Anyway, SMD has not enough CPU power to render enough poly's for such type of game with acceptable speed. Even without computing and rendering of poly's, you'll need to transfer up to 80KB of data per frame (bottom layer ROM>RAM; top layers ROM>RAM; RAM>VRAM).

Maybe, something between Ecstatica and Ballz is more possible for SMD.

[TascoDLX]

Anyway, SMD has not enough CPU power to render enough poly's for such type of game with acceptable speed. Even without computing and rendering of poly's, you'll need to transfer up to 80KB of data per frame (bottom layer ROM>RAM; top layers ROM>RAM; RAM>VRAM).

You're right about the polys but we can do better with the strategy.

Put the background on a scroll plane and the 3D characters/objects on the sprite plane. All you do is render your objects in RAM in the pattern format and transfer to VRAM. With some clever tricks you can handle masking on the other scroll plane. You will have to manage VRAM carefully.

As for RE2, the character seems quite large and detailed. If you can find reasonable speed by limiting the size and lowering the detail, it could work... in theory, of course.

[evildragon]

All this talk and I keep remembering F22 Interceptor.

Has anyone figured out how that game worked? There's multiple rumors on how it worked.

One goes by saying it uses the 13.4MHz clock and makes the 68k run at that. however, that makes no sense. if it was true, the early model 1's couldn't run then, they can't run over 9MHz..

Another goes by saying the 68k AND Z80 both share the load. But then, how does the music run with the Z80 running double time?

[Shiru]

As for RE2, the character seems quite large and detailed. If you can find reasonable speed by limiting the size and lowering the detail, it could work... in theory, of course.

Can you imagine RE-like game with less details than in 'Alone in The Dark'? Even this game requires 16MHz CPU and 640KB of RAM (and VRAM on PC is in CPU address space).

[Shiru]

One goes by saying it uses the 13.4MHz clock and makes the 68k run at that. however, that makes no sense. if it was true, the early model 1's couldn't run then, they can't run over 9MHz..

If it were true, then game must work very slow under emulators, because '13.4MHz clock' can't be dumped;)

[TascoDLX]

As for RE2, the character seems quite large and detailed. If you can find reasonable speed by limiting the size and lowering the detail, it could work... in theory, of course.

Can you imagine RE-like game with less details than in 'Alone in The Dark'?

I can imagine it would be pretty crappy if that's what you mean. But I did say "in theory" -- in other words: it's possible but who would want to? On the other hand, an Alone In The Dark-like game would be nice.

Even this game requires 16MHz CPU and 640KB of RAM (and VRAM on PC is in CPU address space).

RAM requirements mean nothing.

RAM is used for disk buffers, sound buffers, storing graphics, etc. Stuff that needs to be fetched quickly has to be in RAM because disk access is too slow. The Genesis has the luxury of ROM.

[Fonzie]

I added a fps counter to ze mode7 engine of the death... I'm running at 28-30 fps in single screen mode (6*26tiles display range) and 18-20 fps in splitted screen mode (4*24*2tiles display range).

(includes several 2d objects moving around).
Nobody is a god into optimized physics and other things like that here?
For exemple, just having a good camera fallowing a sprite is a nightmare for me ^^

For exemple, if you have a object_angle value from 0 to 380, and want camera_angle value increasing/decreasing to match the object_angle (typicaly, to have the camera angle fallowing the object angle).
If the object angle is 1 and the camera angle 379, how do you do to avoid camera_angle--; and have camera_angle++; ? whaha, all those things drive me crazy ^^

I'll do a benchmark code of my vertical line drawing technique, i'm still extremely convinced it is the way to go for polygonal drawing.

[TascoDLX]

For exemple, if you have a object_angle value from 0 to 380, and want camera_angle value increasing/decreasing to match the object_angle (typicaly, to have the camera angle fallowing the object angle).
If the object angle is 1 and the camera angle 379, how do you do to avoid camera_angle--; and have camera_angle++; ? whaha, all those things drive me crazy ^^

If I understand you correctly:

Code: Select all

difference = camera_angle - object_angle;
if ( difference < 0 )
  difference += 380;
if ( difference < 380/2 )
  camera_angle--;
else if ( difference > 380/2 )
  camera_angle++;

I think that's right.

[Shiru]

RAM requirements mean nothing.

35KB of RAM for raster buffer in 320x224 mode (28KB for 256x224) is nothing? And if we want to use DMA to transfer raster buffer to VRAM, we need two such buffers in RAM. And if we want to store BG graphics in compressed form, we also need third buffer..

object_angle value from 0 to 380

Why 380? Usually full circle has 360 degree. Or, if we speaking about optimization, 256 or 512 'degrees'.

I'll do a benchmark code of my vertical line drawing technique, i'm still extremely convinced it is the way to go for polygonal drawing.

With this technique it's hard to get full horizontal resolution, and we can fill only 2 pixels in column per write (column will be 2 pixel wide). If we could find a way to make horizontal-linear raster, then we'll be able to fill 4 pixels per write.

[Fonzie]

Why 380? Usually full circle has 360 degree. Or, if we speaking about optimization, 256 or 512 'degrees'.

Sure, it was just for the exemple, it's actualy 512. If you look closer, its even more optimized than you think (see VDP sprite's coordinates limits, it's 512px too), haha ^^

Thx Tasco, I'll try this soon, you know, I coded something very close... stupid me

With this technique it's hard to get full horizontal resolution, and we can fill only 2 pixels in column per write (column will be 2 pixel wide). If we could find a way to make horizontal-linear raster, then we'll be able to fill 4 pixels per write.

It is still possible to get full rez at fullspeed, don't worry (using A&B).

Do you think its important to fill 4pixels per write if you can write one pixel at full speed, if the line lenght isn't so big, i think writting pixel per pixel is faster...
My technique is also compatible with "vram fill" vdp operations, but it's another matter

[Shiru]

Do you think its important to fill 4pixels per write if you can write one pixel at full speed, if the line lenght isn't so big, i think writting pixel per pixel is faster...

Yes, I think so. Don't forget that we also need to 'clear' whole frame buffer each frame, before drawing objects.

If we speak about something Starfox-like, we will have many big poly's on screen (background objects), so 4-pixel fill will be effective.

If we speak about RE-like game without close cam, your method maybe will be effective, although then we need to store background in two planes, so we don't have hardware top-layer (need to draw it in software), and also need to 'clear' (restore parts where objects was on prev. frame) background in two planes.

[Fonzie]

void test0(void)
{
register unsigned short i,j;
register uchar *powerout;
register uchar data;

powerout=(uchar*) &rendered_pic[0];
for(i=0;i<128/4;i++){data=(i&0xF)+((i&0xF)<<4);for(j=0;j<224;j++){*powerout=data;powerout+=4;}}
powerout=(uchar*) &rendered_pic[1];
for(i=0;i<128/4;i++){data=(i&0xF)+((i&0xF)<<4);for(j=0;j<224;j++){*powerout=data;powerout+=4;}}
powerout=(uchar*) &rendered_pic[2];
for(i=0;i<128/4;i++){data=(i&0xF)+((i&0xF)<<4);for(j=0;j<224;j++){*powerout=data;powerout+=4;}}
powerout=(uchar*) &rendered_pic[3];
for(i=0;i<128/4;i++){data=(i&0xF)+((i&0xF)<<4);for(j=0;j<224;j++){*powerout=data;powerout+=4;}}

}

int main(void)
{
short i,j,k;
volatile register ushort *pw;
volatile register uint *pl;
uint timerframes;

pl = (uint *) GFXCNTL;
pw = (ushort *) GFXDATA;

init_gfx1();
fvr_load_tiles(15,16+16,0,hex_tiles);

fvr_set_pal(0,mypal);
fvr_set_pal(1,mypal2);

vtimer=0;timerframes=0;
//PReparing screen
for(i=0;i<32;i++){for(j=0;j<28;j++){*pl = GFX_WRITE_ADDR(0xc000+0x40*j+i*2);*pw=0x8000+i*28+27-j+256;}}

//###################################
//###################################
//Test0, std fullscreen filling
//resolution of 128*224 -> 256*224 (128 vertical lines drawed)
*pl = GFX_WRITE_ADDR(0xc000+0x40*2+10);*pw=0x8000+0x2000+16;k=0;
while(k<400)
{
//Show FPS (calculated approximatively during one second on a 60hz system
if(vtimer>60){fvr_load_tiles(256,256+32*28,0,rendered_pic);*pl = GFX_WRITE_ADDR(0xc000+0x40*3+10);*pw=0x8000+0x2000+15;*pw=0x8000+0x2000+16+(((timerframes)&0xF000)>>12);*pw=0x8000+0x2000+16+(((timerframes)&0xF00)>>8);*pw=0x8000+0x2000+16+(((timerframes)&0xF0)>>4);*pw=0x8000+0x2000+16+(((timerframes)&0xF));timerframes=0;vtimer=0;}
else if(timerframes<0xFFFF){timerframes++;}
test0();k++;
}

Here is a test I did... and yeah... the performance is zuppa low ^^ (7 fps without counting RAM>VRAM transfert)...
It just fill a 128*224 pixel buffer line per line (resized to 256*224 because one pixel => one byte => two pixels).

I have to admit I'm a bit lost... I had way better performance on smaller areas, i'm sorry, i must give up :/

[TascoDLX]

RAM requirements mean nothing.

35KB of RAM for raster buffer in 320x224 mode (28KB for 256x224) is nothing? And if we want to use DMA to transfer raster buffer to VRAM, we need two such buffers in RAM. And if we want to store BG graphics in compressed form, we also need third buffer.

No, using a raster buffer for the whole screen is not realistic. You want to use a smaller buffer for each 3D object. And even if you need a buffer to decompress the background, it's temporary. All the background graphics are loaded into VRAM and stay there until the scene changes -- the background doesn't need updates.

Remember: the background and 3D objects are on separate planes.

If we speak about RE-like game without close cam, your method maybe will be effective, although then we need to store background in two planes, so we don't have hardware top-layer (need to draw it in software), and also need to 'clear' (restore parts where objects was on prev. frame) background in two planes.

Honestly, I don't see why this should be different than any other game. The only difference is that the characters/objects need to be rendered. Otherwise, they are sprites and don't need to overwrite the background (or foreground).

[Shiru]

Remember: the background and 3D objects are on separate planes.

We speak about Fonzie's method of column rendering, which involve both BG planes to reach full horizontal resolution.

[TascoDLX]

Remember: the background and 3D objects are on separate planes.

We speak about Fonzie's method of column rendering, which involve both BG planes to reach full horizontal resolution.

*WE* were speaking of an RE-like game, not a game that requires such a method. Don't quote me unless you mean it.