Dread Ep 01 - making "Doom" clone for Amiga 500 

Can you make it a tc for PC Doom? I would like to use the graphics for custom maps.

@Frax Would have saved amiga

Winden caves will do

Exactlly my first thought :)

Nah, the amiga died due to stupid business decisions..

I blame the penny pinching bosses at Commodore and the dominating Pee Cee market!

@@AmigaA-or2hj It was the Commodore douchebag management and PR people that killed Amiga and Commodore off... The technical staff was out of this world and would have handed them the entire world if they had been given just half a chance.

Its a nice thought, but the truth is more complicated than that. Bad management, law suits also had a part to play.

The reason why everything went DOS and Windows is that those System can run on every PC you could bought.

"This is a revolution. Making the impossible possible." - A500 talks with KK/Altair.

Except Carmack was 100% right and this is NOT a proper DOOM engine game. Just because it has the same artwork doesn't mean it has the same engine.

That's an emulator, though. Would it perform the same on a real A500?

@@boden_staendig Yes because the UAE is in the cycle exact mode, so the speed is the same as on the A500.

This is an extremely impressive project, but the geometric complexity supported at playable framerates is quite a bit lower than doom.

Thanks! Actually, the exporter was first. Including the 3D preview of the map, to get a feeling how it would look on Amiga with 160x100 logical pixels, dithering and limited palette.

This is still a work in progress. The variable height floors will definitely come at some point. As soon as I got the ceilings running I focused on gameplay to avoid making just another techdemo, but that doesn't mean I forgot the engine.

@@nonarKitten Yes, A1200 was 386SX competitor, it was suppose to run these 3D games much better. Never did.

Thank you very much!

I'm seriously considering dedicating an episode just to fixing a hand (change dithering, use sprites, and see what's best for performance and quality).

Hand-pixeled sprites for weapons are in the works. It's good to have supporting collaborators. :)

It creates kind a cool side-effect as well :) I know that it's not intentional and the preferred method would be to draw it solid, but sometimes these side-effects of optimization result in a quirky look that some of us actually end up loving :)

Sum of all little optimizations I could have thought of. Including rendering algorithm that's way better than Doom - one closer to Duke Nukem 3D, with extra precomputed stuff for map drawing.

@@KKAltair Have you made a video explaining the rendering algorithms and optimizations you used to implement this? If you haven't, I would love it if you did - and please, if you will, open up a bit on how you came to choose them? Oh well, just a humble request :) and maybe you already did make such video... haven't checked yet :D

@@KKAltair I assume its all done in assembler?

By the time Doom came out, Commodore's fortunes were already in terminal decline and the Amiga was completely irrelevant in the USA market.

I said, if it had been before the ID Doom

I'm using Doom Builder 2 for editing. It's a free editor for Doom, which can be easily reconfigured to work with other games. It comes with configs for all games on Doom engine, but gives no problems adding new one. I've written just the converter which offers map preview (for me to check if everything works OK), but otherwise has no editing features.

@@KKAltair Oh, I see. It's been a long time since I used a DOOM editor. Like... 25 years. How time has flown by. hehe I remember the sweet spot for a PC spec back then was a 486 DX4-100. That was often a good machine for DOOM.

@@electronash Hasn't been even 20 years for me - I must get back! And finish my megawad project - even if it's not going to be a megawad... Maybe a mid-size partial conversion! If I can just get myself to start I could see if I still have the same love for it... Who knows, maybe I could make it a whole 32-level thing... I would have to start by checking out the new engines, mapping, scripting and other features of them, then upgrade my original (which unfortunately possibly exists only as a demo released originally on ftp.cdrom.com/pub/idgames/ which is long gone. Unless I'll find my work files on some of my old hard drives. I'm just afraid that all of them might have been only on one HD that's broken almost as long ago. But it's still available under the name KTA for Kill Them All on doomworld.com - I prefer it simple :) - the name that is; I don't have a fantastic storyline, just some maps and stuff that is needed for a good game of DooM. There's two released versions, the latter one is for BooM engine I believe and the former was an earlier phase made for the original engine and used a DeHackEd patch to modify the executable.) I especially want to really badly do a complete remake of the MAP01, because although some gave good reviews of it back in the day, I've now come to think that it sucks. P.S. I did it again... When will I get rid of my habit of starting a short side not inside of parenthesis and make it a huge multi-sentence moster... I actually started 2nd parenthesis inside the first, but edited it away :D Really really bad habit.

Having said that, this would have been a killer-app back in the 80s/early 90s. This game could have saved Commodore!

For CPU 7.09379 Mhz for PAL mode 7.15909 Mhz for NTSC mode. Custom chips have slightly higher clock speed with NTSC mode.

Thanks! :)

They are relatively easy to find, at least in Europe, and A500's go for about $120 around here in Poland. Consider subscribing if you'd like to watch the progress and eventually get a binary to play yourself. :)

@@KKAltair Subb'd my friend. Actually surprised at myself for not hitting sub before commenting. I wish you the best and I'm excited to see what we can see down the road.

in theory, a vastly superior alien breed 3d could be made as a megawad or iwad for this engine on the Amiga 500

Thanks! :)

Very doubtful. NTSC means DMA has to transfer 60 frames/s instead of 50. While using 4 bitplanes mostly prevents display DMA from taking too much bus time, they still clash at the times display DMA, the Blitter and the CPU are all active at the same time (which does happen in my design).

Zobaczymy jak będzie po zmianie wszystkich tekstur (soon!). :)

Thanks! 😁

Well, at some point I'd love the idea of multiplayer support, but serial cable would be easiest to implement. Especially that I plan to use custom bootloader and completely kick out the system to get as much memory from 512k+512k config as possible. Also the fact that the game is delta-based would cause some problems for making co-op modes (I'd have to sync the enemy simulation).

@@KKAltair - got it. Hopefully, you'll reconsider. Locking out the Amigas greatest asset - its revolutionary operating system - sounds all backwards to me. Imagine a Windows game that would only run from USB, that would also require a serial cable for multiplayer. No one would accept that. Please don't treat Amigas users any differently. Rather, see system friendly compatibility as part of the challenge! :) Best of luck!

@@First_Ninja Well, I was raised on Amiga 600 with no hard drive, so booting from disks and disk swapping was kind of standard procedure for me. Right now the game is just an exe that's OS friendly, but I'm finding myself constantly fighting against memory limit. But my main priority is a stock A500+512k and if I'm faced with a choice of keeping useless OS drivers or adding an extra monster or a few textures, the latter is a no-brainer for me. Stock A500+512k with just a floppy is king here, and all other features will have to align. But that said, I will keep in mind both HDD boot and keeping OS/drivers alive - just expect it to require some more system memory.

@@KKAltair Understood. Ideally, the program would adopt to the system resources it has at hand. Running in a miniscule environment (like an unexpanded A1000/A500/A600/A2000) is all in itself an acomplishment, but the year is 2020 and the reality is that most Amiga owners today have expanded systems with a lot more RAM, SSD-like hard drive storage, the latest version of AmigaOS (3.1.4.1, released last summer) and - of course - Ethernet or wifi networking capabilities. The reality is that every Amiga is pretty much unique - even within a particular model range of Amigas (like the 500, there are significant hardware differences). It would be nice if you would have all of this in mind while moving forwards, and that the program would dynamically request the system resources it needs. Again, it's an awesome project you're managing, and I hope for the very best!

@@First_Ninja I think you extrapolate what you own to others a bit too much. I don't even own an A1200, and I know a lot of people who do as well, or own it in more or less a stock configuration. But my primary reason for targeting a bare A500 is that it wasn't done before. Expanded Amigas, or even a stock A1200 already have good FPS games. It's A500 that doesn't shine in this field. I definitely will keep expanded systems in mind, and they could benefit from smoother framerate, HD loads and keeping things in RAM instead of constant loading, but everything should be playable on a stock A500+512k as well.

I'm definitely going to use that tip!! Thanks! :)

Yes, the performance is the same. And A1200 should play it at almost 25 FPS (I haven't tested it on real A1200 because I don't own one, though).

@@KKAltair Wow, if I remember correctly the original DooM engine had hardcoded top-FPS limit of 24 - that's the smoothest it ever ran, before the source ports :) Even though being a much more limited engine, I haven't heard of another "doom like" game (well, basically any textured 3d game - and let's not go to the "it's not real 3d", it's not really relevant) running on Amiga that smoothly (it may be that I don't know them all or well enough, I haven't actually played any of them and I lost my A500 [as well as never had any other Amigas]). Someday I should check them all, even if just with an emulator...

@@robsku1 Original DooM ran at fixed framerate 35Hz.

PAL resolution, but logical in-game screen is 160x100. Extra horizontal resolution is used for dithering, and vertically lines are doubled with copper. But I don't think this video will be watched that much - not that many retro fans out there (a.k.a. "Tak niewielu nas zostało..."). ;)

@@KKAltair I'm pretty sure it will be over 1000 views in 1 week :) I for sure meant most watched Amiga video. The Amiga is getting more popular again, many are coming back. You are for sure helping with this kind of game :) What about network play. Would it be possible for people with internet connection?

@@nikosidis Looks like it's over 2000 views in under 24h. :)

@@KKAltair That is crazy man!! Gratz :D

@@KKAltair (yet)

Good catch! I do use the sector mode highlighting to check things, but it's still not as foolproof as you can image. And no - the automatic subdivision is still not in. My steam went into other features seen in other videos. :)

​@@KKAltair It seems the last month has left my brains over-sensitive to stuff like this. I have been banging my head against the wall while trying to implement a Quake 1 map format parser and proper occlusion culling for my demo engine so that I can load geometry from TrenchBroom editor. In a sense somewhat similar to what you are doing in this episode, except I don't need to worry about ridiculous system limits! I read about your project from a Finnish demoscene / computer magazine called Skrolli and had to come see what's up. I have not watched the other parts yet, but judging by the first episode this is going to be very cool and interesting series! Keep up the good work!

@@meanmole3212 Quake 1 BSP file format is quite fun, although as far as I remember, occlusion wasn't that bad as it was just a cluster visibility matrix. Computing lightmap UV was way more messy. :)

​@@KKAltair Quake uses the precalculated potentially visible sets to determine which parts of the map is visible from each location, and based on that information you can do the visibility culling alone just by figuring out where the camera's position is in the world. Is this what you refer to with "cluster visibility matrix"? Calculating the lightmaps and the potentially visible sets is beyond my understanding for now since I have not found very good resources about these topics, except the original source code of Quake. For now, I decided to do the culling in real-time based on camera frustum and a leafy BSP tree's leaf nodes containing chunks of the map's polygons. Calculating spheres and bounding boxes for these nodes allows a quick way to cull all of the geometry outside the camera frustum, but after that, every node that gets captured inside the camera frustum must be also culled based on if they are occluding each other in depth. This is what I am currently working on, and the plan is to utilize each node's bounding box and OpenGL's occlusion queries to determine which nodes are actually visible to the camera. Things get tricky when you also have to consider how to bind all of the map's textures efficiently with minimal amount of bindings. As far as I know, Quake's GL version sorts all of the visible polygons based on their textures and draws them in chunks with minimal amount texture bindings. I was able to eliminate this every frame sorting step with the aid of OpenGL's 2D array textures and a vertex attribute that supplies the index of the texture. If no sorting and reconstruction of the geometry is needed each frame, then the map's geometry can be packed inside a single static VAO whose triangles will be pre-sorted based on BSP tree's leaf nodes. This allows quick drawing of separate nodes instead of the whole VAO when index ranges are used. To be honest, I am not even sure does this kind of sliced index drawing yield any performance advantages. If the geometry is already in GPU's memory and does not change, does it make a difference to draw slices of it instead of drawing the whole thing all at once? OpenGL performs automatic clipping for the geometry that is outside the screen space anyway. I guess there's some benefit when it comes to drawing the overlapping geometry in z-direction because that geometry resides inside the screen space.

​@@meanmole3212 Yes. It's "cluster visibility matrix", because every BSP leaf has cluster ID (clusters are simply groups of BSP leaves), and matrix is just a NxN table with "1" on row/column intersections when a cluster X can ever possibly see the cluster Y. (the matrix is stored as triangular matrix, iirc, to save memory) You don't have to calculate lightmaps and visibility at all - you have it stored precomputed in the BSP file already. Even then, computing lightmaps yourself is not that hard and it's a matter of casting rays from lightsources to lightmap texels (plus some edge cases). On the other hand, precomputing visibility is haaaard. As far as frustum culling goes, you can do rough culling while parsing the BSP. At each tree node, you can check whether the camera looks away from the split plane and discard huge chunks of the BSP tree. I'd completely skip the OpenGL occlusion culling if you are to go with Quake BSP. You have perfect occlusion precomputed there, and recomputing it real-time just would make things slower. And last but not least, your last point is more than valid. Quake maps are lowpoly by all today standards. One modern character has more polygons than that. Depth complexity (overdraw) might still be a minor concern, but GPUs are really good with fill rate now. So you can scratch all the above talk, extract all triangles, batch them by texture to limit draw calls and you are good to go. You might do a z-prepass or even look up the occlusion matrix on the Compute Shader to speed things up, but why bother? Because the truth is... even 20 years ago an average computer at my university could smoothly draw Quake 2 maps without any optimizations other than drawcall batching.

You can find my talk about technical details here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-a57QJAE5118.html I will try to rework this into a more organized episodes when I'm done with the map and get some more confidence with the video editing.

Thanks! :) And waste of time or not... what uninterested people say is completely beyond my own interest. I make it for people who *do* care. :) (still, it got my channel up to over 1200 subs, so that's probably best waste of time I did in a while :) )

@@KKAltair the best waste of time ever hahaha. No just keep up with the amazing work. Imagine you made a fucking incredible game for all us Amiga fans to play? It would be/Will be amazing. Totally admire you great skills, and your videos which are very complex and interesting. I can't wait for what ever the outcome will be.

@@RabidGerry Thanks again! :)

No. That would require a completely different engine feature set. This specializes in top-down maps and vertical walls.

Hand is just badly dithered. By adjusting skin tone and dithering settings it should look much better. I just didn't focus on that little problem and let is slip.

Technique is much different from Wolf3D (raycasting) and Doom (BSP), and more like Duke Nukem 3D (front-to-back portal rendering). Except that I precomputed everything possible, optimized drawing routines to death and use quarter resolution (160x100 logical pixels). 16bit mode is optimal here, because more bitplanes cause display DMA to start cutting into CPU/Blitter bus time. And it's also very convenient with C2P. I might have discovered a trick or two along the way, but everything is more like a sum of a bunch of tricks and optimizations rather than a single major breakthrough.

Fast RAM helps immensely, and A1200 provides completely smooth gameplay. I had exact stats somewhere, but can't find them at the moment.

@@KKAltair So, a playable version of doom would have been possible on a stock A1200 and then totally smooth with fast Ram? The 13 year old me is crying right now.

@@amcadam26 This is not Doom. It runs quarter the resolution and everything is ether simplified or optimized. But that's what you have to do to get such a thing running.

Interesting - 4MB was the minimum RAM requirement for original DooM on PC; I wonder, if this runs on A500, surely a more advanced version that's closer to original, maybe even able to use the same map format directly (although if the new one provides faster rendering, maybe a map format like the current one, but with all or most the features of DooM WAD maps remaining), could be made for A1200? I'm not talking about exact clone, but close enough to *not* be in same category as the most limited official DooM releases for consoles (SNES and GBA versions come to my mind first) but rather closer to the DooM engine than them, even if using a completely different renderer... Are you planning on developing a more advanced version for A1200, or will it be the same as A500 version? Or maybe have features that you can turn on/off if you have the machine for it? That would be neat. edit: Oh, I just realized... My response was written more for the KK/Altair than to the original posters comment... Sorry about that :)

No. I never did anything for Genesis (yet). I did some PC intros and retro stuff on the demoscene - check other videos in my channel to see exactly what. :)

Demo (or demos) will definitely be. As for the bigger versions (or even constant updates), I was considering adding small supporter fee, or something, to help me not running out of steam with this project.

We are talking Amiga here, nothing is ever released for free, everyone thinks they will make big bucks on a dead platform.

@@rasz I don't expect any serious money from this project. And don't worry, I will be releasing free playable versions. But on the other hand, I have no obligation to release everything instantly for free and it's completely normal for people to get supporters which enjoy additional benefits (e.g. up-to-date build after each video - why not).

@@KKAltair More than I'm interested about whether the game itself will be available for free or not I'm interested if you will open source the engine? It's definitely something worth preserving as well as sharing with the community :)

@@robsku1 At one point - definitely open source. I'm all for preserving culture.

Already on it! :)

Number of PAL frames (50Hz) required to render a frame.

Edit: Just a small piece of my thought, LOL :DDDD I'd love to see what could be done with it - does it have custom graphics capabilities that could be used to optimize doom-likish 3D (I know, it's actually not real 3D rendering) rendering? Because that's what was the biggest issue with different console ports, none of the 16-bit ones I remember could do it the way DooM did it and just like this project, custom engines were created specifically targetting the hardware were made for each, even going so far as adding a custom graphics chip on the game cartridge to gain performance. I believe it was the SNES version that did this but I'm not sure if it was the only one. I think it was the GBA that could have had way better gameplay if John Carmack had accepted it, which he didn't and I believe he later admitted being a wrong choice. It was because of how it used the hardware to optimize rendering created unwanted distortions and "movement" on textures; unfortunately the engine had to be scratched and rewritten at cost of making more compromises on level complexity, number of enemies visible at once, etc. etc. *and* still ending up being one of the worst console ports of DooM when it comes to FPS - horribly choppy gameplay. The big issue is that Amigas video system works differently than that of a Mega Drive/Genesis - and it's more than probable that this particular renderer written specifically to abuse ( ;) ) the graphics capabilities of A500 to achieve it will be totally infeasible on Mega Drive/Genesis. The CPU being the same only means that the CPU is theoretically powerful enough to implement a doom-like engine (with much more sever limitations) *if* there's a way to do it fast enough with the graphics chip available on the device (unless you want to make a custom cart with accelerated graphics chip within it; that could even make this more directly portable if you included the graphics chip ripped from A500 on it :D, but how on earth would you get that product to others is where it becomes close to impossible - not worth the trouble and cost). The thing is that I doubt that the Genesis/Mega Drive graphics capabilities have what it takes to do this kind of renderer - they could outperform PC's on usual 2D game graphics, but they weren't that good for 3D (except simple vector graphics) - mostly the video chips sucked for rendering any graphics pixel by pixel while VGA's 256-color mode on PC was excellent for simply plotting pixels (and that's all it was really ;) ) and DooM used raw CPU power to render the graphics. There's much more optimization techniques involved in this project than DooM had to do on PC where you could utilize the power of 32-bit 386 and 486 CPU's and without *any* acceleration available for 3D or 3D-looking graphics on the chip a less powerful PC with less capable video chip (really, with 386's PC's started to be just as good for rendering any games without the need of hardware acceleration in the loose sense including hardware sprites, which was why 8-bit machines dominated over 16-bit PC's, so can't be counted out). Unless someone found a way to create a renderer using Mega Drive/Genesis graphics chip that could run as smoothly this would be what could kill the idea... ...if it wasn't for the final and most devastating fact about 16-bit game consoles: They suck when it comes to available RAM. 72 kB of RAM, 64 kB of video RAM in case of Mega Drive/Genesis. Sure, the game can be as large as 4MB, but the RAM available is just devastating for this kind of game. I wonder how they got around this with SNES? Maybe they had extra RAM chip in the game cartridge (which is *not* as far fetched idea at all).

CPU alone does 99% of work here, so porting is only a matter of getting the result on the screen, talking with the system (kernel, input, etc) and such. If a system has 68000 7MHz or above and some sensible means of getting chunky graphics on the screen, then it probably could be ported (there is one port on the way ;) ).

@@KKAltair Ohh, what's the port? And yeah, it has 4 16-color palettes so each tile can do 16 colors. Also if you look up Gasega68K's port of Wolfenstein 3D to the console, he uses a similar dithering method to give the impression of more colors onscreen than the system can actually do. Also you'd probably have to make the viewport a little smaller, but who knows?

@@chrisxdeboy I don't want to reveal the port too soon, but my personal deadline for it is early December. ;) As for Genesis/MD, I would have to look up the specs, but who knows. :)

@@KKAltair Atari ST?

And one of them is writing one. :)

@@KKAltair tired of waiting, you've become

There is only one map currently, and switching the map requires recompiling the executable. This was basically the easiest way to test things at the early stage of the engine, where the map data structures tend to change daily. First published demo will work this way, but then I'll work on a proper loader. And enabling custom maps (and scripts!) is one of my main goals, because I simply won't be able to produce as much content as I would like, all by myself. Doom Builder 2 is a really great editor, even if sometimes I have to work around some limitations (e.g. the "facade height" line type). Writing custom editor would be as much pain, as using it afterwards, so I preferred not to waste time on it (at least for now). And don't worry, keep the questions flowing! :) Thanks!

Using FreeDoom... almost all? :) Thanks for the BSD license. :)