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.
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 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).
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!