I actually preferred Civ 3 to 2 and 4. It scratched a certain itch.

3 has a really nice feel when you manage to get the early timing attacks off against the neighbours, but the later half of the game is too solved - the game ends with infantry + artillery stacks being the only units you need, and with the 3x4 city grid bring optimal.

4 in contrast had a bunch of different paths to power, and those worked even on high difficulties. There were also no optimal city grid the same way (though still being denser than civ5).

3 is still my favourite of the series. 5 was good too, but 3 overall feels complete and had great graphics.

The modding community was gigantic for 3 and was simply amazing being a part of it.

I played A-10 Cuba a ton on an old Pentium 3. Are you doing this in a repo somewhere?

The plan is to put everything into a repo on github, this includes documentation on the file format, and also the rewrite of the original code in modern C++ and DirectX or Vulkan. I don't see much point in reverse engineering the old rendering engine - I can do it but I've got everything I need right now that I can just rewrite the game inside the browser.

Awesome. Good luck and I hope to see it.

It's fast. I don't know if they are conflating the actual compiler being slow with xmake executing it.

I use it for personal projects and I find it substantially easier to mess around with compiling shaders to SPIRV, processing assets, etc... But some of my gripes are, although it _is_ lua, there is some magic fuckery going on. When you specify targets, things for that target need to be close to the definition, and it feels very odd in a lua language to not have `target("name", function (ctx) ... end)`.

Anyways, not going to die on that hill and I'll keep using it because it's simple and works well for my needs. One thing I do like is that I am not having to constantly keep a skeleton CMake project around to copy paste and setup.

> not have `target("name", function (ctx) ... end)`.

It supports this syntax.

https://xmake.io/guide/project-configuration/syntax-descript...

  target("foo", function ()
      set_kind("binary")
      add_files("src/*.cpp")
      add_defines("FOO")
  end)

I think the creators did it a disservice to xmake when they tried to unluaize the syntax. You can also do:

    target("foo", {
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    })

which suits Lua better. Unfortunately you cannot do

    target {
      name = "foo",
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    }

which would be the lua-est lua of all.

It also supports this syntax.

    target("foo", {
      kind = "binary",
      files = { "src/*.cpp" },
      includedirs = { "src" },
      defines = { "FOO", "BAR=BAZ" },
    })

https://xmake.io/guide/project-configuration/syntax-descript...

That's what I meant: the first you can do, the second, not.

I did not spot those in the docs. Thanks a ton. This will help my autoformatter not completely wreck my files.

People getting hung up on `_t` usage being reserved for posix need to lighten up. I doubt they'll clash with my definitions and if does happen in the future, I'll change the typedef name.

Put it in drive, neutral, park, or reverse. Same as an automatic.

If you were able to wave a magic wand today and remove piracy, Microsoft would not remove ads.

Absolutely love my dumb Sceptre TV. Colors aren't super fantastic, but for the casual observer, it is just fine and gets the job done.

Curious about the allocator, why pass a size when freeing?

If you don't pass the size, the allocation subsystem has to track the size somehow, typically by either storing the size in a header or partitioning space into fixed-size buckets and doing address arithmetic. This makes the runtime more complex, and often requires more runtime storage space.

If your API instead accepts a size parameter, you can ignore it and still use these approaches, but it also opens up other possibilities that require less complexity and runtime space by relying on the client to provide this information.

The way I've implemented it now was indeed to track the size in a small header above the allocation, but this was only present in debug mode. I only deal with simple allocators like a linear, pool, and normal heap allocator. I haven't found the need for something super complex yet.