wolfenstein demo for sega genesis

Announce (tech) demos or games releases

Moderator: Mask of Destiny

Post Reply
gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

wolfenstein demo for sega genesis

Post by gasega68k » Thu Aug 22, 2013 5:25 am

This is a demo of wolfenstein for sega genesis written in asm. Mostly is based on the source code of wolfenstein 3d for PC. (sorry for my bad english) :)

Here is a video of the demo: http://youtu.be/BHtKv_cwgVk


Version b5.5(January 10, 2014):
http://www.mediafire.com/download/lbwpw ... o_b5.5.rar
Version b6(February 1, 2014):
http://www.mediafire.com/download/j9a44 ... emo_b6.rar
Version b6.3(February 22, 2014):
http://www.mediafire.com/download/9zgty ... o_b6.3.rar
Version b7(March 23, 2014):
http://www.mediafire.com/download/lka7j ... f3d_b7.rar
Version b8(April 24, 2014):
http://www.mediafire.com/download/39dit ... f3d_b8.rar
Version b9t(may 19, 2014):
http://www.mediafire.com/download/o24pg ... d_b9t_.rar
Version b10(July 8, 2014):
http://www.mediafire.com/download/5885l ... 3d_b10.rar
Version b10.5(August 21, 2014):
http://www.mediafire.com/download/4794a ... _b10.5.rar
Version b10.6(September 27, 2014)
http://www.mediafire.com/download/qrkz6 ... _b10.6.rar
Version b10.7(October 23, 2014)
http://www.mediafire.com/download/a488w ... _b107_.rar
Version "fv11"(December 11, 2014):
http://www.mediafire.com/download/yzzxb ... d_fv11.rar
Version "fv11fix"(Feb 06, 2015):
viewtopic.php?p=25661#p25661

256 x 144 "Test demo version" (Apr 14, 2017):
viewtopic.php?p=31102#p31102

Latest version (256 x 144) (jun 16, 2018):
viewtopic.php?p=33633#p33633
Last edited by gasega68k on Sat Jun 16, 2018 4:51 am, edited 14 times in total.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Aug 22, 2013 7:40 am

Wow it's really smooth considering the windows size ! Really impressive!
What is the window resolution you used exactly ?
Also it seems you extended blank region to allow more vram bandwidth, which is needed to reach 15 FPS !
It would be awesome to see a complete port of the game :D Keep the great work up !
Last edited by Stef on Thu Aug 22, 2013 9:16 am, edited 2 times in total.

Oerg866
Very interested
Posts: 211
Joined: Sat Apr 19, 2008 10:58 am
Location: Frankfurt, Germany
Contact:

Post by Oerg866 » Thu Aug 22, 2013 7:41 am

Looks extremely playable. Good job!

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Thu Aug 22, 2013 8:31 am

That is really smooth !

Enemies must end up in second layer I guess, or the walls will suffer massive color reduction... but that also means more data to pass and that means lower FPS, at least in 60Hz, 50Hz can give fair bit extra.
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

nolddor
Very interested
Posts: 102
Joined: Sun Jun 02, 2013 1:35 pm
Location: Spain

Post by nolddor » Thu Aug 22, 2013 12:46 pm

Can u upload the rom bin file?

sega16
Very interested
Posts: 251
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Post by sega16 » Thu Aug 22, 2013 3:21 pm

Wow this is amazing shows very smooth awesome programming.

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Aug 22, 2013 5:00 pm

I guess a single plan (and so a single 16 colors palette) can be enough as pixels are always rendered in 2 pixels chunk so you fake more colors (128 actually) by blending these 2 H pixels... We just need to take a good base palette to allow at good representation of the original 256 colors palette.

gasega68k
Very interested
Posts: 141
Joined: Thu Aug 22, 2013 3:47 am
Location: Venezuela - Caracas
Contact:

Post by gasega68k » Thu Aug 22, 2013 8:46 pm

Thanks for all your comments, I've been working on this demo for about a year. I started looking for different techniques raycast, I found the source code for PC but at first I found difficult to do in sega genesis (and some parts did not understand), so I set aside. I started to try some tutorials I found of raycast, but worked with some errors. Then I found a good one that worked perfectly (with a good amount of tables), even faster than this, but not be able to operate the doors. :( This is the link of the source if you want to see it: http://lodev.org/cgtutor/raycasting.html # Introduction

Finally went back to the PC version and succeed in making it work. and after many improvements here it is.

Stef, the resolution of the window is 256 x 128, the full resolution (with edges and hud) is 320 x 176, I intentionally leave
this space (86 lines) to use DMA to transfer from ram to vram, and thus also do not need double buffering, and I have more free space in VRAM.
For the enemies I plan to use sprites layer instead of using the second layer, so will be faster because only visible objects are loaded into VRAM.
But first I will try to use the same layer for objects, will be faster but will be the same colors as the walls.

this is the link to download it:
http://www.4shared.com/rar/lr3GeFn4/wol ... sound.html

I use google to translate this, if you do not understand something it's not my fault. :wink:

djcouchycouch
Very interested
Posts: 710
Joined: Sat Feb 18, 2012 2:44 am

Post by djcouchycouch » Thu Aug 22, 2013 8:52 pm

I'm trying to download it, but I can't find a download button that doesn't require creating an account. I'm blind? :)

sega16
Very interested
Posts: 251
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Post by sega16 » Thu Aug 22, 2013 9:41 pm

^^^ It downloaded just fine for me but if you are still having issues downloaded I uploaded it here http://www.mediafire.com/download/56q1e ... soundb.rar
Also I am still amazed on how well this works.
Edit newer version updated link
Last edited by sega16 on Sat Aug 31, 2013 1:35 am, edited 1 time in total.

TmEE co.(TM)
Very interested
Posts: 2440
Joined: Tue Dec 05, 2006 1:37 pm
Location: Estonia, Rapla City
Contact:

Post by TmEE co.(TM) » Thu Aug 22, 2013 10:10 pm

The ROM runs so great !

http://www.tmeeco.eu/BitShit/WolfMD.jpg

I suggest making the border color same as the HUD border instead of black.
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

kool kitty89
Newbie
Posts: 6
Joined: Thu Aug 22, 2013 9:56 pm

Post by kool kitty89 » Thu Aug 22, 2013 10:17 pm

Stef wrote:I guess a single plan (and so a single 16 colors palette) can be enough as pixels are always rendered in 2 pixels chunk so you fake more colors (128 actually) by blending these 2 H pixels... We just need to take a good base palette to allow at good representation of the original 256 colors palette.
For 16 colors, the maximum number of unique combinations (including 2 of the same color -ie the base 16 colors) would be 136, not 128. Though depending on the palette actually chosen (and the colors trying to be approximated) you can get as few as 64 useful psudo colors. (it's also limited to 120 colors max if none of the base 16 colors is useful -ie the max number of dithered pseudocolors)

Posterising the 256x18-bit VGA palette down to 12-bit and then dithering that to 9-bit (2 9-bit colors blend/accumulate to 12-bit) is a pretty straightforward route for this. Posterizing to 12-bit might actually drop the color count to within practical 16-color dither psudocolor limits too.


Another thing to consider would be using H-scroll with a single pixel shift each frame (shifting back the next frame) as a horizontal blending/blur effect.
In NTSC composite video it wouldn't matter as much since H40 blurs a lot in general (could help even out chroma artifacts though), but would be more important in RGB, S-Video, and PAL composite. (if it was in H32, even NTSC composite wouldn't blend that much)

Since it's running at 1/2 horizontal res anyway, that blur wouldn't hamper physical resolution either. And the stuff in the boarder need not be blended either, just leave that normal.



You could also do like SNES Wolf3D and Doom and use a full res sprite (with separate palette) for the player's hand/weapon while everything else is in the render window. (using single buffering here would give more space to buffer the animated sprites for that into VRAM too)



Also, wow, just 247 kB for this demo. Even smaller than Hard Drivin'. ;)
Last edited by kool kitty89 on Thu Aug 22, 2013 10:21 pm, edited 1 time in total.

kool kitty89
Newbie
Posts: 6
Joined: Thu Aug 22, 2013 9:56 pm

Post by kool kitty89 » Thu Aug 22, 2013 10:34 pm

Stef wrote:I guess a single plan (and so a single 16 colors palette) can be enough as pixels are always rendered in 2 pixels chunk so you fake more colors (128 actually) by blending these 2 H pixels... We just need to take a good base palette to allow at good representation of the original 256 colors palette.
For 16 colors, the maximum number of unique combinations (including 2 of the same color -ie the base 16 colors) would be 136, not 128. Though depending on the palette actually chosen (and the colors trying to be approximated) you can get as few as 64 useful psudo colors. (it's also limited to 120 colors max if none of the base 16 colors is useful -ie the max number of dithered pseudocolors)

Posterising the 256x18-bit VGA palette down to 12-bit and then dithering that to 9-bit (2 9-bit colors blend/accumulate to 12-bit) is a pretty straightforward route for this. Posterizing to 12-bit might actually drop the color count to within practical 16-color dither psudocolor limits too.


Another thing to consider would be using H-scroll with a single pixel shift each frame (shifting back the next frame) as a horizontal blending/blur effect.
In NTSC composite video it wouldn't matter as much since H40 blurs a lot in general (could help even out chroma artifacts though), but would be more important in RGB, S-Video, and PAL composite. (if it was in H32, even NTSC composite wouldn't blend that much)

Since it's running at 1/2 horizontal res anyway, that blur wouldn't hamper physical resolution either. And the stuff in the boarder need not be blended either, just leave that normal.



You could also do like SNES Wolf3D and Doom and use a full res sprite (with separate palette) for the player's hand/weapon while everything else is in the render window. (using single buffering here would give more space to buffer the animated sprites for that into VRAM too)



Also, wow, just 247 kB for this demo. Even smaller than Hard Drivin'. ;)



Edit: wait, that also means this would easily fit into the MCD RAM. :D

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Aug 22, 2013 11:17 pm

kool kitty89 wrote: For 16 colors, the maximum number of unique combinations (including 2 of the same color -ie the base 16 colors) would be 136, not 128. Though depending on the palette actually chosen (and the colors trying to be approximated) you can get as few as 64 useful psudo colors. (it's also limited to 120 colors max if none of the base 16 colors is useful -ie the max number of dithered pseudocolors)
Hey Kool Kitty, nice to see you there :)

I was not sure at all about my 128 number, i always impress me about how i can suck when it comes to simple math calculation. How does you arrive to 136 ? I counted 128 as i just eliminate swapped chunk (01 is same than 10) but as we don't eliminate 00 11 .. FF is does 136 ?
Posterising the 256x18-bit VGA palette down to 12-bit and then dithering that to 9-bit (2 9-bit colors blend/accumulate to 12-bit) is a pretty straightforward route for this. Posterizing to 12-bit might actually drop the color count to within practical 16-color dither psudocolor limits too.
Well i just tested the rom and i have admit the result is really great (and smooth) ! The used palette perfectly fit the original color and i believe we can use it to draw sprites as well without much color issues :)
Another thing to consider would be using H-scroll with a single pixel shift each frame (shifting back the next frame) as a horizontal blending/blur effect.
In NTSC composite video it wouldn't matter as much since H40 blurs a lot in general (could help even out chroma artifacts though), but would be more important in RGB, S-Video, and PAL composite. (if it was in H32, even NTSC composite wouldn't blend that much)
Since it's running at 1/2 horizontal res anyway, that blur wouldn't hamper physical resolution either. And the stuff in the boarder need not be blended either, just leave that normal.
I was thinking about it but it would make the image a bit blurry, no clean edge for walls... What could have be nice is to be able to swap nibbles at each frame and not only shift complete scanline. We can do that by having all even pixels in plan A and odd pixels in plan B then at each frame we change H scroll of both plans to make pixels swap:

Code: Select all

A plan = 0x   B plan = y0

frame 0: scroll A = 0   scroll B = 0  --> pixels chunk = xy
frame 1: scroll A = 1   scroll B = -1 --> pixels chunk = yx
frame 2: scroll A = 0   scroll B = 0  --> pixels chunk = xy
...
That would really blend pixels chunk but ... that require 2x vram update and some extra processing :-( Not really interesting then...
Also, wow, just 247 kB for this demo. Even smaller than Hard Drivin'. ;)
Yeah the size of the rom is surprising, specially when we think there is already some sfx as door with nice quality :)

Stef
Very interested
Posts: 3131
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Aug 22, 2013 11:26 pm

gasega68k wrote: Stef, the resolution of the window is 256 x 128, the full resolution (with edges and hud) is 320 x 176, I intentionally leave
this space (86 lines) to use DMA to transfer from ram to vram, and thus also do not need double buffering, and I have more free space in VRAM.
For the enemies I plan to use sprites layer instead of using the second layer, so will be faster because only visible objects are loaded into VRAM.
But first I will try to use the same layer for objects, will be faster but will be the same colors as the walls.
Thanks for the infos :)
You said you don't need to double buffer, this is because you can upload the whole screen in VRAM in a single frame ? If that is the case i assume you prepare your screen buffer so it is directly organized as tiles so you can ue the full DMA speed to upload in VRAM ? For the objects, i'm pretty sure that using the same layer will be good enough, your palette choice is really nice and with 2 pixels colors blend you have something not far from original colors :)

Post Reply