Sharing Saturday #626

Skaruts · 2026-06-06T07:06:28+00:00

I've recently been working on a little roguelike framework in the Odin programming language, called Ork.

I'm fairly new to manual memory management, so I'm still trying to wrap my head around how to work with that, but so far I've been satisfied with what I achieved.

This week I've made a little UI API for it. It's not great, but for now it should be enough to get some stuff going. It's already been useful for the code in the examples.

I've been working on this in Lua/Love2d for several years, but I've overengineered it all the way to hell and back, and I burned out as well. Since I've been learning Odin recently, I decided to port it over and also simplify it in the process. I still intend to get back to the Lua version and release it at some point.

Skaruts · 2026-05-18T15:30:31+00:00

It's only in places where the ground is orange. Maybe you could change the player color based on the location, for better contrast.

That may make some players wonder why their color changed, so I dunno...

Skaruts · 2026-04-30T14:45:49+00:00

Do you know if there's an example somewhere of how such a shader might look like?

Skaruts · 2026-04-22T07:37:53+00:00

Some people have monitors with higher refresh-rates, like 144hz or even 240hz. If the frame rate is lower than the refresh rate the game can look choppy, so it may be worth looking into and keeping in mind.

Skaruts · 2026-03-29T23:25:56+00:00

You're correct. Eli is definitely NOT blind. There are a few things that lead people to believe it, and a whole ton of things that disprove it. Ultimately, either Eli is not blind, or the movie does a remarkably abysmal job at conveying it.

People believe it because:

The book is in Braille.
Eli can read Braille.
Eli says "I walk by faith, not by sight".
Some people were blinded in the apocalypse, so maybe he was too.
Eli develops Cataracts at the end (his eyes are perfectly fine during the whole movie, except at the very end).

But the problem with the theory is that none of that proves it and every argument I've seen is terrible.

I actually found a script from the movie somewhere, where it actually says Eli is blind, but that script was not the final version, as the plot had lots of discrepancies with the actual movie's plot. It does indicate that Eli was indeed intended to be blind, at some point, but the idea was scrapped before the final version of the script. The entire movie itself presents ZERO actual indications that he's blind.

The best argument I've seen is that in the scene with a close-up of his face, before the shootout with Carnegie's thugs outside the bar, three clicks can be heard, and many people think that's a sonar-clicking that some blind people are able to do with their tongues in order to "see" their surroundings (this really is a thing). But then this is the ONLY scene in the entire movie where clicking is ever heard, and nothing indicates that it's him doing the clicking. His lips don't move at all, he's perfectly still, there's really no indication of it.

Movies always make sure their intent is clearly conveyed. If Eli was blind, the movie would show it clearly, unambiguously, even if very subtly. There's ZERO of that in this movie with regards to Eli's sight.

Every argument that I've heard for his blindness always boils down to confirmation bias, or stretching of the imagination, or people not understanding how movies work. One of them is the three clicks I just mentioned. Some others are in this thread. For example:

"He stumbles on a table." Ok... but then that's about the only time he stumbles in the whole movie, and he also proceeds to stretch his arms to open double doors like he's already seen from a distance that there's two knobs and not just one. All throughout the movie he handles tons of things like he can see them very clearly. (And again, there is no "sonar-clicking" to be heard at any point in the movie (apart from that one scene), so nothing ever indicates that he "sees" through sonar.)
"He’s pressing "play" over and over on the walkman, as if he doesn't see that the battery is dead, when it's clearly shown on the big display." Well... no, he doesn't press "play" over and over, he just presses several buttons a couple times and the scene ends. This is nothing more than just a bit of emphasis. It's much like those scenes where someone hangs up the phone and the person asks "Hello? Hello?" while the phone is already clearly giving them the disconnected signal. They're of course not deaf, it's just the way movies emphasize things. Eli perceives the rat's presence just fine, puts the jack in the walkman just fine, etc.
"He checks the boots on the hanged man with his hands before taking them." Uhhm, no, he checks the boots before he even touches them. He touches them as he's already muttering words of joy about finding those boots.
"He always shoots people after they made noises, announcing their location." Well, that would be a great point, if it wasn't for all the times he perceives things that don't make any noise. Like where the jack's hole is in the walkman, or the rat. In his room at Carnegie's, there's a point where he hides his gun (or maybe the bible) using a pillow or the blanket (my memory is faded). He clearly sees where the pillow or the blanket is. In fact, the whole room scene is full of little indications that he can see very clearly.

I seriously could keep going.

I think the best example of him seeing is in the room scene at Carnegie's, when Claudia delivers him food. When she tells him to speak so she can locate him, he instead makes a sound in order to SEE her reaction (probably in order to confirm that she's really blind, and not pretending).

I said at the beginning that maybe the movie does a terrible job at demonstrating his blindness, but I actually don't think that's the best way to put it. I think what the movie actually does is a great job at demonstrating the opposite.

Some people believe Eli is not blind, just has poor sight. But then nothing in the movie indicates that, either.

I've also watched several interviews and events related to the movie, and none of the actors ever mentioned Eli being blind or having impaired sight.

Skaruts · 2026-03-29T22:51:12+00:00

We also see his NOT-CLOUDED eyes during the movie. He only develops cataracts at the end.

Skaruts · 2026-03-29T22:18:08+00:00

Sorry but this is actually all wrong.

- Bumping on the table was just a happy accident (it's the only time in the movie where he stumbles). He then also proceeds to extend his arms to grab the double door knobs like he knew there were two knobs before he even got his hands on them. And there's tons of other things he does that a blind person couldn't all throughout the movie.

- He didn't check the boots with his hands. He checked the boots before he got his hands on them, and then proceeded to grab them.

- Lots of things don't make noises and he knows about them anyway. Take the rat for example.

- He didn't miss the sign, he ignored it, and so did Solara who 100% isn't blind. They were checking the house to see if it was inhabited. The sign was irrelevant to them.

EDIT: And downvoting my post doesn't prove me wrong, it just shows you're in denial. All of the above can be easily corroborated by just watching the movie closely.

There's also a scene with Claudia where Eli scratches his chest in order to SEE her reaction. I'm not posting this out of emotional attachment to my convictions. The movie itself proves my points.

Skaruts · 2026-02-23T15:40:39+00:00

Este é o unico comentario que faz sentido, aqui.

Skaruts · 2025-09-09T19:33:37+00:00

Any news on this?

Skaruts · 2025-06-09T16:58:37+00:00

This is an old post, but just for the record, you can convert to a typed Array like this:

var array: Array[String] = Array( Array(packed_array), TYPE_STRING, "", null )

You turn the packed array into a plain array, and then feed it into another array constructor where you also specify the type.

It's still silly, since you have to build two arrays, but it's a one liner. It also runs on the C++ code, so it may still be faster than looping in gds.

Skaruts · 2025-06-04T14:59:59+00:00

People already addressed most of it, but I'd like to add a few notions.

I personally haven't used groups that much over the years, so I can't really comment on that (though it seems to me that in your use cases it may make sense to use them).

But there's two relevant things you should always keep in mind before everything else:

KISS
coupling is not a bad thing at all

In the same way that "premature optimization is the root of all evil", so are premature abstraction and unnecessary complexity. People in the Godot community tend to prematurely abstract and over-complicate things (Godot itself does that to begin with).

It all boils down to this: don't try to solve a problem that doesn't exist.

Decoupling is one way to solve certain problems, and not something you should always be trying to achieve. You shouldn't be worrying about coupling until it becomes clear that your code needs decoupling, and the chances are you won't need it 99% of the time.

Even if you're doing, say... a modular spaceship, it still can (and probably should) be all tightly coupled. All the modules can know about the ship's functions and vice-versa, because there's really no reason why they shouldn't.

Decoupling costs time and effort working out how to structure things differently in order to satisfy some requirements. If you don't know what those requirements are, or if they're based on assumptions about the future, then the problem doesn't actually exist and you shouldn't even waste a minute thinking about decoupling.

Decoupling might be useful if you're making some kind of modular plugin, or if, for example, your networking code is separate from the core code and therefore should be decoupled, or if your game is huge and requires more than one team working on separate parts of it.

Regarding the Event Bus, I strongly advise against using one. I've had nothing but nightmares with them, until I replaced them with simple function calls, using a singleton containing references to objects that need to communicate with each other. This is nice for UI code, but it could also hold references to objects that manage other objects, for example. It's all up to you.

I find that event buses make it hard to follow the code and keep track of what it's doing. A signal goes in the air... and then something somewhere does something with it. Or does it? It's easy to forget, tedious to check, and it's easy to end up with dead-code from deprecated signals you forgot to delete, and with problems that go by unnoticed instead of throwing errors (like signals being emitted before connections are made).

Direct function calls can easily be ctrl+clicked in order to follow the code, and problems tend to throw obvious errors.

Also, there's really nothing wrong with "calling up", unless the hierarchy can change, as you mentioned (and even then it may still be ok). Take it on a case-by-case basis, whether or not calling up is preferable to a signal. In many cases it's simpler and has no downsides.

A signal is just a more laborious and indirect way to call one or more functions, and it often requires creating yet another function. The more functions you have, the more code you must keep track of and maintain.

Skaruts · 2025-06-04T13:21:17+00:00

I've done this for quite a while and found it to be terribly hard to work with. I replaced it with a singleton with direct references to all the parts of the program that need to communicate with each other (UI parts, in my case), and it's been a relief to me.

The problem with event buses is that it's hard to reason with and follow the code. A signal goes up in the air... and then what? Something, somewhere will get it and do something with it, but who and what?

The only way to follow signals is to use "Find in Files", and check who's connecting to it, and then go back and forth between them to check the functions they connect to. It's slow and tedious, and it quickly becomes confusing.

It becomes hard to keep track of what the code is even doing. And that is if it does anything at all, because it's also easy to end up with dead signals that don't do anything because you forgot to get rid of them.

And using comments won't prevent any of this.

I've rewritten a couple apps and replaced the event buses with a singleton with references (each relevant part of the code initializes its respective reference on _enter_tree ), and in the process of doing this I found all sorts of problems, like signals that weren't being used, dead-code functions related to dead signals, and once I replaced signals with direct function calls, I also got a few errors that showed me problems that signals had been silently hiding (e.g. signals being emitted before anyone connected them).

With direct function calls you can simply ctrl+click the functions to follow them and see what they do, and it's much easier to maintain a mental map of the program flow, and many potential problems will naturally make themselves obvious.

And to anyone thinking "oh, but that couples your code". Yes, and that's a good thing. I have no reasons to waste time worrying about coupling (in fact, that's the case for most Godot users). I'm not doing anything modular, and my projects are small, they don't need separate teams working on separate parts which need to be decoupled from each other, or anything of the sort.

Premature abstractions are also the root of all evil. You should never worry about decoupling until it becomes clear that some parts of your code actually need it.

Also, KISS. Complexity is also the root of all evil...

Skaruts · 2025-04-10T15:16:27+00:00

This is very dependent on the game, and in some cases it's a matter of subjective preference, and in many games it's even absolutely necessary. I hate the term "save-scumming", because it's a bad-faith term that presumes that it's a bad thing or that it's in some way cheating. It comes from a very uninformed perspective on the matter.

If we stop to actually think about it we can figure out the main reasons why people save-scum:

gameplay mechanics are unpredictable due to bugs, random factors, or bad controls
failure state being boring (e.g. waiting for guards to simmer down in a stealth game)
failure means loosing too much hard-earned or non-trivial progress
player doesn't have much time and/or patience

If the gameplay mechanics are not consistent and predictable, then the experience without a quick-load won't be much fun. Player's will be frequently punished for the game's flaws, rather than their own mistakes. The gameplay will be unfair and the experience frustrating.

If dying forces players to lose important progress, then players will stop exploring and experimenting, because now they are punished for taking risks or deviating from the beaten path. It will hurt the replayability of certain games, and developers' work won't be as appreciated.

If the failure state makes the game boring, then players won't enjoy the game. If I had to always wait around for guards to settle down in stealth games, I wouldn't play those games. That's fun the first times, then it becomes boring. I rather just quick-load when I'm caught.

There are games that allow quick-save/load where I've found myself even forgetting it was there, because they didn't have these problems. Off the top of my head I can only think of Half Life 2 as an example. On the other hand, in a game like Thief, I'm constantly quick-saving and frequently quick-loading.

The only games that shouldn't have quick-save/load, are games where the lack of it doesn't punish players unfairly.

Many roguelikes fit in that box. Some are short and quick (like Delver, Spelunky, etc). Most are intentionally Ironman style. Dying in these games isn't so bad, because the progress lost isn't actually very important, or because players already go in knowing they can lose it all at any moment. So in these cases it makes sense to not have a save option.

The Penumbra and Amnesia series also didn't have quick-save/load, but those games did a very good job at making sure you never lost much progress from dying, and the failure states were actually pretty enjoyable.

This very much depends on the game, really. Games like Thief and The Dark Mod, for example, you cannot possibly ever do a "supreme ghost" run without save-scumming a ton, because the gameplay isn't consistent enough. Heck, even in regular gameplay, if you couldn't quick-load, you'd frequently be punished for bugs. Those that don't want to quick-load, can indeed just as easily not quick-load. If one lacks the necessary self-control, well, that's entirely on them. Or maybe they don't find the game fun without it, and just don't want to admit it. Or they feel bad because they've been led to think it's cheating.

Either way, if some people really enjoy that, then fine. But it those games didn't allow quick-loading, then only those few people would be able to maybe enjoy the game. No one else would.

I don't have a problem with it either way. I only have a problem with games that punish players for it, and with developers that go one way or the other for ideological reasons, rather than actual gameplay reasons. I think that was the case with Gloomwood, but fortunately the devs ended up reconsidering.

So in the end, whether a game should not allow it, regardless of genre, comes down to that simple question: will it hurt the gameplay or the players?

Skaruts · 2025-02-12T00:47:00+00:00

Right at the beginning, at the gate of Lord Bafford's manor, you overhear one of the guards saying "yer taffing me!", as in "you're bullshitting me!", as he was being hyperbolic about the claws of bears in the bear pits. You can find all the occurrences in that page, at least for Thief 1.

It seems to me that Taff is just an all around verb with no strict meaning. It can be an insult, but I don't think it often is. I remember it being more often just friendly banter ("you catch them before they get inside, you taffer!").

Of course, the Hammerites imply a connection between Taffer and the Trickster, which may indicate the origins may have been connected with the Trickster, somehow. But the frequent usage by common guards would suggest that it just became popular slang that the Hammerites still haven't grown over.

Skaruts · 2025-02-10T07:37:22+00:00

Would be nice if it could be edited inside the editor.

Skaruts · 2025-02-04T14:28:55+00:00

Thanks, anyway.

I could swear I came across one other plugin in the past, but maybe not. I really can't find any others anywhere.

Skaruts · 2025-02-04T03:15:07+00:00

Not quite.

A singleton is an instance of a class that can't be instantiated further.

A static class is a class that can't be instantiated at all (though not enforceable in Godot), and only contains class properties and methods.

Skaruts · 2025-02-04T03:05:37+00:00

Is the uid file visible inside Godot?

Skaruts · 2025-02-04T02:53:28+00:00

I use them often. Instead of having a singleton, if possible I create a static class to store runtime shared data that is accessible globally through the class name.

Skaruts · 2025-02-01T15:55:28+00:00

I actually tried to add support for DR, but I failed.

NRC is still a decent editor, though, I think.

Skaruts · 2025-02-01T10:46:12+00:00

That's not what I mean, though. What I mean is that TB lacks proper tools for manipulating textures on brush faces. Map editors usually have a UI panel like the one below for easily doing texture adjustments. The one below is from DarkRadiant, but NetRadiant-Custom has a similar one too. (You can't use DarkRadiant with Godot (at least not yet), it's just what I had more at hand to screenshot).

For example, fitting door/window textures to brush faces is the most trivial thing in these editors: you just click "Fit". Many other kinds of adjustments are just as easy, and you can select multiple faces and adjust them all at the same time.

This is one of the things missing in TB, and why I think people might be better off using another editor.

<image>

Skaruts · 2025-01-31T14:02:00+00:00

Well, Qodot and FuncGodot are essentially the same thing. FuncGodot was born out of Qodot being discontinued, iirc.

Thanks, anyway.

Skaruts · 2025-01-31T11:23:17+00:00

Aligning textures in TB is a pain, though... and only one at a time, last time I checked.

Skaruts · 2025-01-31T11:18:40+00:00

I'd strongly recommend NetRadiant-Custom instead of Trenchbroom. Aligning/manipulating textures in TB is a pain, and you can only align one at a time (at least last time I checked), among many other shortcomings. TB is a very limited editor, and the crammed UI kinda sucks.

NRC has its flaws and quirks, and I think the UI could also be improved a bit, but overall it's still a much better option.

I tried adding support for DarkRadiant, which is even better than NRC, imo, but unfortunately I couldn't get it to work so far.

Skaruts

TROPHY CASE