It's interesting that we're so used to the GUI buttons having that specific behavior of only triggering when releasing, even if you exit and enter the button area while holding the mouse button down, etc.
IRL 99%+ of buttons work by just doing the thing as soon as you press them. But a button that works like that in a GUI would feel wrong.
> But a button that works like that in a GUI would feel wrong.
No, it doesn't. It feels way more responsive.
My pet peeve is "stopwatch apps" which trigger on release instead of on press. When timing something where fractions of a second matter, most people won't realize that it triggers on release and tap down when they want to start / stop, adding some arbitrary delay until they actually release the button.
No, even for stopwatch, trigger on release is the correct choice, as it’s more precise.
When tapping, I have to see, or in case of watching for some event to happen to stop the time, feel/guess when exactly the distance between screen and finger approaches zero. With a stop button triggered by release however, I can just calmly rest my finger on it and raise when the event happens, without any guesswork.
How does a real stopwatch work? Hint: it starts/stops on press, not release. So that's what the app should do, to map with prior expectations.
"Nobody uses real stopwatches anymore" might be somewhat true, but in athletics training they still do, and it just shows that it's not possible to adequately reproduce a thing on a touch screen and have it be as functional as the real item. A stopwatch app on a phone will always be a poor substitute for a real stopwatch.
Yes, but on a real stopwatch, or on a computer mouse, you can rest your finger on the button with almost but not quite enough force to actuate it, and activate it with a press.
On a touch screen you have to hover your finger over the button and move it down some indeterminate distance to actuate the button. The equivalent to the above example for a touch screen is to activate on release, as you can rest in a state “ready to click” just like on a physical button that way.
Interestingly the "activate on release" logic was implemented in computer GUIs long before touchscreens were common, used purely by mouse-click (a physical button).
What's the experience with Font Forge for creating pixel fonts? I have never used it but I always assumed that a font creation tool made for arbitrary style "vector" fonts is probably unwieldy if all you want is square pixels, to be rendered pixel-perfect, etc.
It's pretty much MS Paint type experience. You get a grid and color pixels black or white. But you can move up/down grid sizes automatically and then you get to fix it at different grid sizes.
I made PixelForge [0] a while ago just for creating pixel fonts and being able to export to TTF. I had it semi-abandoned for a few years, but I'm about to release a new version in the next few days! [1]
Maybe because it sounds like a question on a 10th grade exam. It’s demanding and didactic, both in framing the question and the form of the expected answer.
Having lived with a cat that had been in the streets for months before being adopted, and a different cat that had always lived indoors, I think that's the main difference in behavior regarding safety.
The one that had had experiences outdoors was more obsessed with food (to the point of eating everything fast until vomiting sometimes), scared of noises and sudden movements (going to hide in safe places), even from the people that had been living with her and caring for her for years. She was sweet and loving, but the streets never left her.
The one that had always been indoor was friendly to everybody, never super scared of noises, super curious, could regulate food properly (eating piecemeal throughout the day), etc.
There's always differences between cats' personalities, and this is a small sample, but it seemed significant and made sense given their experiences and possible past trauma.
The quick way I'd solve that is to open any program window (like calculator or whatever), mark it as being on top of other windows, and resize it and place it on top of that area. It seems quick and easy enough for the effort.
It reminds me a bit of this post from the Facebook engineering blog (2015) [1] where they discuss embedding a very tiny preview of images into the html itself so they show immediately while loading the page, especially with very slow connections.
Any interesting insights about using Godot with C#? I love C# and I'm happy using it in Godot even though it's not as seamless as in Unity: in Godot 4 we still can't export to Web if the project is C#, and there's the whole conversion between C# types and Godot types that adds inefficiencies and extra allocations, etc.; it feels like it's a second-class language in Godot.
I'm always interested in seeing what people find when developing larger projects in C#.
The founding developers were all software engineers with .NET experience, so it was the natural choice even though at the time it was Godot 3.x with Mono. I had used Unity before but not Godot. The project is structured as mostly plain C# DLLs with a relatively thin Godot UI layer controlling it, so the Godot type system is fairly encapsulated. We haven't really seen any issues with those decisions beyond just working out the communication between Godot and DLL. But again we were just working from what we knew so I can't really say if this was the best way to go about it.
We were building on C# Godot and I think it is a second class citizen in the sense that 1) you can't export to wasm and 2) they are moving the interface to be handled by gdextension.
That said, I think once you get the gist of it and understand the landmines, it is really nice to use vanilla dotnet rather than unity's fork.
I have this principle of "5% scripting". If the high level scripting on top of C++ consumes about 5% of frame time, then the language of the script does not matter.
IRL 99%+ of buttons work by just doing the thing as soon as you press them. But a button that works like that in a GUI would feel wrong.