churnedgodotdev
churnedgodotdev on Hacker News
Also, George R. R. Martin uses WordStar 4.0 on a DOS machine:
https://www.cnet.com/culture/george-r-r-martin-writes-with-a-dos-word-processor/ Twitter acting by itself to suppress free speech is not
a 1st amendment violation, but acting under orders from
the government to suppress free speech, with no judicial
review, is
https://twitter.com/elonmusk/status/1598853708443357185Okay, that makes sense. The video on the linked Blender Apps page shows this really simple app where one drags models around and then drags materials onto the models to give the model that material. So something simple like that would work better in Godot. But Blender's 3D modeler is way more powerful than Godot's but has a very steep learning curve so distributing a simpler version of Blender's modeler could definitely make sense.
- Godot is great at importing Blender models/scenes.
- Blender is GPL, Godot is MIT.
- Godot produces much lighter .exe files. Blender Apps are at least 200MB.
- Godot has web export, too.
Godot still has stability issues that can affect larger projects (presently over 7000 open issues on Github[1]) but for smaller demos and art things Godot usually is pretty solid.
I hope Gen Z soldiers don't have this attitude.
[Mortar round blows off leg of Gen Z platoon grunt.]
"OMG! Mortar rounds are SO UNFAIR!" Let's sign a change.org petition demanding mortar rounds only emit harmless pink smoke. If we end up with pink smoke in our foxhole we can demand more time to dig a deeper, better concealed foxhole.
More recently, you can use Frama-C to constrain allowable sequences of 0's and 1's for C types and formally verify correctness.
In Ada since 1983 you can, e.g, declare your own 8 bit signed symmetric type without the wart -128 like so:
type Sym_8 is new Integer range -127 .. 127;
Then this fails at compile time: My_Signed_Byte : Sym_8 := -128;
SPARK can prove all execution paths through your program are free of such constraint violations. This means safe SPARK code can disable runtime checks and run faster than the safest Rust/Zig dev settings, which insert runtime checks for over/under flow.In Frama-C, say you want a function that returns an absolute value. This function will fail to verify:
/*@ ensures (x >= 0 ==> \result == x) &&
(x < 0 ==> \result == -x);
assigns \nothing; */
int abs (int x) {
if (x >=0)
return x;
return -x;
}
It fails to verify because you might have x==INT_MIN. So this will verify: #include <limits.h>
/*@ requires x > INT_MIN;
ensures (x >= 0 ==> \result == x) &&
(x < 0 ==> \result == -x);
assigns \nothing; */
int abs (int x) {
if (x >=0)
return x;
return -x;
}Oh, time to go down a low-latency rabbit hole. Start here:
https://raphlinus.github.io/ui/graphics/2020/09/13/composito...
Some key mentions: Windows has a hardware overlay API. A hardware overlay is why the OS mouse cursor renders with low latency even with 'vsync on'.
For fullscreen, the ultimate in tear-free low latency is beam racing. Search for 'blur busters beam racing' to go down that rabbit hole.
1. Use 'desynchronized', e.g. canvas.getContext("2d", { desynchronized: true });
2. Instead of using requestAnimationFrame(), draw as soon as a move event is received.
Here's a paint app that uses techniques 1 and 2 to achieve much lower input lag drawing the pen strokes that chase the cursor:
Two other tricks to be aware of:
3. [Chromium only.] Use 'pointerrawmove' to get move events as soon as they happen instead of waiting for a big bunch of coalesced moves to all arrive after a delay.
4. Drawing where the cursor is predicted to be in order to compensate for lag works well during smooth cursor/pen motion. For example, the Windows Snip & Sketch tool actually renders the line you are drawing in front of the direction your pen tip is detected traveling because when using, say, a Microsoft Surface Pen on a physical Surface Pro screen the line being drawn would otherwise noticeably lag behind the physical pen tip (especially on a 60Hz screen) unless this predictive trick is used.
Finally, be aware of open Chromium issue #992954. When the devtools are open [F12], coalesced events aren't used so you get lower input lag but more events to pump (like 'pointerrawmove'). This bug is maddening because it depends on whether or not you have the debugger open!
https://bugs.chromium.org/p/chromium/issues/detail?id=992954
https://tidbits.com/uploads/2019/04/T2-hiccup.jpg
This image was linked from this article:
https://tidbits.com/2019/04/05/what-does-the-t2-chip-mean-fo...
https://ecology.wa.gov/Spills-Cleanup/Contamination-cleanup/...
For almost 100 years, the Asarco Company operated a copper smelter in Tacoma. Air pollution from the smelter settled on the surface soil of more than 1,000 square miles of the Puget Sound basin. Arsenic, lead, and other heavy metals are still in the soil as a result of this pollution.
https://github.com/godotengine/godot/issues
Every single time a Godot bug bites me I find that a bunch of other devs reported the issue more than a year ago but no one has had time/money to fix the issue. For example, I was just bitten by #45628 opened Feb 1, 2021: https://github.com/godotengine/godot/issues/45628
When implementing controller support for a top-down Zelda-like game, it's normal to allow either the d-pad or left analog stick to control direction. But if you enable both at the same time in Godot then d-pad inputs cause your character to "freeze".Eventually Godot will stabilize and be to game engines what Blender currently is to 3D modelers. If I had time to learn the Godot C++ code I would volunteer to help but I want to actually make video games instead of working on an engine.