C64 demo with Doom style raycaster

Link me beautiful

If you are not interested in the demo itself grab doom_workstage.d64 from the link above and run "DOOM C64" inside VICE or on a real PAL machine.
And yes, thats running at 1 Mhz. :)

I expected this to be another Maze War clone, but the screenshot showed a "complex" architecture. However it looked just polygonal with dithered colouring, which is not the same as textured.

Here's a video of the effect in question: http://www.youtube.com/watch?v=ahnU-acuPZU#t=4m15s

And may I ask, is there any difference with this Castle Master video, other than the increased smoothness? Same type of graphics (polygonal, flat shaded), same type of "shading" (pattern filling).

Technically it can be thought as a micro-scale texture mapping, where instead of filling in pixels with the same color you fill in a pattern, but without accounting for angle/distance/perspective: the pattern looks the same at all view distances and angles.

Maes said:

And may I ask, is there any difference with this Castle Master video, other than the increased smoothness? Same type of graphics (polygonal, flat shaded), same type of "shading" (pattern filling)

Its the smoothness.
Remember, we are talking a machine that came out 1982 and that runs at 985 khz, yeah, kilohertz.
And this is a BSP-raycaster engine, much like Dooms, whereas the Freescape engine (Castle Master, The Crypt, 3DCK, ...) uses polygons and can grind to a halt on 8 bit machines if there are too many.

Or you could just port the Build engine.

http://video.google.com/videoplay?docid=-3523656097378023191#

Brilliant

Ooo, I like that per-pixel lighting trick in the last one. Sure, it's on one surface, but still damn cool.

It's impressive how far you can push a machine like that. After watching these kinds of demos I just feel like I completely suck at programming. hehehe

Belial said:

Or you could just port the Build engine.

http://video.google.com/videoplay?docid=-3523656097378023191#

http://vimeo.com/3811256 I LOLed.

I just found this out!

http://www.youtube.com/watch?v=Y7h3H-_8N_o

There were many 8bit attempts in the past to recreate a wolfenstein or doom style engine, few of them tried for fun to be a port of doom (like a wolfenstein engine on ZX Spectrum just with the sprites of Doom) but this one went closer that is so funny. I mean, it's slow and ugly, but the first one that actually tries to resemble the original maps as close as possible. Crazy, even the music, the flood effect when new game starts, the menus, everything. Don't say it's better than other 8bit engines (though it's one of the few with various angled walls) but it's funny and it's VIC20 (16kb of Ram I think).

I always wondered how "low" a proper port of Doom could go with regards to requirements. For a "proper" port I mean one that can use the original resources in their standard formats (perhaps downsized, e.g. smaller maps, or redesigned, e.g. new graphics to better fit with the limitations), and uses most of the original game logic. If you recreate too many resources or end up with too radically different game code, then it borders on being a recreating.

The cut-down measures used on ports such as SNES, 32X etc. are a good indicator. Practically, I think it's impossible to go below 2 MB of addressable combined ROM + RAM space without starting to sacrifice too much, and requiring major re-rewrites. When you're dealing with machines having a bit depth < 8 and planar displays, then even the 1 byte per pixel of the original starts looking wasteful.

Edit: I'm surprised that they chose to use proper scalable "textures" for this minimal port. The ZX spectrum one uses fixed-resolution patterns that never pixelate instead, which IMO look better than ultra-low-res textures, and are probably much faster to render.

I'd like to see someone make an Amstrad port. Looks to me like that should be the goto platform if someone wanted to try a non-butchered 8-bit port.

I now noticed that the VIC20 port uses actual scaled sprites :-o

By comparison, the Spectrum one used pre-scaled sprites at 2 or 3 fixed scale levels, not actual graphics scaling.

As for an Amstrad one, I dunno: due to the way the machine works, it would be closer to the Spectrum than to the C64, so I would expect a port to be virtually identical to the Spectrum one. Not much in the way of sprite scaling etc. but reasonably fast in block transfers, which means that the fixed pattern and pre-scaled sprites method would work better. Certainly, unless a spectrum-like GFX mode would be used, the Amstrad has the potential for prettier visuals (and even palette effects).

As an aside, I'd always thought Doom on the SNES would've worked better as a rail shooter. It just didn't have the juice for the whole thing.

Belial said:

I'd like to see someone make an Amstrad port. Looks to me like that should be the goto platform if someone wanted to try a non-butchered 8-bit port.

Amstrad port would be great. Everyone is begging me to do it :P

About two years ago I tried to make a wolfenstein engine. In this one I've optimized as much as I could the vertical column renderer, but the essential distances/scale values for each column are a precalculated animation.

I've also used the same renderer with precalced techniques in my demo Wolfenstrad. I precalculed distances for each part around 360 degrees and select the window of view, so only rotation around a stationary point (one part with the greetings is still animation, with slow frame rate and interpolation between half the columns to fit in memory). The nice aspect of this demo is that I also tried to show animated effects on the walls just by scrolling or displacing column coordinates (just like the doomonstration doom WAD I released years ago where I did plasma and stuff on Doom walls :). Exception is the end upscroller where I really move data upwards on the columns.

But as for realtime, currently the raycaster code for distance calculation, while using as much as possible precalced tables, it's still written in C (yes I am in love with SDCC compiler now :) and I am too busy/lazy right now to catch up and port it to assembly and optimize it. Besides the numerous bugs, might be taking more than 12VBLs, that is 5fps or less. Many people are asking me what's happening with the engine but I always say when it's done :P

The first one who ever did a wolfenstein on the CPC was Richard Wilson. It's here (also download link). A realtime one, kinda slow but kinda big. And the great colors of Amstrad shows!

I just realized there is even a GitHub. Code is C with parts of assembly. Interesting. There is even a D64 in the archive, works well with WinVice emulator (added full memory expansions in the settings). WASD IJKL going through it to see how the first episode levels are represented. Crazy!

Very interesting! This one actually reuses parts of the original linuxdoom C code, something that earlier ports/remakes like ZX Doom couldn't do.

source

I wasn't sure what to make of it when I first saw this (I thought it could be a fake video but then I read the description). But this true complete port of Doom on Super CPU. Which is 65c816 (16bit version of 6502 CPU of C64) at 20mhz and added 16MB of Ram.

It's nice as a proof of concept. I don't know if it's very optimized, but if you extrapolate backwards, you can imagine how pathetically slow doom on C64 with 1mhz would run :)

p.s. They should try F5 low detail and smallest screen possible if it's implemented in the port.

The most probable performance killer here is, like in the Amiga ports, the lack of a chunky graphics mode, as everything must still go through the C64 video chip. Writing to a particular pixel on the screen must be a PITA, programming and time-wise.

They must also be using modified colormaps remapped to a few available colors, while still using the original 8-bit resources (something that was done in a more modern TI port of Doom, with colomaps mapping 256 colors to 16 levels of grayscale).

This already should use a reduced resolution as it is using multicolor mode, thus giving you a whooping 160x200 pixel.

There are a bunch of other problems that will haunt you with this setup. Foremost, every time you need to access the normal C64 RAM the SCPU has to slow down to 0.98 MHz.
And as Maes already mentioned, no chunky graphics mode.
The bitmap mode in the VIC2 reuses the char modes circuit, meaning that in memory your picture is interleaved 8 times, meaning that starting from the top it looks like this in reality:
1x1 1x2 1x3 1x4 1x5 1x6 1x7 1x8 8x1 8x2 8x3 ... 16x1 16x2 ... and so on. And the icing on the cake is the dreaded badline. Every 8 lines of picture the VIC2 takes over the whole system to rebuffer color and sprite information.

From the readme:

Some parts has been rewritten in assembler for better performance:

* Fixed point multiply/divide
* Chunky to bitmap conversion
* DrawColumn and DrawSpan

So, yeah, i bow my hat to AmiDog who ported that.

This looks pretty impressive, imo

They might be able to squeeze just a tiny bit of extra performance by at least preconverting fixed-resolution bitmaps to tiles and sprites, that can benefit from "hardware acceleration".

It may also be worth to look into accelerating the drawing of multiple columns (e.g. if a column of a known width is to be plotted, at least some of the dreaded planar-to-chunky conversions can be substituted with a fast, single-color, same-scanline blit. But that would require serious re-engineering, though some modern source ports actually do that (writing two or more horizontal pixels while "paying" only for one, in terms of Doom's ass-backwards column rendering position calculations).

I wouldn't call that a successful port, it is unplayably slow, has no sound. And minus points for running in an emulator.

Just a poc/experiment.

Well, i can send that to a friend who has a real SuperCPU and he could test it against the real thing.