new amiga 500 doom like !

[b0lt-thrower]

Man I can't help it, I keep eeeeeeeagerly checking for new updates

[AmigaHope]

In a software renderer, chunky pixels only matter on the most simple of engines. The more complex the engine, more work is being done in the engine while the C2P overhead remains the same.

So chunky pixels could make Wolf3D go *way* faster, Doom go notably faster, Quake a little faster, but by the time you get to an engine like Tomb Raider, C2P becomes a small percentage of the work to be done. In the end your frame rate gets limited by how slow your display RAM is.

[KK/Altair]

Man I can't help it, I keep eeeeeeeagerly checking for new updates

Me too! Seriously, I check here daily for all possible messages/questions that may appear here.

As for the update, making a demo level would be next task. I'm still figuring out how to approach it, because I'd love to record the process of the making, but I have completely no experience in this matter. Also not having a safe spot to record doesn't help either (when I do have some time, my kid is sleeping nearby, so no voice recording).

So chunky pixels could make Wolf3D go *way* faster, Doom go notably faster, Quake a little faster, but by the time you get to an engine like Tomb Raider, C2P becomes a small percentage of the work to be done. In the end your frame rate gets limited by how slow your display RAM is.

I've talked to quite some AGA/060 demo coders, and not even one said C2P stops being a problem. On the contrary, C2P is the main reason their effects run 25/30 FPS. So, if there's a platform where C2P time becomes small percentage, it's certainly not Amiga.

[d4rk3lf]

Originally Posted by KK/Altair

Me too! Seriously, I check here daily for all possible messages/questions that may appear here.

If it-s quiet here, then it-s because we all are holding breath, in excitement for the demo release.

Recording of making of, is awesome.

[LaBodilsen]

Originally Posted by KK/Altair

I've talked to quite some AGA/060 demo coders, and not even one said C2P stops being a problem. On the contrary, C2P is the main reason their effects run 25/30 FPS. So, if there's a platform where C2P time becomes small percentage, it's certainly not Amiga.

Consider that C2P can be done at copy speed on 060 (copy from fastmem to chipmem), i think the chipmem write speed is the major limiting factor for AGA/060 coders. even if you had a chunky mode, the slowdown would still be the write speed to chipmem.

[Mathesar]

Originally Posted by b0lt-thrower

Man I can't help it, I keep eeeeeeeagerly checking for new updates

Me too! Can't wait for the demo...

[b0lt-thrower]

Originally Posted by KK/Altair

Me too! Seriously, I check here daily for all possible messages/questions that may appear here.

So, anything I ask I apologize if you answered it on twitter or other forums already. Also I'm not even a programmer, so, again, apologies if my questions are dumb.

Did I read you right when you said level, texture, object data and so on was coded within the program itself? e.g., no WAD files, but it's hard coded in the executable?

How "big" (or complex) can maps be and the program still run at a decent (12-14 fps) frame rate? Could you use any of the stock DOOM maps, E1M1 or anything else? What about other in-game effects? Hurtfloor, etc.?

Thank you in advance so much for your responses!

Oh, and I shared this with Rebecca Heineman, who did the Jaguar port of DOOM back in the day.

[d4rk3lf]

Originally Posted by b0lt-thrower

Also I'm not even a programmer

Me too.

From what I understand (correct me if I am wrong KK/Altair), this is not like Doom engine, but more like and advanced Wolf3D engine.
So, no stairs, but there's a lot of visual addition in comparison to wolf 3D Engine.
It can have diagonal walls, it can have floors up to 2 or 3 levels (but you can only look at them, not walk on them), openings on the roofs, background image at distance.... all this he showed in the video.
All this additions makes levels to appear much bigger, and more doom/quake like in appearance.
It even have some cool lightning cast on floor effect.

[NovaCoder]

Originally Posted by AmigaHope

In a software renderer, chunky pixels only matter on the most simple of engines. The more complex the engine, more work is being done in the engine while the C2P overhead remains the same.

So chunky pixels could make Wolf3D go *way* faster, Doom go notably faster, Quake a little faster, but by the time you get to an engine like Tomb Raider, C2P becomes a small percentage of the work to be done. In the end your frame rate gets limited by how slow your display RAM is.

Yep for AGA/RTG this is accurate. OCS/OCS with an accelerator will always be very limited doing traditional c2p.

[d4rk3lf]

That brings me to another (noobish) question:
With Aca 500 + in my Amiga 500, will there be any speed improvement on (default) 14Mhz (68000), or overclocked 24, or 42Mhz? And additional 8MB of Ram, of course.

Edit:
I have to correct myself here.

Originally Posted by d4rk3lf

it can have floors up to 2 or 3 levels (but you can only look at them, not walk on them)

KK/Altair actually mentioned he is thinking of a way, to even allow walking on different floors. That would really bring it to Doom complexity.
Now, how cool is that?

[saimon69]

Originally Posted by d4rk3lf

Me too.

From what I understand (correct me if I am wrong KK/Altair), this is not like Doom engine, but more like and advanced Wolf3D engine.
So, no stairs, but there's a lot of visual addition in comparison to wolf 3D Engine.
It can have diagonal walls, it can have floors up to 2 or 3 levels (but you can only look at them, not walk on them), openings on the roofs, background image at distance.... all this he showed in the video.
All this additions makes levels to appear much bigger, and more doom/quake like in appearance.
It even have some cool lightning cast on floor effect.

While not enough for a doom clone, would love to see some dynamic adventures or dungeon crawlers on the style of Corporation, Captive and hired guns with this engine

[idrougge]

Originally Posted by KK/Altair

2. Complete sound system from scratch - right now it plays one MOD continuously, but the true dream would require some kind of custom music player (and probably a tracker :P) with dynamic allocation of channels, that would also be shared with SFX.

Sounds like you need Phx's ptplayer library. http://eab.abime.net/showthread.php?t=65430

[Muzkat]

Looks fantastic. Well done and keep up the great work!

[paul1981]

Originally Posted by Muzkat

Looks fantastic. Well done and keep up the great work!

Yep! This is where the fun really is to me - watching these sublime programmers squeezing out the very best from a 68000 Amiga and to just marvel at what really can be done.

[KK/Altair]

Did I read you right when you said level, texture, object data and so on was coded within the program itself? e.g., no WAD files, but it's hard coded in the executable?

Yes. My objective was to get something playable and fun before motivation burns out, taking all shortcuts available. And skipping disk handling was definitely a major shortcut. Also at this point files just cause more problems than solve, because the format I store things in changes routinely at this point, and I expect it to change a lot more. I keep all source files in WAD (yes, the Doom format) and BMP formats and just convert to C data tables when building executable.

How "big" (or complex) can maps be and the program still run at a decent (12-14 fps) frame rate?

Way bigger than your Amiga memory. The only thing that gets slower with map size (except for loading, or course) is BSP complexity, which still grows logarithmically and is used only for locating camera and moving objects. Everything else - lost of walls to draw, active objects, etc - is local. After finding where you are in BSP, the engine only considers your immediate vicinity. The frame rate is mostly dependent on how complex your immediate surrounding is and how big objects are drawn on the screen.



(* only visible objects are active; literally; which has fun implications, that if the doors close when missile was mid flight behind them, it will freeze and continue after opening the door)

Could you use any of the stock DOOM maps, E1M1 or anything else?

Stock Doom maps are to detailed to be drawn effectively. While my engine has zero overdraw while drawing maps (Doom was really wasteful with this case!) the cost of computing how to draw each vertical pixel column is considerable and looking through 3-4 portals is maximum before things start getting slow. I was aware of this bottleneck and designed the map accordingly, which isn't true for Doom maps.

What about other in-game effects? Hurtfloor, etc.?

Colored floors and ceilings are already supported (e.g. grass outside) and such sector effects ould be trivial to add. I just didn't feel they would be readable enough without any kind of pit to fall in.

From what I understand (correct me if I am wrong KK/Altair), this is not like Doom engine, but more like and advanced Wolf3D engine.

This engine has nothing to do with Wolf3D, which used raycasting. Even the engine in Wildcat demo didn't use it. Raycasting is generally straightforward, but polygon rendering is much, much faster.


But comparing to Doom, my engine is much more advanced, when it comes to drawing optimization. While Doom just rendered a lot of things back-to-front, I'm drawing front-to-back with using portals with zero overdraw (which is what Duke Nukem 3D did). But while DN3D computed what to draw and sorted on the fly, I precompute this information. I don't want to sound overconfident, but my map drawing algorithm is probably more optimized than both of them (but again, I had both this engines as a reference, and could improve upon them).

So, no stairs, but there's a lot of visual addition in comparison to wolf 3D Engine.

As soon as the engine started looking more like Doom than Wolf3D, I focused on making a playable game. Variable-height floors will definitely be in - I just wanted to limit the engine complexity and check things working before diving deeper. I have quite a clear idea how variable-heigtht map rendering should work. Funnily enough, drawing sprites on top of that would be more of a challenge (e.g. a monster partially hiding behind a low wall).

With Aca 500 + in my Amiga 500, will there be any speed improvement on (default) 14Mhz (68000), or overclocked 24, or 42Mhz? And additional 8MB of Ram, of course.

If you get to a level of a stock A1200, expect stable 25 FPS (tested on PAL) with an occasional frame drop. At this level, the CPU just gets things done and Blitter C2P becomes the bottleneck. You might get there or close with just 14MHz and some Fast RAM (A1200 without cache), and definitely should hit it with 24 MHz.

KK/Altair actually mentioned he is thinking of a way, to even allow walking on different floors. That would really bring it to Doom complexity.
Now, how cool is that?

I have already a clear idea on how to do that. It just requires rewriting a good portion of the rendering... AGAIN!
But it's definitely cool enough to definitely try it once I'm up to this task.

While not enough for a doom clone, would love to see some dynamic adventures or dungeon crawlers on the style of Corporation, Captive and hired guns with this engine

That might require a lot of tweaking, considering how much map data is precomputed, but probably should be possible.

Sounds like you need Phx's ptplayer library. http://eab.abime.net/showthread.php?t=65430

Thanks for the link!! I'd still love to have some wavetable-based instrumnents to avoid the sound of repeating samples (with 64k limit you can really hear that), but it might be a good solution for now.

[b0lt-thrower]

As always, KK, you provide some great insight. I'm looking forward to watching this grow, and develop. Thank you for sticking with it. The path through native Amiga FPSes is a sad one in places, scattered with forgotten and abandoned programming projects...

[Tigerskunk]

This project is so crazy amazing..

I don't have words for that..

[malko]

@KK/Altair : Your "think out of the box" to make FPS games run better on Amiga, is just amazing. You're a genius ! (in all modesty of course )

[Glen M]

Originally Posted by KK/Altair

I'm drawing front-to-back with using portals with zero overdraw (which is what Duke Nukem 3D did). But while DN3D computed what to draw and sorted on the fly, I precompute this information.

This statement above pricked my interest. If the engine allows a player to freely walk around a 3D environment so you have a view in any direction from any point how is it possible to precompute this? Surely there are thousands of possibilities hence why games like Duke3D do this calculation real time.

It is of course very possible I'm missing something obvious here but the above is at least how it appears to me reading the thread.

[Dunny]

Originally Posted by KK/Altair

I've talked to quite some AGA/060 demo coders, and not even one said C2P stops being a problem. On the contrary, C2P is the main reason their effects run 25/30 FPS. So, if there's a platform where C2P time becomes small percentage, it's certainly not Amiga.

I think that the point here was that c2p becomes less of a problem as the overall geometry engine complexity increases - you're still going to be spending the same amount of CPU cycles doing the c2p, but as a percentage of the overall work done it decreases considerably as the work becomes more complex.

In other words, the amount of work involved in transforming vertices and moving actors etc increases massively, while the c2p work stays the same.