Wolfenstein 3D on 68020 14 MHz

[Tigerskunk]

Great job, mate!

[b0lt-thrower]

Wow, amazing! Very well done.

[alexh]

Nice project. Ray of .tSCc wrote a Wolf3d engine in 68k that had decent frame rate @7MHz with planar gfx. He started with the Apple II port.

http://s390174849.online.de/ray.tscc.de/wolf3d.htm

I've wondered why someone didn't try to start from the Atari ST alpha and resource it (or ask for the source) and go from there.

[ Show youtube player ]

[BSzili]

Originally Posted by Tigerskunk

Great job, mate!

Thanks!

Originally Posted by b0lt-thrower

Wow, amazing! Very well done.

Amazing is a bit too generous, since we have Dread now, a valiant effort perhaps

Originally Posted by alexh

Nice project. Ray of .tSCc wrote a Wolf3d engine in 68k that had decent frame rate @7MHz with planar gfx. He started with the Apple II port.

http://s390174849.online.de/ray.tscc.de/wolf3d.htm

I've wondered why someone didn't try to start from the Atari ST alpha and resource it (or ask for the source) and go from there.

[ Show youtube player ]

I'm sure someone has already attempted to get the sources of the ST port in the past. The Mac version is already open source though, and modern compilers generate pretty good code if you pay attention. I was surprised that GCC6 turned my big wall scaler switch/case into a computed GOTO, but I digress. The biggest issue is obtaining the game data, which for the Mac version involves installing it in an emulator, converting the executable MacBinary or AppleSingle/AppleDouble, transferring it to the host machine, extracting the files from the resource fork, etc. The 3DO or Apple IIgs version are much better as they have all the data in a more accessible format, but the sources are not available for their specific version of BurgerLib. The lack of source is not the only reason I went for the PC version, as it's quite different from the console/Apple versions. If someone could get the sources of the 3DO or IIgs versions I'd be open to porting those as well.
Anyway the ST version still uses chunky graphics for the 3D view as the walls and sprites are drawn as columns, the biggest difference is that it uses BSP trees and polygon rasterization instead of raycasting, which is much faster. This is shared with all console/Apple versions of Wolf3D.

[alexh]

Originally Posted by BSzili

The 3DO or Apple IIgs version are much better as they have all the data in a more accessible format, but the sources are not available for their specific version of BurgerLib.

I'm sure you're right. The oldest version of BurgerLib I could find was BurgerLib2 which is part of the 3DO port of Doom.

https://github.com/Olde-Skuul/doom3d...ter/lib/burger

Originally Posted by BSzili

If someone could get the sources of the 3DO or IIgs versions I'd be open to porting those as well.

I get the feeling that the source code is co-owned by multiple companies which is why it has not been released (at least that is what Sheppy wrote). The closest I could find were the Jaguar and 3DO source code for Doom which I'm sure everyone already knows about.

Originally Posted by BSzili

Anyway the ST version still uses chunky graphics for the 3D view as the walls and sprites are drawn as columns, the biggest difference is that it uses BSP trees and polygon rasterization instead of raycasting, which is much faster. This is shared with all console/Apple versions of Wolf3D.

Interesting stuff.

Thanks for all your efforts.

[Amigajay]

Great work on this btw!

A couple of things, this runs 'fine' without any fastram using a CD32 setup via Winuae, which was surprising, obviously window size needs reducing to get half decent fps.

Second thing, when running from a startup-sequence after trying to start game past the 'how tough are you' screen an AmigaDOS screen pops up with 'preloadgraphics new pages 184 freed pages 0' but then i heard a gunshot noise, so once i minimized the window and dragged down the Workbench screen the game appeared behind. Any ideas?

[rothers]

It's interesting to compare this to Wolfenstein running in the Dread engine on an A500.

[ Show youtube player ]

[saimon69]

Need to apologize to Szilard because i came out a bit of a jerk on a youtube thread; the port is interesting and performance is good for using the original engine - this is my public apology

[BSzili]

Originally Posted by alexh

I'm sure you're right. The oldest version of BurgerLib I could find was BurgerLib2 which is part of the 3DO port of Doom.

https://github.com/Olde-Skuul/doom3d...ter/lib/burger


I get the feeling that the source code is co-owned by multiple companies which is why it has not been released (at least that is what Sheppy wrote). The closest I could find were the Jaguar and 3DO source code for Doom which I'm sure everyone already knows about.


Interesting stuff.

Thanks for all your efforts.

I think I tried the 3DO Doom version of BurgerLib many years ago, but it wasn't compatible with the Wolf3D rez files. The format probably changed slightly between the two games as they were published a year apart.

Originally Posted by Amigajay

Great work on this btw!

A couple of things, this runs 'fine' without any fastram using a CD32 setup via Winuae, which was surprising, obviously window size needs reducing to get half decent fps.

Second thing, when running from a startup-sequence after trying to start game past the 'how tough are you' screen an AmigaDOS screen pops up with 'preloadgraphics new pages 184 freed pages 0' but then i heard a gunshot noise, so once i minimized the window and dragged down the Workbench screen the game appeared behind. Any ideas?

The game itself doesn't consume a lot of memory, the main issue is the speed of the Chip RAM. Once I'm done with the sounds I'll add 2x1 Akiko C2P for the heck of it, and try to run it from the startup-sequence. That window is just a bit of debug info I left in by accident, you can suppress it by running the game with "wolf3d >NIL:".

Originally Posted by rothers

It's interesting to compare this to Wolfenstein running in the Dread engine on an A500.

[ Show youtube player ]

Dreadeats the Wolf3D engine for breakfast, no contest.

Originally Posted by saimon69

Need to apologize to Szilard because i came out a bit of a jerk on a youtube thread; the port is interesting and performance is good for using the original engine - this is my public apology

Haha, no worries I didn't take it wrong. After Dread, it's hard to impress anyone, but that wasn't my goal. I'm just trying to get the original game to run on an A1200 at an acceptable speed.

[Amigajay]

Originally Posted by BSzili

The game itself doesn't consume a lot of memory, the main issue is the speed of the Chip RAM. Once I'm done with the sounds I'll add 2x1 Akiko C2P for the heck of it, and try to run it from the startup-sequence. That window is just a bit of debug info I left in by accident, you can suppress it by running the game with "wolf3d >NIL:".

Excellent, cheers

[vroom6sri]

It runs pretty nicely on my A1200 with ACA1230/56. The counter in the top left corner was reading 39/40 consistently even when I put it in 100% full screen.

Great work!

[redblade]

Originally Posted by BSzili

That's already possible as most of the screen uses native (planar) bitmaps. You can render everything save for the 3D view without C2P, i.e. there's no chunky in the menus at all, status bar.
I already measured these, e.g. just the raycaster, ...+walls, ...+sprites, ...+weapon, ...+c2p etc.

I just realized that there's a special case for the walls that can have its own drawing function, so watch this space.

So for testing purposes without doing c2p (chunky to planar conversion), A vanilla A1200 can do all calculations and still dump out 60frames of 256 colours chunky format in a second?

That's interesting especially as the minimum DOS requirements was a 286 640k and VGA. But it doesn't mention what clock speed for the 286 as games after that would mention a 386SX-33 (Day of the Tentacle, Sam and Max). Also the 286 had some high clock speeds (5mhz to 25mhz mentioned on Wikipedia).

Great work by the way, Are you reading the keyboard via IDCMP or is this a non system friendly game to get that extra bit of speed?

[BSzili]

It definitely can't do 60 fps "off-screen" without C2P, as the rendering itself is very CPU-intensive. You can find footage of Wolf3D running on 286 machines, and the speed is comparable to this port. For a smooth framerate you need a 386-DX.
For the the keyboard and mouse I'm using a high priority input.device handler.

[BSzili]

Originally Posted by Amigajay

Excellent, cheers

I did some experiments with the Akiko C2P. It was trickier to implement than I expected because you have to write 4 chunky pixels at once, which got in the way of the pixel doubling. After some trial end error I ended up treating the chunky buffer as a word array, and using some bit twiddling to extend 0xFACE to 0xFAFACECE quickly. Unfortunately the speed is almost the same as the CPU-based C2P, but I'll leave this in the code in case someone wants to experiment with it later.

[Amigajay]

Originally Posted by BSzili

I did some experiments with the Akiko C2P. It was trickier to implement than I expected because you have to write 4 chunky pixels at once, which got in the way of the pixel doubling. After some trial end error I ended up treating the chunky buffer as a word array, and using some bit twiddling to extend 0xFACE to 0xFAFACECE quickly. Unfortunately the speed is almost the same as the CPU-based C2P, but I'll leave this in the code in case someone wants to experiment with it later.

Oh that’s a shame, is the speed the same without fastram too?

Obviously games like Gloom and Doom, even Catacombs improved with Akiko, do you foresee a workaround or is it just the way you are writing to the buffer that makes it too hard to use at the same time?

[Superman]

I have given this a quick test on my A1200 with TF1230 and it runs very nicely. Nice job!

[ Show youtube player ]

[desiv]

That reminds me, a while ago, I picked up a Graffiti board.
There wasn't much support for its C2P implementations, but some.
In some of my testing (which was ages ago using DoomAttack), I know that on my A1200, the "optimized C2P 020" driver ran faster than the Graffiti C2P driver.
(Note: I had my ACA1230/28 by then, so I had some extra CPU speed and FAST RAM)
Of course, that could mean just that the Graffiti driver I had just wasn't very good?
I wonder if it is similar to the reason Akiko C2P is about the same speed in your testing...

[Estrayk]

Originally Posted by desiv

That reminds me, a while ago, I picked up a Graffiti board.
There wasn't much support for its C2P implementations, but some.
In some of my testing (which was ages ago using DoomAttack), I know that on my A1200, the "optimized C2P 020" driver ran faster than the Graffiti C2P driver.
(Note: I had my ACA1230/28 by then, so I had some extra CPU speed and FAST RAM)
Of course, that could mean just that the Graffiti driver I had just wasn't very good?
I wonder if it is similar to the reason Akiko C2P is about the same speed in your testing...

Btw, the indivision mk3 from icomp have native Graffiti support.

[lmimmfn]

Originally Posted by Estrayk

Btw, the indivision mk3 from icomp have native Graffiti support.

Are you sure? It was always mentioned as a "might have that functionality in the future", did Jens ever confirm it?

[Playaveli]

Great work! Congrats on this project. Sound worked fine for me. Around 40-45 FPS.

* bugs:
- Controller won't turn right (keys worked fine)
- After I rebooted my Amiga (1200, Blizzard 1230 MKIV, 128 MB RAM) the game won't start anymore. Screen stays black.

Any ideas?