The Dawn of Kernel (Development)

[mr_lou]

Twitter videos work fine for me every time...

First time I tried clicking a Twitter video I think, and it didn't work.
Seems to work now though. So dunno.

[Gryzor]

May random snafu, ok

[reidrac]

Update time!

Disclaimer: the video doesn't capture 50Hz properly, also lots of debug are enabled and it looks "weird"; but the game is updating at 25 FPS.

What does the debug mean:

• Red boxes show mini-buffers in use, which is tiles affected by sprites being drawn. Take into account the red boxes are erased in moving sprites (remove the sprite and leave the background), so there are few things going on.
• The thin border lines (not very visible on the video) signal when an update happens on time (25 FPS!), thick lines or a complete red frame means the update was late (slow-down!). There are no thick lines on the video, meaning: yay!

https://twitter.com/reidrac/status/952689606255939584

I've been optimising few bits that were OK for my previous games but a waste of time in this one; that includes better batched draw (e.g. the engine fire on the player's ship, now is not a composition of player + fire) and few places where I was was being silly using CPU (e.g. even for fixed path enemies, I tend to be lazy and make them "smart", looking for obstacles, although I know the complete path when the map is loaded).

I'm also updating the HUD when the game isn't busy, so it may delay updating the score a frame or two, but it will never slow down the action.

Next thing is improving how bullets are drawn. For performance I don't support blitting arbitrary sprite sizes but a limited fixed set (8x8, 8x16 and 8x24). Bullets can be consolidated into 4x4, and I may even not use a mask because the shape is square-ish.

With that change I think I'll be really close to the performance that is required for the game, and 25 FPS.

(to be honest, this game would play just fine at 16 FPS; but now that I'm used to play it at 25 FPS, it would be hard to play it at a lower frame rate)

[reidrac]

Faster, faster!

I made an optimisation for "small sprites" (still masked), and it improved a lot.

The following video isn't amazing, but it shows a bit what I'm talking about (if you look closely). See previous post for information about the debug bits on the video.


https://twitter.com/reidrac/status/953411077278195712

If the sprite is between tile boundaries, that means more pixels to push and it'll be slower, but it reduces "worst cases" reasonably.

This engine isn't ideal for a shooter anyway, but as I said in my first post, I plan it to be more tactical than just pew-pew.

I'm going to leave the engine alone for now and start making new enemies and probably prototype the terminals; although that part is still one of the "unplanned" bits of this game.

Anyway, progress!

[GUNHED]

Any link to a video? Chrome doesn't pick up that tweet. 

[reidrac]

Any link to a video? Chrome doesn't pick up that tweet. 

You can watch it on Twitter, if you're interested. If you see the preview, click on the date and that opens the content on Twitter domain. If you don't see the preview, just open the link.

I guess is something related to cookies or anything like that.

[GUNHED]

Well, I don't use Twitter, Facebook and all that stuff... Would be nice it you post us a message as soon as you got a video up somewhere. 

[reidrac]

Well, I don't use Twitter, Facebook and all that stuff... Would be nice it you post us a message as soon as you got a video up somewhere. 

You don't need Twitter account to watch the video, as far as I know.

I won't upload the videos to anywhere else, for now. I'm sorry you can't be bothered to watch it on Twitter, is your call.

[robcfg]

Works for me on Chrome, maybe you adblocker is causing you trouble?

[Skunkfish]

The videos are working for me now embedded on the forum which is nice, not sure what changed as they weren't before!

[Gryzor]

They were always here Perhaps connection to Twitter was slow and so the page rendered without them or something, but it's been a while since they're available fully embedded

[reidrac]

Update Time!

Fixed a bug that I believe it's been there since my first game; I probably imported it from a speccy game when I started working on the CPC, BUT it only shows at 25 FPS (well, probably shows at 50 FPS too). So I guess is not a bug in my previous games because all of them run at ~16.6 FPS.

I made few changes in the map renderer, simplifying the shadows. I really like the shadows I made in Golden Tail, but it requires too many tiles, so in this one I'm using a different approach that, as a side effect, improves compression of the maps (so WIN).

I'm working on the first tileset, and planing some map design and thinking on some ideas for the core gameplay.

kernel-tileset.png
(552.19 kB, 1173x880 - viewed 144 times)

[ervin]

That  is looking fantastic.
I love those glowy red-bullet-things in the top right corner. Very very nice pixel work.

Just wondering - what was the bug that is only visible at 25+ fps?

[reidrac]

That  is looking fantastic.
I love those glowy red-bullet-things in the top right corner. Very very nice pixel work.

Just wondering - what was the bug that is only visible at 25+ fps?

It is related to the code that tracks time to enforce the specific number of FPS. There's a divider ; with 16 FPS that divider is 3, and it was working fine, but it didn't work with 2 (50 / 2 = 25 FPS), making some updates longer and making the animations quite choppy.

[ervin]

It is related to the code that tracks time to enforce the specific number of FPS. There's a divider ; with 16 FPS that divider is 3, and it was working fine, but it didn't work with 2 (50 / 2 = 25 FPS), making some updates longer and making the animations quite choppy.

Ah, ok... very interesting.
Do you do that to stop the game going too fast when there is less stuff moving on-screen?

[reidrac]

Ah, ok... very interesting.
Do you do that to stop the game going too fast when there is less stuff moving on-screen?

Yes, something like that. The game updates state and redraws every other vsync, instead of 50Hz.

Without tracking time I wouldn't know how to make it constantly smooth. No all the updates require the same CPU time.

[Gryzor]

How I love your pixel style...

[reidrac]

Quick update

I finished integrating Arkos 2 in my code and... well, I'm stupid. All my efforts to get things playing smoothly at 25Hz are just not enough, because I didn't take into account the CPU cycles required by the music and effects.

This is not all bad news, Arkos 2 is amazing, and I hope I'll show in the game with better music than usual; but I need to think how I can make it play smooth now.

I'm using the lightweight player and I still need to spend more time reading the code. I did the conversion to SDCC assembler (that is a bit "special"), but perhaps I can find ways of reducing the CPU use.

Anyway, this means that the game will have sound soon. Not sure if I'll be able to keep it running at 25Hz, though.

[ervin]

Quick update

I finished integrating Arkos 2 in my code and... well, I'm stupid. All my efforts to get things playing smoothly at 25Hz are just not enough, because I didn't take into account the CPU cycles required by the music and effects.

This is not all bad news, Arkos 2 is amazing, and I hope I'll show in the game with better music than usual; but I need to think how I can make it play smooth now.

I'm using the lightweight player and I still need to spend more time reading the code. I did the conversion to SDCC assembler (that is a bit "special"), but perhaps I can find ways of reducing the CPU use.

Anyway, this means that the game will have sound soon. Not sure if I'll be able to keep it running at 25Hz, though.

How are the sprites being drawn?
Are you using an optimised asm routine, or a function provided by a framework you're using?

Also, the code that you've written that determines which parts of the screen need to be redrawn - is that code in C or asm?
I've been working on a little prototype of large sprites, and the code that determines how much to redraw makes a noticeable difference to performance, once optimised.

[reidrac]

How are the sprites being drawn?
Are you using an optimised asm routine, or a function provided by a framework you're using?

Also, the code that you've written that determines which parts of the screen need to be redrawn - is that code in C or asm?
I've been working on a little prototype of large sprites, and the code that determines how much to redraw makes a noticeable difference to performance, once optimised.

It's all ASM; all my game engines are like that, I only write high level logic in C (and very often I end converting that to ASM too, once I proved the idea works).

I'm working on small optimisations and I'm getting some cycles back, so I may get there. I still have few options left (like make the bullets more "blocky" and don't use masked sprites for them).

Is not as bad as I though, but the audio player is definitely using a good chunk of CPU. At the moment I'm using 25Hz for the audio, meaning that I can update the sound every other int (and not the same one I use for drawing). That definitely helps!

[Targhan]

Is not as bad as I though, but the audio player is definitely using a good chunk of CPU. At the moment I'm using 25Hz for the audio, meaning that I can update the sound every other int (and not the same one I use for drawing). That definitely helps!

You can also cut the player in two: the code that sends the data to the PSGs can be called one frame out of two. This will "smooth" the consumed CPU.

[reidrac]

You can also cut the player in two: the code that sends the data to the PSGs can be called one frame out of two. This will "smooth" the consumed CPU.

I think I know how to do that, it is a brilliant idea. Playing at 25Hz is perfect. Thanks!

[reidrac]

Update time!

I've implemented few improvements on the engine itself:

• Small optimization by adding support to erase "small" (4x5) sprites; this is for the bullets.
• Split the Arkos player "play" in two: prepare frame and write to the PSG; so I can run them in different interrupts (I play the music at 25Hz).

Both seem to help, but is still not good enough. It all depends; with Arkos player on, trigger happy and few enemies; there will be some slow down when the bullets aren't tile aligned and there are explosions, etc.

I'll think about this further on; perhaps I may go back to the big-buffer memory-hungry engine. I still have one last idea to try that is basically stop using masked sprites for the bullets, and I'd like to experiment with some ideas to allow the engine to catch up minimizing the slowdown.

For now, I'm continuing with the game. I'm implementing the secondary weapons now. You can see the missile in the following video.

Usual disclaimer: the video was captured from an emulator and encoded to be shown on Twitter, it is not an accurate representation of the game updating at 25Hz on the real hardware.


https://twitter.com/reidrac/status/965245408829063168

[Gryzor]

Still looking great... can't wait to play it - thanks for the updates!

[Targhan]

Did you try using the AKY player? It is waaayy faster, but the music will take more memory, but maybe this will suit your needs. There is no sound effect for this player, but the next version will provide a stand-alone sound effect player, so mixing both shouldn't be too hard.