hexer303

Thank you. Yeah the load times could probably be improved. It's still the desktop assets and all pre-loaded ahead of time. It could benefit from some streaming of assets in future updates.

In terms of gravity, I actually recall this was a team debate. The original design was to use real gravity but the team thought it was simpler to have discrete areas of influence. We never really had time to A/B test it. Kerbal Space Program uses a similar model.

I ported my old project from 2007 to WASM. Original game was built in C++ for Win32 DirectX. This was an educational project with a team of 6 and 5 months of development.

How to play: Press Quick Start. Left/Right keys to aim, Up/Down for power. W/A/S/D to move the camera, tab to lock/unlock the camera.

Works on mobile too, though not perfect yet - drag the arrow around to aim, adjust the power bar, tap fire.

Originally started porting back in 2020. The first step was to port native DirectX code into OpenGL, DirectSound to SoLoud and platform code to SDL.

I ended up porting the rendering code to bgfx and coding agents game me a big boost this year so to finish the project.

The aesthetics and feature all remain original.

Some of the porting challenges: - Lots of DirectX code. Back in 2007 portability was not a high priority for us. Custom-built engine.

- Packed 32 bit custom model and animation file format with packed structures.

Back then we also made some interesting choices: - Wrote our own custom STL-like library. - For performance, the model loading code was pre-allocating a block, reading the entire file and then fixing up the binary structure offsets into pointers. This was the packed structure binary format and was not portable to modern systems so had to rewrite the loader. - Originally I wrote a custom Maya exporter plugin and model format that supported skeletal animations. Ironically we ran out of budget to produce the animations so it ended up barely used. - We had a strict rule: Absolutely no exception handling or RTTI. This ended up paying off 19 years later because it made it easier to port to WASM.

Trivia: - The weird player names are mostly nicknames of other students and staff at the time. - There are some pop culture sci/fi references to Space Balls and other movies if you notice them. - The game pre-dates Angry Birds by 2 years but has some of the same vibes to it.

It seems that the agentic search benchmarks have fallen victim to reward hacking, just like the coding benchmarks. It's good to see mitigation efforts being made to address this problem.

What do you foresee in the future releases and improvements to this?

I just finished a similar project for fun and education.

It was a 20-year-old codebase from my old game in win32 and DirectX 9.

I first ported it to native and also switched to bgfx for rendering. This was the bulk of the work - converting all of the old DirectX fixed function pipeline code to shaders. Luckily all modern shaders can simulate all of the old fixed-function DX pipeline features with little effort. Including the coordinate system. Loading DDS textures didn't present a major challenge either.

Had similar native asset loading as yours - no deserializer. It loaded an entire asset file into a preallocated memory block, used packed structures and converted file offsets to pointers after loading. I had to convert it to 64bit for native first.

The most surprising thing: I had no idea WASM is 32bit until I read your article! Once I ported to 64bit, I then ported to WASM and I didn't even encounter any arch related bugs. In hindsight I guess it's because most of the original code was 32bit and the asset file format is still 32bit format. When I ported to 64bit I used a deserializer, so I guess that's why it all worked out in the end.

For native audio I ended up using SoLoud library, but for emscripten I #ifdef'd it out to use inline JS instead. I figured there is no point in having all that extra audio library code compiling to WASM when modern browsers natively support playing audio, oggvorbis, etc. It worked out ok, but there's still a minor bug where the music doesn't loop perfectly. You can hear a split second gap between end/start. I haven't looked deeply into it yet.

Originally when we wrote the game we had banned ourselves from using C++ Exception handling and RTTI. The decision likely paid off as it makes the generated binary smaller and faster. Although I haven't had time to measure. Supposedly C++ exceptions introduce a much heavier overhead in Emscripten.

You can see the port in action at https://scorchedplanets.com

Thank you. Not many. I just use the Github copilot $40/month plan and it suffices.

I run it in manual approve mode and review/adjust every edit. Mostly auto-select model at 10% discount, or Claude frontier for more complicated tasks.

My dev process follows the same philosophy as the app itself: AI can suggest, but Human must steer and approve.

I find that the arguments of whether or not AI boosts productivity is not very productive.

The more grounded reality is that AI coding can be a productivity multiplier in the right hands, and a significant hindrance in the wrong hands.

Somewhere there exists a happy medium between vibe coding without ever looking at the code, and hand-writing every single line.

Unix shells are conceptually simple but hide a surprising amount of complexity under the hood that we take for granted. I recently had build my own PTY controller. There were so many edge-cases to deal with. It took weeks of stress testing and writing many tests to get it right.

A likely scenario is that software will become more expensive to consumers because the vendors will have to buy liability insurance in-house.

Also, it will raise the barrier to entry for any small vendor or a solo dev trying to make a living with open source.

"Trying to start your own small business in the EU? Tough shit. Go get a job, peasant!"

"I haven’t looked at Flutter for other platforms than web so I cannot comment on it other than that the general principle of Flutter is a terrible idea."

The author completely missed the point of Flutter. It is a mobile-first platform positioned as an alternative to ReactNative. Its main goal was to provide a way to build cross-platform iOS/Android mobile apps with a minimal performance trade-off. For example, its code is compiled into native machine code for iOS, Android, and desktop. Its apps tend to be more lightweight and feel snappier. Unlike ReactNative they do their own rendering so that you can have pixel-perfect consistency across platforms.

Flutter's web and desktop support is more of an experiment and a convenience for those who want to port their existing mobile apps to web and desktop.

ReactNative was targeted for web developers who want to port their existing apps to mobile, Flutter's web support is the reverse of that.

It's all logical until you are dealing with an outage when your clients can't tell the difference between a wrong endpoint and a missing item.

Example: https://news.ycombinator.com/item?id=31849488