Genny and 3D
Moderator: BigEvilCorporation
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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.
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.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
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...)
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
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!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...)
(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 ).
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.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.
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.
Last edited by Fonzie on Tue Dec 19, 2006 2:21 pm, edited 1 time in total.
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Mistakes... 256px would have been better, but then it would not look and feel like Duke on PC I guess...
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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) ?Fonzie wrote: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.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.
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.
Also i though the VDP was just slower in 256 pix mod (lower data rate than 320 pix mode, and lower sprite capabilities)...
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, 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 .
<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 ....
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 ....
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).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 :)