The smoothness of the weapon sprite animation creates the illusion that the whole game is running at a higher framerate than it is, that's really neat! Beautiful pixel work from John, too!
Thanks! :) But right now there are no other coders heping me - I'm on my own, code-wise. The two graphicians I work with are doing awesome job, though. :)
Sadly, he was right. Doom has much higher resolution, uses much slower rendering approach, has more complex levels, draws textured floors and processes logic with fixed 35Hz update rate. And every single one from this list is already a performance killer for Amiga, let alone all 5 together. But still, it's not my point to remake Doom, but to make something cool which was never done before. :)
Wow, those results at the end with the increased framerates and animated movement are absolutely stunning. The spin-down animation on the chain gun had me grinning ear-to-ear. Fantastic work KK and John! Spectacular stuff.
Amazing work! So much is possible with just the right ideas! This is really delightful, and I'm not even big on Amiga -- never owned one -- but I would totally play this on at the very least emulation! The spin-down of the chain gun is super smooth and graceful! If you want to make it look "stronger"/"harsher" as it fires, you could make it shake violently, so it looks like you need some muscle to hold it properly still. :)
Thanks! Basically we did test a more violent shake but it just felt too much. The barrel already spins at a very fast rate and the shaking made it more blury which didn't felt quite right. This latest anim still has some recoil shaking (unlike the original Doom and Free-Doom chaingun variants) but it is subtle. Having said that we may revisit this in the future (once sounds are also in to get a better feel) ;)
The major problem was the firing rate. The chaingun fires 12.5 bullets per second and any more shaking at that speed would just blur the weapon. With all this firing, we even didn't have time to rotate the barrel properly (and still keep the animation clear), so it fires twice during the time a barrel moves by one position.
Thanks! Actually John made and sent me them before we even thought about any decision here. So I had to implement them not to waste his work, and there was no debate after seeing the results.
@@KKAltair this is really shaping up so good I am starting to think that if this came out in 1993 It might have bought our beloved Amiga some more years! So, so cool! :-D :-D
To run Doom properly, back in 1993, I needed to upgrade my 486 SX25 's cpu to a DX2-50. The fact that you found a way to run something similar on a 7.2 mhz CPU with no math co-processor is astounding. You two are rockstar's!
@@KKAltair I understand this, but try to run the original Doom on a 8 mhz 80286 AT PC and see the frame rate one will obtain while attempting to run this game.
The fact the hand gun looks darker when the muzzle flashes is actually something that we can justify since our eyes care about relative brightness more than absolute. The non-specular parts of the gun would suddenly look dark contrasted against the flash.
I just saw the complete first/test level on Pixel Shade channel and I find that the non-squareness of certain rooms and corridors (as opposed to wolfenstein 3d for example or duke 3d on megadrive) and the level design in general makes the universe of the game very easy to get into.
Just don't bring a second A500 there, because as I have null-modem deathmatch on my todo list, if all goes well, you will hardly get any job done then. ;)
A very interesting video not just for showcasing the game but for those interested in pixel art as well as how the OCS chipset worked along with its strengths and limitations. Super excited by this. I have to say, even though I thought this game look beyond impressive I always thought the gun and hand graphics let it down. Im so glad this has been updated with sprites. Looks so much better.
Great episode again. Those animation tweaks you've done for the weapons is genius. What a great personal achievement to get to where you are. Oh yes - that spin down animation! I think/hope my a600 020/40 should be able to eat this for breakfast :-D
It was kind of fun moment for me when I taken a peek at original Doom after playing with John's graphics for some time. Man, the original Doom chaingun felt so rough with its two firing frames. :) John did an awesome work here.
Then go for it! :) A lot of work, but quite rewarding seeing the result. Alternatively, after we've got things sorted out we'll be starting a Discord server where people could be involved in the project if they like, or just hang around for a chat, if you'd be willing to have some fun with this engine.
Wow thats a top notch unbelieavable result for a plain A500 .. and i'm in love with the chaingun animation! Seeying what you reach with a plain A500 I wonder what you could obtain by using instead a 68020 AGA machine
I'm wondering -- how large a map can you create? Not just in terms of complexity, but play time and space? What I enjoy about classic doom is that it may sometimes take you easily over half an hour to find the keys, buttons, or doors, and find your way. Having elevators, stairs, height differences of any sort is also very often a key element to these things. We don't have floor heights here, right? I'm wondering if it'll still be possible to have hazards, water or lava, crushing walls, such things. There are so many great doom mappers out there -- if you held a contest -- I bet people would make MEGA WADs for DREAD too.
In time it all would be in. I just don't want to end up with just another game engine, so I'm pushing in the game direction instead adding engine features. But I'm pretty confident I can implement varying floors and ceilings. As for map size, it's only limited by memory size. Hidden surface removal is done in such way that the engine totally doesn't care about map parts you can't see.
You got the idle frame for the chaingun completely backwards. The intended idle frame is with one barrel in the middle, not the inbetween frame with two barrels visible side-by-side. Also worth noting that it has 3 barrels and not 4, just for reference.
Well... since we have a spindown animation, it should stop somewhere random each time in reality. I know FreeDoom used idle frame with a barrel in the middle, but I kind of like it more this way. But in any case, this is trivial to change.
@@SomeOrangeCat You don't need a bigger hammer. All you need is lower numerical complexity (or at least a way to skip some not needed computations). :)
I can't wait to play this whenever a demo is done! Might I ask, are you thinking of adding gamepad support incase somebody wants to port it over to the cd32?
@@KKAltair The cd32 isn't really all that different aside from the built in CD player. I've seen people port over games like Breathless and Alien Breed 3d 2 to it.
@@dvuemedia 256-color palette would need major engine redesign, which I'm not willing to make right now (A500 is king). But more CPU power, especially coupled with some Fast RAM, is always welcome.
I'm still watching this development. I do beleive if you complete this then people will start working on that time machine next haha. Ask John Ramero to do some levels for it!
Wow. Astonishing. Jurassic Park OCS need to be patched with that engine. 😅. If an A500 is capable of that I'm also curious of what a stock A1200/CD32 could do which such coding sorcery.
Looking again, I wonder if it makes sense to turn off the constantly scrolling skies? Or perhaps scroll them much more slowly or only when turning. The current movement draws more attention to the lower frame rate of the main engine compared to the sprite animation.
I don't know if that would work but have you considered line scrolling as in skewing the more diagonal sprite frames at run-time? It would be a bit harder to author the sprite but then opaque horizontal slices would only have to be 64 pixels wide rather than the whole frame being wider.
I have considered this, but as the Copper is busy duplicating screen lines, interleaving screen handling with sprite handling Copper code would be tricky.
At this point It looks like the most complex graphics on an 3D FPS to an OCS Machine, with the original 68000 of all things is coming to the Amiga 16 or 17 years after its demise. This is stunning. You could run Doom on the Amiga before... but only if you had fast ram and a lot MHz to spare. I am waiting for this so badly to be released. Btw. how many floppys i have to save for this... like 50?🤪🤪
Is the Copper too busy doubling lines to be used to increase the skybox pallet? Eg drawing a dynamic gradient behind alpha dithered clouds? EDIT: I am showing my ignorance even asking this, but I will leave the question here anyway.
Thanks! I wouldn't count on it being completed any reasonable future - too much work, given the current team. But I plan on releasing demos and WIPs once it gets into shape, so I suggest keeping an eye on the channel.
Świetnie. Szkoda, że już zabrakło spritów na cały HUD, ale może chociaż by zrobić cyfry na HUDzie na tych 3-kolorowych spritach ? Uwolniłoby to kolor czerwony i żółty z głównej palety, ale czy oprócz tego dałoby to jakieś przyspieszenie ? To co jeszcze jest do zrobienia zanim otrzymamy demko do odpalenia na swoich Amigach ? :)
Sprity można dowolnie multipleksować - jak sie jakis skończy wyświetlać, to poniżej można go użyć ponownie. Przykładowo pomiar wydajności jest już zrobiony na sprite, który niżej staje się częścią broni. Także jak będzie trzeba, to HUD dopalimy. :) Do zrobienia jeszcze menu (in progress), dokończyć mapę i dobrze jakby efekty dźwiękowe. No, chyba że chłopaki od grafiki wymyslą znowu coś tak fajnego jak te sprity broni, że szkody by nie wrzucić. :)
@@KKAltair Czyli ten HUD na spiteach by działał tak, że w jednej klatce wyświetlamy broń, w drugiej klatce zamiast broni wyświetlamy HUD w trzeciej klatce znowu zamiast HUDa wyświetlamy broń itd ? Nie będzie migotania wtedy ? ;)
Fantastic update! Great work guys, the engine is already superb, this is another cherry on the cake to improve it further! Btw would it be possible to improve the explosions to be less dithered like the gun fire colours?
Absolutely! Basically the video above is just the beginning of what's coming next. Virtually all the old assets are in the process of being retouched, tweaked or outright replaced with new ones, specifically made with the engine's strengths and limitations in mind. It's gonna get much, MUCH better visually so stay tuned ;)
By the by, if you are ever looking for someone to try and make maps for the game, and you have a map editor setup that you could share for this, like a config file for one of the known DOOM Wad editors -- I'd be happy to attempt to create a few maps. Maybe even a set. I was always thinking this would benefit hugely from a community made influx of maps.
I know it's not the point but I'd love to see what you guys could do with a basic A1200 + 4MB fast ram configuration, using tricks and traps learned here...
@@KKAltair I bet. Though I was thinking how a similar ground up approach designed for AGA might benefit. The Doom clones of old basically treated the chipset as an obstacle to overcome so that they could focus on chunky pixel software rendering. And while this worked for faster CPUs, I always felt like there was an untapped happy medium somewhere. Seeing the use of real sprites for the weapons is exactly the sort of thing I mean.
@@KKAltair yes I realise that planar graphics are a problem, hence copperscreens first and later c2p. C2P was great on faster CPUs but after then nobody thought about doing anything that wasn't just the CPU drawing into the chunky buffer and converting it to planar for display. Things like sprite weapon animation could've been handy there too. Less render effort for the CPU. I remember spending time writing c2p routines looking to get copyspeed. And weirdly later, doing the same thing for pixel format conversion in RTG because the existing methods were so slow. In hindsight I wish I'd spent more time embracing what the native chipset could do, rather than focusing only on it's limitations.
Already imagined. I wouldn't be able to sleep at least for three nights after buying it as a teenager (although I was a teenager in late 90's). And looks like that dream lived on until I've got the skill to pull it off. :)
@@KKAltair pc owner: I've got doom Amiga owner: ill just make it myself Pc owner: Hahaha whatever Amiga owner: learns to code and find all the methods .... creates fast 33 years later... haha.
Very good improvement. Good you did not settle with Amiga fanboys "engine looks great" mentality and kept working on weapon sprites that were truly awful. Now they look nice so I do not have to complain about them anymore. Shall I start complaining about the next graphics issue with the engine...? ;-P
Well... the fact is, I *did* settle for it (at least the versions dithered in the previous episode). Just John didn't, sent me the ready sprites and at this point it would be shame not to use them. :)
Jaw-dropping. At 3:42 I thought he wasn't using the amiga engine, that he was showing the original sprites in order to compare with their downgraded version.
Yes, the 3:42 part is just a mockup using animation program - just original sprites pasted onto a screenshot from our engine to get general look & feel.
@@KKAltair Ah ok, so it was just a mockup animation (But I've just checked, resized and put in 15 colors). When you see the final result of your work, it seems believable that the Doom weapons would look fine if implemented in the engine anyway. Thanks for the answers.
Thanks! We have considered that option, but there are problems with this solution. The player shot or explosions can still overlap the weapon (drawn behind it), which we can't do given our 64px limitation. Also managing sprite split would be troublesome given that Copper is already juggling screen lines (halving vertical resolution) and we would have to rewrite entire copper list (right now we are just patching a certain part of it with new values).
@@dlfrsilver I'm making the menu system "making-of" episode (and implementing the menu itself at the same time), so there will be some more stuff coming. :)
Would it be possible to eventually port the assets and maps to FreeDoom? I know that this project is about making a DOOM engine for Amiga, but I can't help but imagine all these original assets and maps being ported to PC at some point.
Maps would require retexturing and remapping things and line numbers, because I'm using my own identifiers for these. Also I'm not sure we will keep the space marine theme (making own games is fun!), so in the end our assets might not be useable for FreeDoom, which aims to recreate Doom look and feel. Other than that, it would be completely up to the artists.
@@KKAltair I'm speaking of FreeDoom strictly as the game engine, not the asset theme itself. So if Dread's engine will be "the same" as DOOM's engine, as in game limits, enemy behavior or map functions, it would be possible to do a 1:1 recreation of it as a FreeDoom-based IWAD.
the only thumbs down is from the guy called John Carmack. I think its becouse of the statement that an Amiga will never run some game, i dont know, who remembers stupid statements :D
He is still correct. This is not a straight Doom port, uses quarter resolution, completely different rendering algorithm and a lot of Amiga-specific tricks.
@@KKAltair never admit defeat or compromise. especially from the PC MASTER RACE :D . If he knew how to program (an amiga) he would run it on a minimum sys requirments. I mean , a 386 AND 4 MB RAM? WHAT ARE WE , THE 1 PROCENTERS :D
A couple of years ago, I made a porn game on the NES, that had the sex sprites limited to 2 frames per animation. I had used sprite offsets to ease the movements, similar to these guns. :P
BTW. What thoughts do you have for the sound effects? I'm thinking that it's unnecessary and not possible to fit in chipmem to have all samples playing in the original 11025 Hz. Many sounds is still good in much lower sample rates. Maybe you can pick samples with different sample rates. Making a collection that sounds great, but still fits in the A500 chipmem. Here is a zip with 10 different samplerates. www.dropbox.com/s/xz4mcsqxrqrqzfg/DOOM-sounds-in-10-different-samplerates.zip?dl=0
The music is midi-files originally. If you're going to have the music I believe it's better to have them converted and optimized to Protracker mods. Please let me know if you want me to do that for you!
@@DjMetune I definitely will want original music for the game at one point. Also Protracker is far from being optimal, considering chipram usage. Paula sound chip is perfectly capable of wavetable playback and it's a shame that no tracker (that I know of) used this feature.
@@KKAltair Wow! Yes! Wave table synthesis would absolutely be super welcome for Amiga. If we could have a way to play it, also as a system friendly virtual synth output device for music (MIDI) development and easy playback. But it would be fantastic if the original midi-files could be playing, as you say. Though they are using more channels than we have Paula hardware channels. And at least one channel would need to be used quite frequently for the sound effects. www.dropbox.com/s/upqo63jkr65bml3/doommusic.zip?dl=0
You mean Blitter line mode? I think my c2p is already quite optimized, but suggestions are welcome. Currently: - source pixels are already 2x1 - blitter transposes and interleaves data in 2 passes (2x 320x100 x 4bpp of data in A+B+D mode), - blitter "nasty" is off, but blitter and screen swap is completely interrupt driven (and CPU already started rendering next frame) - lines are Copper-doubled I have no idea how to improve it further, but I'd gladly hear one. :)
@@KKAltair My approce give you the edge, to balance between blitter and cpu worload, and maybe to speed-up cpu rendering since chunky buffer must be rotated
@@KKAltair simple. I set interleaved planes which are some sort of vertical chunky. Then i'll draw a line with blitter with pattern which Is 4 pixel chunky. So i fully convert them Just by drawing into planes. 1x2 Is made for free Just by setting right blitter Mask. 2x2 Is made allmost for free by copper. Since you can only convert 4 pixel at once, you can choice when doing them, during CPU rendering. By doing so, you can go fully 1x1 imternal rendering with CPU since 2x2 Is made by copper and blitter. So youre going to use less ram, maybe less CPU power to do actual rendering, and maybe speed up wall draw since chunky buffer must be rotated
@@alessandrodigaia9439 My current solution does 2 Blitter 320x100x4bit passes, using ABD channels, for 97440 Blitter cycles total (including one extra word here and there for shifter to work). Column transposition is done in the first pass by splitting the pass in 20 word-sized slices. That's 44 Blitter operations total, but they are interrupt-driven, so CPU already renders next frame. Your suggestion is to draw 160 vertical lines, which would take roughly 92000 Blitter cycles (channels AD for the first line of a word, ACD for the remaining 7). So that might be slightly faster than my approach on the Blitter side, but will put more effort on the CPU to set up the 160 individual operations. And this would consume the benefit of driving Blitter with interrupts. CPU is at premium in my engine (I even wish there was a "blitter very nice" bit), so that won't work. Unless of course I didn't understand your technique and you can't do C2P with just 160 full height lines - in which case the results could be even worse. But the above is the lower bound estimate on filling screen with vertical lines.
Well, the final launcher design is already a lot different than the Freedoom one. Although the original was kinda weak in the first place (imho), so it's not a massive improvement. In any case the weapons are all gonna be replaced once we get closer to using original graphics for the full game. Until then the demo is planned to use mixed reworked free-doom assets and new ones, tailor made for the style and concept KK is aiming for (for this demo).
I've just seen all the videos on this project, and all i can say is your knowledge and dedication to the amiga hardware is beyond fascinating. If you need any help developing a soundtrack or a music theme for this project or your channel in general, i'd be happy to help. So far, i've made a soundtrack for a Cd32 game Pong4k and a theme for RMC retro road trips, and i've composed a theme yestirday inspired by your work. Just say the word and i'll upload it and send you the link. You can contact me on slavko.kozomora@gmail.com if you're intrested. In any case, keep up the good work and cheers!
@@KKAltair I can upload it on wetransfer and send you a link vie email, or i can post it here as a comment? Let me know :D its a work in progress but its about 90% done
@@slavkokozomora8893 Do as you prefer. If you like some publicity, link would be perfect. And in other case, find my email in contacts on devkk.net webpage.