Genny and 3D

Stef · Post by **Stef** » Sun Dec 17, 2006 8:48 pm

In Silpheed only your ship and ennemy ships are really calculated and draw. The background 3D is just a "movie", all is read from the CD in real time. That definitly not "real time 3D" but a soft of precalculated 3D (i guess the compression format is adapted to the flat rendering).

The segaCD vector chip can transform and deform a bitmap but it is not used to draw flat polygon. In fact it's better to directly do texturing

anyway the vector table initialisation is a pain to calculate, generally we use the sub68k fot that.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Mon Dec 18, 2006 8:46 am

Silpheed is very impressive (I even have original CD but no MCD). Background is FMV for sure, sprites and stuff I'm not very sure if they're generated by MCD 68K or MD 68K. Who has beat that game ? Last boss is difficult (damn, off topic...)

stalepie · Post by **stalepie** » Mon Dec 18, 2006 12:43 pm

TmEE co.(TM) wrote:Silpheed is very impressive (I even have original CD but no MCD). Background is FMV for sure, sprites and stuff I'm not very sure if they're generated by MCD 68K or MD 68K. Who has beat that game ? Last boss is difficult (damn, off topic...)

Silpheed's one of my favorites. I have a friend who had a copy with me, so I got a lot of fond memories of it circa 1993 or whenever it came out. Love the music of level 5. I can hum it right now. No, I could never beat that last boss, but my friend could. I used a cheat to see the ending, rationalizing that I had seen all the final boss (stage) had to offer fair and square. I think Silpheed is a good example of how good artistry masks technical limitations. In the hands of most developers, the FMV backgrounds would have looked bad (Novastorm) or just wouldn't have provided a great experience (Star Blade), yet Gamearts knew what they were doing, and the illusion was almost seamless. I love that game!

(yes, I've come to realize other shooters have much more intricate and innovative gameplay... but it's still fun. Plus it was like the first game in America with spoken cuss words in it! haha ).

Fonzie · Post by **Fonzie** » Tue Dec 19, 2006 2:14 pm

If you render your 3D or scalling by software and per horizontal line, no need DMA fill, just use my method (you'll get 90° reversed picture) to render at fullspeed without making a mad BMP2Tiles calculus... that is the trick.

I just looked at duke nukem and it do exactly same thing as I explained above ... It rank tiles from top to bottom and set a bias of 4bytes between each byte write (it drops the first 4bits) so it renders vertical lines at fullspeed.
Since this method renders picture 90° reversed, they also reversed the bmp data in the rom, exactly like i did in my mode7 demo

Unfortunately for duke, I think they made two mistakes:
-They are not using "half" render trick like Bloodshot/Toystory (it would have required to display sprites using genesis VDP sprites). But the wall rendering is actualy 2times slower than it could be.
-They use 320px width mode, so they don't take advantage of the "TV stretch" of the 256px mode.

Bah, its easy to say "they made mistakes"... But that was just my input.

TmEE co.(TM) · Post by **TmEE co.(TM)** » Tue Dec 19, 2006 2:17 pm

Mistakes... 256px would have been better, but then it would not look and feel like Duke on PC I guess...

Stef · Post by **Stef** » Tue Dec 19, 2006 3:13 pm

Fonzie wrote:
If you render your 3D or scalling by software and per horizontal line, no need DMA fill, just use my method (you'll get 90° reversed picture) to render at fullspeed without making a mad BMP2Tiles calculus... that is the trick.
I just looked at duke nukem and it do exactly same thing as I explained above ... It rank tiles from top to bottom and set a bias of 4bytes between each byte write (it drops the first 4bits) so it renders vertical lines at fullspeed.
Since this method renders picture 90° reversed, they also reversed the bmp data in the rom, exactly like i did in my mode7 demo

Unfortunately for duke, I think they made two mistakes:
-They are not using "half" render trick like Bloodshot/Toystory (it would have required to display sprites using genesis VDP sprites). But the wall rendering is actualy 2times slower than it could be.
-They use 320px width mode, so they don't take advantage of the "TV stretch" of the 256px mode.

Bah, its easy to say "they made mistakes"... But that was just my input.

Some questions, i though the DMA was only capable of transfering word, can it do bytes transfert ? can we choose byte or word for VRAM (depending of the dest address A0 value maybe) ?
Also i though the VDP was just slower in 256 pix mod (lower data rate than 320 pix mode, and lower sprite capabilities)...

Fonzie · Post by **Fonzie** » Tue Dec 19, 2006 5:12 pm

i mean, they render the thing in RAM (or directly in VRAM), just increasing the write adress per 0x4 after each byte write (to ram or vram)... In the case they work into ram, they just DMA the whole stuff to vram with régular word method.

Stef · Post by **Stef** » Fri Dec 29, 2006 10:38 am

I got your point, you just have to do an 90° reversed bitmap then you can blit it by DMA quickly

I should give some tries here.

Stef · Post by **Stef** » Mon Jan 01, 2007 5:47 pm

Well i tried to work on that 90° reversed draw method.
It appears i just can't deal with it because we can't do simple byte write to the VRAM, not by VDP port nor by the DMA.
So i've to render 4 pixels at once. i'll try to find another method to arrange the bitmap in tile.

Fonzie · Post by **Fonzie** » Mon Jan 01, 2007 8:01 pm

Ho, 90° method works with bytes if you work into RAM and then RAM>VRAM using simple DMA.

Stef, I thought a lot about what you said to me "big bit shifting takes lot of 68K cycles", so i investigated and found : One 8 bit shift is slower than 2bytes writting (68K reg to ram).
Bah, it just increased by two my ****7 rendering-speed, I approach 30fps with all sprites moving around

Thx a lot for the tips.

I think i was too focused to do all the stuff inside the 68K registers and then write the result... maybe i read too much the 32x timings documentation

.

Stef · Post by **Stef** » Tue Jan 02, 2007 7:27 am

The 68k isn't of these cpu you have to minimise memory access (no cache penality). You have to take care of the expensive instruction (as bit shift) and unrolling loop help a lot

About the bitmap rendering, ok i understand now, it's just when you're doing it in main RAM.

ob1 · Post by **ob1** » Tue Jan 02, 2007 7:33 am

<OFF TOPIC>
OK you guy. So, we agree : we're 2007, Jan the 2nd, half past eight in the morning, and we're talking about Genny, aren't we ? Guess that's what we mean by "geek".
Happy new year !!!
</OFF TOPIC>
I'd say the 68k isn't penalized by memory access since its CISC root makes possible for him to compute directly on memory !!!
The M68000UM (not the PRM this time), shows the time of each operation. Indeed, big shifting is slow ....

Fonzie · Post by **Fonzie** » Tue Jan 02, 2007 10:49 am

"Guess that's what we mean by "geek". "
Tss tss

Genny programming, geek?

tss tss

"and unrolling loop help a lot "
I see, i only execute 8 instructions in my roll... maybe i should unroll more, thx

Stef · Post by **Stef** » Tue Jan 02, 2007 11:04 am

8 instructions isn't that bad but 16 or maybe even 32 can help

I did 16 for my memory transfert, seems to be a good number !

Shiru · Post by **Shiru** » Wed May 09, 2007 11:28 am

Stef wrote:The 3D level of Toy Story is the most impressive imo. I do want to examine that game :p
The main trick is that they only render half of screen and use vertical flip for the other part, anyway, this is still quite impressive :)

I slightly examined all raycasting games on SMD some time ago, and interesting thing is that Bloodshoot uses same trick. Up/down halfs just slightly alters by different palettes (for example, skull on first door is just palette change).