Wolfenstein 3D port for CD32

[earok]

Originally Posted by ReadOnlyCat

Thanks!
And the moment I go fetch the sources on the Zone I realize you included a link to the GitHub project on the first post...



Oki, thanks for these details. If it is all C, then all the better, my assembly is way too rusty to be of use for the moment.

I have a bit of work already "planned" on Catacombs 3D which I expect to be very similar technically to Wolf3D so I will first check if anything I thought about for the former can be applied to the latter. No promises on dates though, I have much to do before I even start looking at it.

Haha, I think I never bothered updating the Git after the initial check in..

Catacombs 3D would be interesting

[ReadOnlyCat]

Originally Posted by earok

Haha, I think I never bothered updating the Git after the initial check in..

Catacombs 3D would be interesting

Ah, damn.

Could you put the archive back into the zone? I completely missed it at the time and almost did not touch my computer for a few months so it is long gone now.

[gururise]

Someone with the latest source, could you upload to github? That way any enhancements/changes can be easily managed.

[earok]

Originally Posted by gururise

Someone with the latest source, could you upload to github? That way any enhancements/changes can be easily managed.

Honestly, I made an ugly mess of things, probably not worth bothering with. It might be worth asking BSzili if he'd be kind enough to do a proper port along the lines of what he did for Catacomb 3D.

[eXeler0]

Originally Posted by earok

Haha, I think I never bothered updating the Git after the initial check in..

Catacombs 3D would be interesting

Maybe you've seen the newly produced Catacomb 3d The Descent for CD32?

Link;
http://www.ares-shop.de/product_info...c8umgitkc5t2d5

Edit: Have not seen how well the latest version runs but it uses Akiko for C2P.

Skickat från min LG-H850 via Tapatalk

[stevsurv]

Originally Posted by eXeler0

Maybe you've seen the newly produced Catacomb 3d The Descent for CD32?

Link;
http://www.ares-shop.de/product_info...c8umgitkc5t2d5

Edit: Have not seen how well the latest version runs but it uses Akiko for C2P.

Skickat från min LG-H850 via Tapatalk

Looks quite interesting...

Cd32 Preview-

[ Show youtube player ]

PC dos version as a comparison-

[ Show youtube player ]

No music in the Cd32 version demo!

[eXeler0]

Originally Posted by stevsurv

Looks quite interesting...

Cd32 Preview-

[ Show youtube player ]

PC dos version as a comparison-

[ Show youtube player ]

No music in the Cd32 version demo!

I've seen that one. I meant the latest version played on an actual CD32. :-)

Skickat från min LG-H850 via Tapatalk

[BSzili]

That's a very old video. Here's one I made: [ Show youtube player ]

The biggest performance improvement in Catacomb 3D came from drawing the walls using 68k compiled scalers. They are basically large unrolled loops that spit out textured columns to the screen without calculating anything real-time. The original game used them for the sprites too, but it was self-modifying code which is a big no-no on 020+ with the cache enabled.
Anyway, walls can be drawn at near copy-speed using this method, which would help Wolf3D too, I guess. I could give it a shot if I had the source of the latest version.

[eXeler0]

Originally Posted by BSzili

---cut
Anyway, walls can be drawn at near copy-speed using this method, which would help Wolf3D too, I guess. I could give it a shot if I had the source of the latest version.

Are you talking about PC source wolfenstein.. or say.. AmiWolf..?
Pretty sure NovaCoder uploaded the sources to aminet. :-)

Is there anything that could be added without penalty? How many colors is it currently using?

I just saw a proper Doom port running on a C64 with SuperCPU. They had to do some compromises but its damn impressive nevertheless. Id like to believe a decent wolf3d port on the cd32 isnt beyond reach :-)

Skickat från min LG-H850 via Tapatalk

[BSzili]

There is no concept of colors, the scalers are just copying bytes from one location to another. What I forgot about was that in Wolfenstein 3D the wall drawing is completely different, it's not done using compiled scalers. So much about that.
What would be interesting is to get a hold of the source of the Mega Drive port from gasega68k. He rewrote the whole game from scratch in assembler.

[eXeler0]

Originally Posted by BSzili

There is no concept of colors, the scalers are just copying bytes from one location to another. What I forgot about was that in Wolfenstein 3D the wall drawing is completely different, it's not done using compiled scalers. So much about that.
What would be interesting is to get a hold of the source of the Mega Drive port from gasega68k. He rewrote the whole game from scratch in assembler.

Yea, Megadrive version is crazy impressive. I have no idea how you even do a tiled graphics version of an fps.
"64kB RAM in he Megadrive ought to be enough for everyone? :-)"

Skickat från min LG-H850 via Tapatalk

[earok]

http://aminet.net/package/game/shoot/AWolf3D_src

Might be a good starting point (it's what I used with my aborted attempt). Switching it to use WriteChunkyPixels is easy as it already uses WritePixelArray from memory. There's a few glitches here and there (eg enemy soldiers can kill you dead from a far distance due to using UINTs for the distance calculations), it only supports Shareware edition and it's missing audio but generally seems OK. There's some ASM for wall rendering.

Note that this isn't Novacoder's AmiWolf, he hasn't made his source public as far as I know.

[BSzili]

Originally Posted by eXeler0

Yea, Megadrive version is crazy impressive. I have no idea how you even do a tiled graphics version of an fps.
"64kB RAM in he Megadrive ought to be enough for everyone? :-)"

To be honest tiles are not a whole lot more inconvenient than the chunky to planar conversion. Heck, the VDP tiles are in chunky format AFAIK.

Originally Posted by earok

http://aminet.net/package/game/shoot/AWolf3D_src

Might be a good starting point (it's what I used with my aborted attempt). Switching it to use WriteChunkyPixels is easy as it already uses WritePixelArray from memory. There's a few glitches here and there (eg enemy soldiers can kill you dead from a far distance due to using UINTs for the distance calculations), it only supports Shareware edition and it's missing audio but generally seems OK. There's some ASM for wall rendering.

Note that this isn't Novacoder's AmiWolf, he hasn't made his source public as far as I know.

AWolf3D looks too stripped down, the wall drawing routines are lacking quite a bit. Wolf4SDL is a better base to start, since it's closer to the original sources.
One of the I things that worked well in Catacomb 3D was having most of the screen in planar.
My idea is to have a double buffered native screen and convert all of the 2D graphics to planar bitmaps at load time. This way only 3D view area needs to be C2P'd into the screen. Drawing the non-3D part would be fast, and there would be no need to waste chip-RAM bandwidth by doing C2P for the full screen every frame.

OK, this is interesting. Challenge accepted.

[SteveUK]

Originally Posted by BSzili

My idea is to have a double buffered native screen and convert all of the 2D graphics to planar bitmaps at load time. This way only 3D view area needs to be C2P'd into the screen. Drawing the non-3D part would be fast, and there would be no need to waste chip-RAM bandwidth by doing C2P for the full screen every frame.

OK, this is interesting. Challenge accepted.

This is exciting would this run on stock cd32 at playable speed? With possible cd audio like catacomb? (The 3do wolf had good sound from memory)

[earok]

Originally Posted by BSzili

Drawing the non-3D part would be fast, and there would be no need to waste chip-RAM bandwidth by doing C2P for the full screen every frame.

From memory, the version I was hacking on (AWolf) doesn't do C2P full screen every frame anyway? I thought it only did C2P on the parts of the screen that have changed (eg the 3D view always but it only does C2P on the Score counter when the Score counter has been updated)

Originally Posted by BSzili

OK, this is interesting. Challenge accepted.

Fantastic news can't wait.

Random thing, I had this idea that maybe - assuming the guns could be rendered in 16 colours - the guns could be rendered with sprites for additional speedup, especially considering the AGA chipset supports 64 pixel wide sprites..

..actually probably too hard, considering you'd need a contiguous block of the palette for the gun colours..*shrug*

[BSzili]

Originally Posted by SteveUK

This is exciting would this run on stock cd32 at playable speed? With possible cd audio like catacomb? (The 3do wolf had good sound from memory)

I have no idea who owns the rights to the console ports of the game. The DOS AdLib tracks can be included as CD audio for sure. The rest is too early to tell.

Originally Posted by earok

From memory, the version I was hacking on (AWolf) doesn't do C2P full screen every frame anyway? I thought it only did C2P on the parts of the screen that have changed (eg the 3D view always but it only does C2P on the Score counter when the Score counter has been updated)



Fantastic news can't wait.

Random thing, I had this idea that maybe - assuming the guns could be rendered in 16 colours - the guns could be rendered with sprites for additional speedup, especially considering the AGA chipset supports 64 pixel wide sprites..

..actually probably too hard, considering you'd need a contiguous block of the palette for the gun colours..*shrug*

To me it looks like it C2Ps the whole screen:
https://github.com/earok/AkikoWolf/b.../vi_sdl.c#L172
Even if it did, blitting planar bitmaps would be faster than the generic C chunky blitter + C2P.

I also thought of using sprites for the weapon, but there are too many limitations. The sprite 16-color banks are continuous, starting from a specific palette offset, that's no good. Maybe attached AGA sprites can use 256 colors? Since graphics.library has no support for AGA sprites whatsoever, I have no clue how to program them. The weapons are also upscaled from 64x64 to 128x128, so I'd need two 64x128 sprites. I'd have to keep them in memory too, which might be just too much to fit into 2MB with the rest.

[earok]

Whoops haha.. I thought for some reason I forgot to commit anything to that repository. The wl_draw.c has a few parts where only part of the screen is sent to WriteChunkyPixels (though it seems I've commented most of them out).

I don't think there's any way to make AGA sprites use 256 colours.. so far as I know the only real difference between AGA sprites and Non-AGA sprites is they can be up to 64 pixels wide, so maybe it's just a case of poking the right register? In any case I think you're right that it probably can't be used in any meaningful sense.

It's a shame though.. one of the big slow downs I found with the source I was working with was simply the loop that renders the gun, I got a big speedup by just turning off guns entirely. I came up with some hack compromise where it wouldn't waste so much time just checking empty pixels to see if they needed to be rendered.

[BSzili]

Sure, but setting the attached bit allows you to combine two sprites. On OCS/ECS you can combine two 4 color ones into one 16 color sprite. I would assume the same would work for 16 color AGA sprites as well, you could combine them to get 256 colors.
A less complicated solution would be converting the weapons into planar bitmap bit-plane mask pairs, and using BltMaskBitMapRastPort to draw them over the play area. It would be still faster than the brute-force method.
An other solution is bringing back the compiled scalers for sprites. That would also make other scaled sprites super fast, but to do it without self-modifying code it needs much more memory.

[earok]

Sprites are always 4 colours (16 if attached) whether AGA or OCS. Toni's compiled a good list of the AGA specific features of sprites though I'm unsure if any of them would be any use other than the 64 pixel wide thing - http://eab.abime.net/showpost.php?p=1076544&postcount=4

In regards to the actual possibility of using sprites for the on screen weapons however:
- It appears the sprite sheet for weapons is 88 colours in total (most of the frames alone use around 20-30), so either changing the palette at runtime on the copper or serious dithering would be required anyway.
- *Assuming* the above could be handled in a satisfactory way (and maybe it can't be), even on maximum screen size the gun shouldn't take up than 128 horizontal pixels even when firing Gatlin on full blast. So four sprites in total (2x attached 64 pixel wide sprites) would cover it.

So probably a stretch, but if it COULD be done, you'd get gun rendering with virtually zero CPU overhead.


This is just for my knowledge and curiosity:
- I assume a compiled scaler is essentially an unrolled loop that draws a single column of the image to the screen at a certain size?
- If self modifying code can be used, it essentially allows the scaler to be generated at "real time", otherwise you'd need to generate scalers for every possible size, hence the need for much more memory?
- You want to avoid self modifying code because of difficulties with CPU caching etc?

[BSzili]

The biggest issue with the sprites is that they don't have separate color registers, so I'm limited to 16 consequent palette entries, which may or may not be a good match to the weapon colors. Is it even possible to change just the sprite colors? The more I think about it the more complicated it sounds.

The compiled scalers are large unrolled loops generated for a range of scale sizes (1-MAXSCALE), that draw a single column. You pick a routine for a wall height, set the texture address, the screen column and it spits out the pixels. The issue with sprites is that they can have holes in them. The original game solved this by jumping in at specific offsets, and patching in return opcodes where transparent parts begin. This won't work with the cache enabled on '020 and up.
https://github.com/BSzili/refkeen/bl...3_scale.c#L750

A non-self-modifying version would need extra scalers of varying lengths, one that scales a 64, 63, 62, ..., 2, 1 pixel texture columns. I could still jump in the middle of these, but I wouldn't have to patch in the return opcore and restore it after drawing each segment. If I ever want to do port the Catacomb Adventure Series to the CD32 I'd definitely need to implement this.