Second Hand Computer 0.18.0 - THE ROGUE UPDATE is out!
As promised yesterday, this version contains FT-Rogue, a simple roguelike game written in Funscript/Lua, with full source. I wanted to experiment with what more could be done in SHC, and what better way than a simple roguelike.
#GameDev #IndieDev #Roguelike #FantasyComputer
https://funtimeelectrics.itch.io/second-hand-computer/devlog/1360684/shc-0180-the-rogue-update
@vampiress Thaks for the v-sync fix!
I just hit a crash (see attached image) while scrolling through the man page. I had the down arrow key held so maybe a keyboard buffer overrun? IDK.
@Farbs No. None of my test machines run that slow. What are you running it on?
Also - you can turn on the fps counter to see if the whole renderer is running slow or not.
under $engine in the config file, add
option_gfx_show_fps=true
@vampiress
Keypress Sounds:
On both times I've seen this (the second time was holding to walk in ftrogue.scr)
Now that I've fiddled with turning keypress sounds on and off I don't seem to be able to reproduce it.
Machine:
Windows 10 Home 22H2
16GB RAM
2.70GHz CPU
GTX 1060 (6GB) + Intel HD Graphics (128MB)
I haven't checked which GPU it's using.
FPS:
Solid 60 when idle but spikes as low as 1 on these events.
Bonus windows bug:
It's always fullscreen regardless of the option setting.
@vampiress Oh also, adding this near the end of ftrogue.scr improved performance drastically :)
-- dodgy write buffering as a performance hack
_written = {}
function draw_tile(x, y)
local c = tile_char(x, y)
if _written[x+y*WIDTH] ~= c then
move_cursor(x, y)
write(tile_char(x, y))
_written[x+y*WIDTH] = c
end
end
function full_draw()
for y = 0, MAP_H - 1 do
for x = 0, WIDTH - 1 do
draw_tile(x, y)
end
end
end
@Farbs I've had one or two crashes during testing with that precise vector error, and it was related to the key press sound. Near as I could tell (it proved impossible for me to reproduce intentionally) when you held down a key, and there was a system stutter, it'd try to play MANY sounds at once, fail, but fail in such a way that the system thought it had succeeded, and they needed to be removed from the playing sounds stack.
Which things go slow? It sounds like it's full screen re-draws that are slow. I'm not sure why they're slow on your system and not others though.
@vampiress Yeah, it's interesting!
Every text draw is a bit slow, but specifically opening the help menu from the left and clicking on the scrollbar is very slow, and as I uncover more of the map in ftrogue each step is slower.
It's interesting that scrolling through a man page is much faster than clicking on the help scrollbar.
Is man batched in a way that the help window isn't? One line at a time vs one character at a time maybe?
@Farbs It's SDL, I don't write that low.
Though, I just saw this - it's possible it's not batching the draws at all, which might explain a lot.
I will have to look at updating my SDL3 version.
@Farbs Actually I'm now wondering if that is indeed the issue.
@Farbs I just upgraded the engine from SDL SDL-3.2 to 3.4. I can't see any performance difference at my end, but allegedly it DOES batch things properly now.
Next update will have that in - curious if it makes an impact on performance for you.
I get almost the exact same ~210fps without vsync enabled on my dev machine with both versions, so I guess that just isn't the bottleneck on my system.
@Farbs Okay you just sent me down a rabbit hole.
I threw in a bunch of optimisations. One issue I found meant that every glyph update was hitting disk read access.
Again, no noticeable speed bump on my test machines here but they always ran fast.
Anyway, 0.18.1 will have a bunch of speed optimisations and the SDL3 update. Curious to see how that goes for you!
@Farbs Well they're rendered differently. The terminal uses its own glyph rendering system with an 80x25 grid of sprites that either exist or don't.
The in-window help UI is entirely different, in that it's just regular sprites using the window as a parent, like any other UI system.
There are more sprites in the Window though.
It sounds like adding/removing glyphs is slow on your system. I'm not sure why though - it's just SDL draw calls.
Elissa
Colin
Farbs
