new amiga 500 doom like !

[rothers]

Hey, would something like this help? I've made it quite big in terms of the box area it covers, you won't have to draw that part of the screen. It could be bigger still if that helps (could do 128*48?)? You could also do a bare fist on the left and the other hand holding the gun on the right to save more space...

[KK/Altair]

Originally Posted by rothers

Hey, would something like this help? I've made it quite big in terms of the box area it covers, you won't have to draw that part of the screen. It could be bigger still if that helps (could do 128*48?)? You could also do a bare fist on the left and the other hand holding the gun on the right to save more space...

I'd love to have such weapons, but right now I'm restricted to what I can find. But making it too big will distract the player too much. And we aren't talking about speed boost so big we'd have to sacrifice general aesthetics. The thing is, the actual drawing is only one of the major bottlenecks. Another big one is the computation I do for every column of every visible map line.

And as a second thought, firing action can only switch to the first shooting frame, so we could assume that the common area of current frame and first firing frame is safe to be skipped. I don't expect big gain, but every gain is a gain worth trying. After all, the current performance is no result of a single trick, but rather the sum of all tricks and optimizations implemented.



And in the meantime, I've just finished recording voiceovers for the next video. As an afterthought, I'll just need to add some quick introduction (what I do in the series in general), because cutting straight to paper map design without explaining what is it for doesn't cut it. But I feel I slowly get a hang of this whole editing/recording thing.

[rothers]

Can you share or explain what the palette situation is and I can draw you some suitable things.

[KK/Altair]

Originally Posted by rothers

Can you share or explain what the palette situation is and I can draw you some suitable things.

Palette situation is dynamic, to say at least.

I'm definitely going to allow each map to have a custom palette, so source assets would have to be stored in 8bpp format (either one 256-color palette for entire game or a per-asset palette) and they will be dithered to 16 colors of the level on load (including coloring logical pixel halves separately). In case of 8bpp source assets, a pair of tables (for checkerboard pattern) could go a long way and allow complete control of how source assets are represented in map's palette - including but not limited to recoloring for climate and avoiding nasty dithering outcomes (because we all love how current hand looks like).

Another thing is, that a lot of people keep questioning me how using sprites could improve the situation, which would give the gun its own custom palette. I'm not completely sold on this solution, because it requires either limiting gun to 3 colors, using multicolor severely limiting gun size, or some creative combination of both. But I'm willing to give it a try anyway.

[Tsak]

Originally Posted by KK/Altair

Another thing is, that a lot of people keep questioning me how using sprites could improve the situation, which would give the gun its own custom palette. I'm not completely sold on this solution, because it requires either limiting gun to 3 colors, using multicolor severely limiting gun size, or some creative combination of both. But I'm willing to give it a try anyway.

4 attached sprites (64pixels wide altogether - 16 colors each) is pretty fine I think to fit most vanilla Doom weapons, even if some tweaks are required for a few of them (the current handgun already fits with ease f.e. and probably so does the shotgun).
Weapons can then have their own palette which will make the game much more colorful overal. The color slots that are currently held by the guns will also be freed to be used in the level itself. And using hardware sprites might also free up resources (correct?). This seems to me like a massive win overal

-Edit 1: And to top the above, each individual weapon can also have it's own unique color palette, given the weapon change is gonna work like in Doom (move old weapon down, move new weapon up) as you could do then a sprites palette swap once the weapon to be changed is off screen.
-Edit 2: In addition colors used for levels and enemies are currently drastically limited (per level) because you need to keep the color palette coherent throughout the game so as not to mess with the rendering of your weapons (which remain the same). So there's not much room for level palette changes really. Making the weapons sprites will -at least- alleviate this restriction as then you can freely change the palette of the surroundings without affecting your weapons.

[rothers]

I think I can manage with 3 colours mostly, I'll see what I can do. I might do one attached and the rest 3 colours. Guns tend to use the same colours. I might do a separate sprite for the gun fire.

[d4rk3lf]

Originally Posted by KK/Altair

No - I'm more an engine guy. I like making games and maps, but technical aspects will be my main focus here (including core gameplay). After all, if stories were my main focus, I wouldn't have picked Doom, right?

I understand completely.
Just, understand, it would be pity to have such amazing technical game, without nice campaign. Imagine Wing Commander with poor campaign story.
I really hope, once you make 95% of the engine ready, to have a little thought about it, and of course, I'll be willing to help, if you need help on that.

After all, I think nice story and missions could motivate you further. For example, you wanted something unexpected to happen (something little bit different then grabbing a red key for red door), and then you think a way on how to solve the technical part within the engine.

Looking forward for next video.

[KK/Altair]

4 attached sprites (64pixels wide altogether - 16 colors each) is pretty fine I think to fit most vanilla Doom weapons, even if some tweaks are required for a few of them (the current handgun already fits with ease f.e. and probably so does the shotgun).
Weapons can then have their own palette which will make the game much more colorful overal. The color slots that are currently held by the guns will also be freed to be used in the level itself. And using hardware sprites might also free up resources (correct?). This seems to me like a massive win overal

I'll have to check exact dimensions. Each weapon except pistol has quite a wide base, but some of that is off screen and never visible. I'd have to check carefully exactly how far down each frame can be displayed (separately, because frame 0 swings when player walks, and firing frames recoil), clip the graphics and see real width.

Also the win with sprites is not that obvious, because the DMA steals extra bus cycles.

I think I can manage with 3 colours mostly, I'll see what I can do. I might do one attached and the rest 3 colours. Guns tend to use the same colours. I might do a separate sprite for the gun fire.

Yes, all the options give some room for creativity. Also you can easily end a sprite and reuse it during another scanline on a different position - which I expect to be essential for shotgun loading frames.

Just, understand, it would be pity to have such amazing technical game, without nice campaign. Imagine Wing Commander with poor campaign story.

And imagine Doom without campaign story... oh, wait...

Just joking. But as I've stated before, as soon as I manage to get the toolchain into somewhat usable shape, I'm all open to start some kind of modding community and hopefully we all could collaborate on something interesting. Because not only I don't consider myself a good storyteller, but the scope of making such a game on top of the engine simply feels beyond my time capabilities. So everybody would be better off with other people making maps and me finally implementing these variable-height floors and stuff.

After all, I think nice story and missions could motivate you further. For example, you wanted something unexpected to happen (something little bit different then grabbing a red key for red door), and then you think a way on how to solve the technical part within the engine.

My problem is that my mind is constantly flooded with tons of completely new ideas (not related to this project) and work on videos feels more like work than fun, so I have to push myself to move forward with this all. But I imagine sharing progress is the only way to get visibility and start some kind of community, so hopefully it'll be easier in time.

Looking forward for next video.

Soon. Sadly, I've got sick (common cold, fortunately), so can't record the few missing voiceovers for the intro.

[Gorf]

Originally Posted by KK/Altair

Also the win with sprites is not that obvious, because the DMA steals extra bus cycles.

But only from Blitter and not from CPU

[utri007]

Wondering how near your are to get playable demo out?

[ma693541]

@utri007, I wonder that too. I will gladly pay €25 for the finished game. This game rock.

[roondar]

Originally Posted by KK/Altair

Also the win with sprites is not that obvious, because the DMA steals extra bus cycles.

Sprites are extremely cheap though, if you don't need to dynamically alter the imagery and instead stick with pre-determined animations they're by far the cheapest way to draw anything on the Amiga.

Of course, if you need to start masking stuff in the sprite that all changes, but if all you want is overlay the sprite on a certain part of the screen it's really quite effective. Even better would be if it were to be possible to cheaply* avoid drawing the pixels behind the non transparent parts of the sprite (not just not to the chunky buffer, but also not to the bitplane one so essentially avoiding part of the C2P). But that's something that would be very dependent on how the engine works so I don't really consider myself qualified to argue that it is easy or possible

Anyway, the above are just some ideas. Hopefully they're helpful. If not, well the game as shown is already quite impressive as is

*) I'm thinking about something like a rectangle that isn't drawn to or something like that, masking is probably too expensive?

[KK/Altair]

But only from Blitter and not from CPU

CPU can use any available cycles, just not two consecutive ones. So if both Blitter and Sprite DMA are active, CPU has to share bus with the Blitter. Without sprites CPU would just delay one cycle on first clash with the Blitter, then share the bus perfectly until display DMA kicks in (which makes CPU again delay one cycle and start sharing cycles with Blitter).

Wondering how near your are to get playable demo out

Few more videos and demo should be out. I'll also be probably releasing another version with much bigger map at the same time for a small motivational fee.

@utri007, I wonder that too. I will gladly pay €25 for the finished game. This game rock.

Finished game is a looooong waaaaaay ahead. And it probably won't happen without community support.

Sprites are extremely cheap though, if you don't need to dynamically alter the imagery and instead stick with pre-determined animations they're by far the cheapest way to draw anything on the Amiga.

So you'll be glad to know that somebody already volunteered to make dedicated weapon sprites for this game. Based on FreeDoom ones, but hand-pixeled to look best while obeying sprite limitations.

Even better would be if it were to be possible to cheaply* avoid drawing the pixels behind the non transparent parts of the sprite

Each logic screen column has vertical Ymin/Ymax which limits the drawing. This is implemented for easy clipping of things drawn behind doors, ceilings, or even floor color splits. So the weapon shape could be cut out quite precisely. There are two considerations, though:
- if weapon is ready to fire, weapon frame can be changed to firing one at the very last moment (to reduce latency) - so we can only skip drawing the common part of current frame and first firing frame,
- wall rendering uses simplified logic for first pass, which skips clipping by Ymin/Ymax and draws just full screen - not drawing under weapon would require disabling this optimization and prformance could be worse in the end

(not just not to the chunky buffer, but also not to the bitplane one so essentially avoiding part of the C2P)

C2P is done on Blitter and Blitter loves full-screen rectangles. I think any saving under weapon would be not worth breaking the simplicity of current full screen C2P implementation. Note that CPU logic for determining how to skip a part of C2P is not free.


Anyway, next video just needs a few touches now, so...

[roondar]

Originally Posted by KK/Altair

So you'll be glad to know that somebody already volunteered to make dedicated weapon sprites for this game. Based on FreeDoom ones, but hand-pixeled to look best while obeying sprite limitations.

Nice

Each logic screen column has vertical Ymin/Ymax which limits the drawing. This is implemented for easy clipping of things drawn behind doors, ceilings, or even floor color splits. So the weapon shape could be cut out quite precisely. There are two considerations, though:
- if weapon is ready to fire, weapon frame can be changed to firing one at the very last moment (to reduce latency) - so we can only skip drawing the common part of current frame and first firing frame,
- wall rendering uses simplified logic for first pass, which skips clipping by Ymin/Ymax and draws just full screen - not drawing under weapon would require disabling this optimization and prformance could be worse in the end

Well like I said, I really don't consider myself qualified to tell you if it would worthwhile to do. From my outsider perspective it just seemed like a potential positive effect on performance. Obviously I have no clue how many cycles your drawing code takes and even less how many cycles it would cost extra to "not draw" behind the sprites.

What I do know is how many cycles it costs to draw sprites to the screen vs pushing pixels with the Blitter and that's all that my thought process was based on. Real world is always more complicated

C2P is done on Blitter and Blitter loves full-screen rectangles. I think any saving under weapon would be not worth breaking the simplicity of current full screen C2P implementation. Note that CPU logic for determining how to skip a part of C2P is not free.

Fair enough, seems logical.

For the record though: I do know these are all compromises and that what I'm saying isn't "free". What I was wondering about/suggesting was that perhaps the overall result could be positive - primarily because the act of drawing a sprite to the screen itself is so cheap compared to using the CPU or Blitter to the same. If this is not the case for you, well then that's fine too

[KK/Altair]

Obviously I have no clue how many cycles your drawing code takes and even less how many cycles it would cost extra to "not draw" behind the sprites.

8 cycles flat color per logical pixel (2x2 quad of real pixels) and 16 cycles textured. Not much, especially considering more often than not weapon will be obstructing untextured floor, so I expect savings to be less than cost of logic required to implement them.

For the record though: I do know these are all compromises and that what I'm saying isn't "free". What I was wondering about/suggesting was that perhaps the overall result could be positive - primarily because the act of drawing a sprite to the screen itself is so cheap compared to using the CPU or Blitter to the same.

Exactly. I've already tried quite a few "optimization" ideas which turned out not to be optimizations at all. But every idea is worth considering because even small optimizations add up.

[roondar]

Originally Posted by KK/Altair

8 cycles flat color per logical pixel (2x2 quad of real pixels) and 16 cycles textured. Not much, especially considering more often than not weapon will be obstructing untextured floor, so I expect savings to be less than cost of logic required to implement them.

8 Cycles per 2x2 pixel block is indeed quite nice. Having to add logic to check, well, anything at that speed is going to be costly.

Just for fun, I did a very rough back-of-the-envelope calc for how much you could save (let's assume all pixels are flat). This would then be on the order of 64x64 pixels=32x32 logical pixels=8192c minus sprite cost of 8*64*4=2048c. Which is a total of 6144 CPU cycles/3072 DMA cycles. That's really not a lot and that excludes the logic for actually skipping the pixels.

So from a performance perspective it's indeed probably not really worth the bother. That just leaves it potentially looking better, which can naturally be a good reason to do it anyway. But yeah, it doesn't offer as much performance as I'd hoped (if it would even offer any).

Exactly. I've already tried quite a few "optimization" ideas which turned out not to be optimizations at all. But every idea is worth considering because even small optimizations add up.

This is true, so I'll keep blundering around in this thread randomly suggesting stuff that'll probably end up not making things faster

[KK/Altair]

So from a performance perspective it's indeed probably not really worth the bother. That just leaves it potentially looking better, which can naturally be a good reason to do it anyway. But yeah, it doesn't offer as much performance as I'd hoped (if it would even offer any).

There will be savings, because Blitter no longer will have to blit the weapon (and CPU won't have to fire interrupt 4 times to setup all 4 weapon blitting passes).

This is true, so I'll keep blundering around in this thread randomly suggesting stuff that'll probably end up not making things faster

Keep at it! Even if 1 in 20 ideas turns out to be a working optimization, and even if it would save 1/10th of a frame, I would still consider all of this worth it.

[KK/Altair]

And the new video is out.
Have fun!

[ Show youtube player ]

[nikosidis]

So good to see updates to this fantastic engine Looking very good. Thank you for the video and keep on the great work.

[dlfrsilver]

awesome engine !