wolfenstein demo for sega genesis

gasega68k · 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)

Stef · 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

Keep the great work up !

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

Looks extremely playable. Good job!

TmEE co.(TM) · 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.

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

Can u upload the rom bin file?

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

Wow this is amazing shows very smooth awesome programming.

Stef · 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 · 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.

djcouchycouch · 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 · 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

TmEE co.(TM) · 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.

kool kitty89 · 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'.

kool kitty89 · 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.

Stef · 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 · 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