🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

If you want to redraw HUD part of screen, every frame, you basically lock yourself to 30fps

A topic by DagonDev created 78 days ago Views: 57 Replies: 5
Viewing posts 1 to 4

So I am trying to draw HUD just like it is done in need tilemap demo and if I want to redraw something from HUD space I am not drawing rest of the screen in that frame and vice versa.
My quick tests shows me that you can't draw both on same frame as it doesn't work.
I understand that every dynamic thing should be drawn with DrawSprite and not with redrawing tilemap, but I am trying to upgrade my logger debug lib (https://itch.io/t/79403/debugging-tools-logger) that would eat up sprite limit quite quickly.
Easy solution would be not to redraw HUD space every other frame, but... then you still lock drawing game space into <60 fps. What is the reasoning for how this works? And can I bypass this?

Right now the feature is experimental. Not sure I'm happy with how it works currently. To your point, it's not ideal. So the way I had envisioned this in its current implementation is that you don't redraw the display where the HUD is. Since you don't clear it, that pixel data is persistent from frame to frame. So you draw it once, then during the game, you just use sprites as stamps to change a few elements like numbers or icons. It will count against your sprite total which is a side effect. I may just open up drawing tilemap data multiple times in a single frame and you'll just have to work around any performance penalty.

The alternative, and what is closer to real hardware is to split the actual background draw per vertical scanline. I may allow a way of blocking off a range of scanlines. Not sure yet. But feedback like this is really helpful. Trying to find the balance between accuracy and ease of use. 

(Edited 1 time)

Tough decision. I understand you trying to balance between going old style and going user convenience, but from my personal perspective, this gets detrimental to end product.

Good way, for now, would be to allow all solutions you described so user can decide what works best for his/her game.

Because if you choose to use more lenient method, purists will be angry and if I you choose 100% true way of 8bit, it will throw away all those people looking for developing game in 2017 way with limitations. (like me)

Then, making several methods is very time consuming and prone to bugs...

This thread made me think about Game Creator and I moved it to separate thread: LINK.

hello, sorry to interfer it but after reading the whole thread, i remember of  a small well known fact among old devs team that i'm been reading or watch video: in devkit of each console gen, they tend to add one extra chip or other thing mainly used for debug like you tried to do there since a while. so, my suggestion is this:

why don't you create a dedicated dev chip for debugging part? once exported, the dev chip will be removed fully from the exported game :)

and also, check this wikipedia: https://en.wikipedia.org/wiki/... it will give you some idea of how different these dev console kit are... :)

This is a good idea. That is sort of what the Game Creator does with the editor. It exposes a whole set of APIs that are not part of the final game. Over time I'll continue to flesh that out more so it will be easier to debug games.

i'm glad you like this idea, i'm looking forward it then! :D