2D Vehicles(patkerr.co.uk) |
2D Vehicles(patkerr.co.uk) |
The Atari ST is in the news today on HN! (there was a TFA about the Atari Falcon, which was a really big Atari ST).
> .eyebrow, .label {
> font-size: 0.78rem;
> text-transform: uppercase;
> letter-spacing: 0.19em;
> font-weight: 750;
> color: var(--accent);
.--.
|/`-\
__ _( '\'
_.-' | __(,
.' _.-' \/ %;
/\.' / ;%,
\/ '.__.-' '#;
| / ;%,
\ || '`
\ ||
| ))
| ||
|__||_
| '.__)
'._)
Ran out of steam, I guess...
I don't mean to be... judgemental, but if you had the talent to go something like this, why devolve on the remake? One could think that a person with your level of skill would be one of the main vanguard for hand coding. Again, I don't want to be too judgemental, as I am not a great programmer and use assisted tools when planning and designing personal apps, but I am just curious.
I was a bit pushed for time, and didn't feel inclined to try making the diagrams myself.
Still, I agree that they're a bit "slop adjacent". However, I thought they would be better than nothing for someone trying to get their bearings.
I'd be ecstatic if more people used AI to share more cool things they've done. that'd be awesome. more of this blog post please.
I am the author of this thing, and I find your comment very amusing. ;-)
Seems the author chose option 2 and focused on the article instead.
This thread originated with one poster expressing disappointment that someone of the author's acumen would choose this path, and another poster asked why the author (or someone of their skills) should have chosen a different path. I weighed in with an answer to that question.
Obviously the author did not see things the way I suggested, or else the conversation would not have happened.
Also Physics for Game Developers (2001) had a hilarious chapter dedicated to car racing simulation. Most of the chapter is dedicated building the scene in a minute detail - for instance pointing out that the center of gravity of the car will change during the course due to fuel consumption - only to simplify and cancel out most things at the end to leave the reader with just a handful of variables.
[1] https://www.asawicki.info/Mirror/Car%20Physics%20for%20Games...
https://www.youtube.com/watch?v=I8GQCZgCNw8
I built an OpenGL car physics simulation as an undergrad as a project. It was very fun.
I would've liked to understand more about why it works the way it does, how it achieved the correct feel etc, not just regurgitate whatever the code does.
I would've liked to know more about how the author achieved what they did, not a blog post anyone with an llm could've written.
As I said in the summary article, the core is a "textbook" 2D rigid body simulation (the "Brick" layer), and the Car bit mostly a matter of deciding what forces are applied to the tyres.
In short, the tires "like" to go back and forward, but resist going sideways (relative to the direction they are pointing in).
The forces which are applied at the tyres are roughly equivalent to friction, but not quite (friction is stranger than people think, and is not actually very velocity dependent). In some ways my tyre forces actually behave more like a form of "viscous drag" actually. I knew this was a bit dodgy at the time, and it was a sort of conscious "hack" that was chosen to produce "playable" behaviour as simply as I could.
That being said, AFAICT, the diagrams are also basically irrelevant to the article in its capacity as a high-level overview of the project. You can just ignore them for the purpose of reading the article.
It’s when digging into the project source code that you should look at those diagrams, and then feel frustrated by how much they suck. :)
===
[1] This seems to happen a lot with LLM-generated code docs / diagrams / etc, when the docs are written in the same session as the code itself, but later; the LLM seems to see the docs as “following” the prior work in its linear context, and so mistakenly writes as if the reader of the docs will have also read whatever’s in the context before getting to the docs. That assumption, of an incrementally-growing shared context that can be implicitly made reference to by “later” text to compress that “later” text, makes a lot of sense when generating one long linear stream of prose, or even when generating a series of chain-linked entries (like conversation responses, or chapters of a book); but doesn’t work out when generating a web/graph of separate bits of text. This is kind of a fundamental flaw in producing coding agents as fine-tunes over conversational base models, and it’s one that coding-agent harnesses have yet to really focus on addressing.
Much of the text is generated as well.
Great story, programming and mechanics.
I think the fractal solver is bugged, but maybe I am just using it wrong. It says placing a cone in the red zone will block the vehicle, but either the colors are inverted or the backend is off, because everything is red except a few spots.
Otherwise very fun. I managed to park a truck the solver called impossible :)
Note: Using safari on an iPad of that matters.
And shortly after I learned how expensive tyres were, I stopped doing handbrake turns.
And shortly afterwards, in addition to all the different physics-in-action experience, I learned about how car insurance excess works.
Thank you for a great little physics engine
I speak with some authority on the matter. ;-)
https://youtu.be/Dt44PEIWBRg?is=CbVTRyDfo8Nt56fH
Thrust was by Jeremy C. Smith who went on to work on Exile with Peter Irvin
It'd be amazing to hook is up with the engine sound simulator: https://github.com/ange-yaghi/engine-sim
I wrote the rest of it "by hand" though.