Wolfenstein 3D port for CD32

[eXeler0]

Originally Posted by 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.

NOT a coder but as a graphics guy I have vague memories about setting palette start offsets for sprite usage. So unless Im way out of line here, couldn't you reserve part of a fixed 8 bit palette for 2d graphics and set a different offset palette start for the various weapons?
(Seems to me Wolfenstein has very little actual palette variation.)



Skickat från min LG-H850 via Tapatalk

[BSzili]

Reserving 16 colors for sprites is the only clean way to do it, the first row with the standard 16 color PC palette looks a prime candidate for that:
http://diehardwolfers.areyep.com/bun....htm#appendixb
There might be some graphics using them, or they could have some special function. In that case remapping is necessary, which would complicates things a bit, especially for sprites. Anyway this is a bit too early, first I need an example C program on how to do AGA sprites.

[Samurai_Crow]

If you can squeeze 15 colors per row of pixels and allocate 2 banks of 15, you can double buffer the sprite palette with the Copper list.

[BSzili]

Ok, I more or less have a clean base to work with. I have two Intuition screen buffers, latched images are drawn with BltBitMap, the fonts are drawn with BltTemplate. I have a continuous chunky buffer converted directly with Akiko with the starting offsets and pitch precalculated.
Now the quest to find fast drawing routines for the 3D portion (walls, sprites, weapon) starts. I gave the original sources another look, and I was wrong, it still uses compiled scalers. In fact it looks quite similar to what was in Catacomb 3D with some extra compacting for the table. First I'll check if I can reuse the code from Catacomb 3D.

edit: Compiled scalers for the walls work now, this is a good start. Wall scaling now works at copy-speed, I got a 50% speed increase from 3 FPS to 6 FPS The huge AsmRefresh function eats up a lot of CPU time. In the original game it was in assembly, hence the name, and for a good reason.

[eXeler0]

Originally Posted by BSzili

Ok, I more or less have a clean base to work with. I have two Intuition screen buffers, latched images are drawn with BltBitMap, the fonts are drawn with BltTemplate. I have a continuous chunky buffer converted directly with Akiko with the starting offsets and pitch precalculated.
Now the quest to find fast drawing routines for the 3D portion (walls, sprites, weapon) starts. I gave the original sources another look, and I was wrong, it still uses compiled scalers. In fact it looks quite similar to what was in Catacomb 3D with some extra compacting for the table. First I'll check if I can reuse the code from Catacomb 3D.

edit: Compiled scalers for the walls work now, this is a good start. Wall scaling now works at copy-speed, I got a 50% speed increase from 3 FPS to 6 FPS The huge AsmRefresh function eats up a lot of CPU time. In the original game it was in assembly, hence the name, and for a good reason.

Interesting..
Do you have a target fps towards which youll optimize against or just make it as fast as you can and see what you end up with, so to speak?

Skickat från min LG-H850 via Tapatalk

[BSzili]

I think 12-15 FPS would be the minimum for this type of game to be playable, the Mega Drive version is in that range. How to get there is anybody's guess, I'll start with stripping down the AsmRefresh function to see what makes it so slow.

[BSzili]

I tried cleaning up the function, I even looked up an older C version which is as lightweight as it gets. It's no good, it's still dog slow, I only got a couple FPS with the actual drawing dummied out.
The SNES and Mac version of the game used BSP trees instead of ray casting, which is said to be faster. Fortunately the Mac version is open source, I'll have a look at how it works.

[eXeler0]

Come on man you can do it, look :-)

http://mashable.com/2016/12/19/wolfe...2#LXT1dcDNCqqs

Edit: (Kind of cheating with a custom CPU in the cartridge, but still ;-)

[BSzili]

Yes, I can reduce the view area to ~160x90 too.

[eXeler0]

Originally Posted by BSzili

Yes, I can reduce the view area to ~160x90 too.

That was actually what I was wondering in post #45 , I think shrinking the view area is a legitimate path to achieving playable frame rates if all else fails. ;-)

Skickat från min LG-H850 via Tapatalk

[Amiga1992]

I think the other trick we can take from that is that the game skips lines to be rendered. Can you draw every two? might look weird on a CRT, but we can try, right?

[BSzili]

Skipping lines in this case wouldn't help since drawing the individual columns is fast, but the horizontal resolution could be halved so the raycaster has less work. Still, it bothers the heck out of me that the raycaster is this slow. I really want to try BSP trees, but I don't have a node builder or the original SNES/Mac levels for that matter.

[Samurai_Crow]

Originally Posted by BSzili

Yes, I can reduce the view area to ~160x90 too.

If you're going that low, you might as well use Copper Chunky.

[eXeler0]

Originally Posted by Samurai_Crow

If you're going that low, you might as well use Copper Chunky.

He said that of course only because as a comparison to the rather puny Gameboy Color resolution :-), but.. yes... As long as we are dealing with the crippled Amigas (i.e. 020 without fast RAM) maybe Copper chunky is the fair enough "Amiga chipset limitation" -way of doing it.
The AKIKO chip never gave more than... what... 25% boost for C2P?

From some old forum post I have these numbers for AGA Copper chunky: 330×256 in (3×2pixel mode)
or 220x256 in (2×2)

I think 220x256 (2×2 pix) sounds acceptable?


Skickat från min LG-H850 via Tapatalk

[Samurai_Crow]

Originally Posted by eXeler0

He said that of course only because as a comparison to the rather puny Gameboy Color resolution :-), but.. yes... As long as we are dealing with the crippled Amigas (i.e. 020 without fast RAM) maybe Copper chunky is the fair enough "Amiga chipset limitation" -way of doing it.
The AKIKO chip never gave more than... what... 25% boost for C2P?

From some old forum post I have these numbers for AGA Copper chunky: 330×256 in (3×2pixel mode)
or 220x256 in (2×2)

I think 220x256 (2×2 pix) sounds acceptable?


Skickat från min LG-H850 via Tapatalk

Sorry, I missed the GameBoy reference. :-)

As for the resolution of non-overscanned Copper Chunky on AGA, the resolution is 160x256 PAL or 160x200 NTSC. I would not suggest doing the bottom panel in Copper Chunky though. Also, if you don't do horizontal overscan, the sprites remain active so you don't need to redraw the hands holding the gun and the palette registers used by the sprites remain completely available.

[BSzili]

I was sarcastic. He sent me a video of a custom written version running on a custom hardware in a tiny, tiny screen. The C2P is as good as it gets, I need fast rendering for the walls.

[Samurai_Crow]

Ok. I get it now. Unfortunately, the Wolfenstein level editor I saw back in the day shows the levels being stored as tile maps.

Will this help? http://www.afadoomer.com/wolf3d/about.html

[eXeler0]

Originally Posted by BSzili

I was sarcastic. He sent me a video of a custom written version running on a custom hardware in a tiny, tiny screen. The C2P is as good as it gets, I need fast rendering for the walls.

You definitely shouldn't see it as a "taunt" but rather as inspiration - that there are other retro enthusiast out there trying to do stuff that has never been done before for no other reason than to prove a point, or "because why not" :-) (like the dude that got Doom running on an HP printer :-)
I want to cheer you on in your efforts!


Skickat från min LG-H850 via Tapatalk

[BSzili]

Don't worry, I wasn't put off by it. In the meantime I found the source code of WolfEdit 2 for Mac, which has a node builder. It's in Pascal, so I either translate it to C so I can include it in the game, or touch it up for FreePascal keep it as a separate utility. We'll see.

[BSzili]

I managed to write a mostly working node builder based on WolfEdit2. It was a good idea to rewrite it, the level format of the DOS version differs quite a bit.
The pushwalls are going to cause some trouble because the console/Mac version has simplified levels, where only one pushwall side is visible to the player. The original DOS version on the other hand has levels where you can see up to 3 sides, some has two pushwalls next to each other, etc.
Then came the horrors, the DOS version of Wolf3D still uses degrees for its angles. The bsp renderer needs to calculate many angles, so before I can do anything I have to switch to BAMS.
What have I got myself into...