Zig development

[erlend-sh]

I had a conversation with @cxong about this and he’s receptive to the idea.

Problem: it’s pretty hard to attract new C contributors to a project like this because the language, timeless as it may be, consists of an “aging population”.

Solution: Zig on the other hand is rising in popularity among both young and old with its many novelties and rapid development. There’s a potential win-win here with cdogs providing Zig coders with a richly featured game project to hack on, while the Zig community can bring renewed interest to the cdogs codebase.

There’s precedent for this in the likes of raylib: https://github.com/raysan5/raylib/pull/2014 – but as Cong pointed out:

I think the situation between raylib and c-dogs is different; the former is a library so adding zig interop makes it useful for other zig projects, whereas c-dogs is only meaningful if we also start adding zig code to c-dogs

So I would want to make sure we don't harm the existing situation by moving to zig; this means:

• building valid binaries for win/linux/mac, including release builds
• good IDE support, including interactive debugging

I think the first step should be achievable if someone puts in the effort to build and test on all 3 platforms; the release build might be a bit tricky because there's a lot of integration going on with github/itch uploads, but if someone has the inclination to do so, I'm happy to review this work

c-dogs is quite a big codebase at this point, so realistically we will always have some legacy C code hanging around, I guess zig code can interop with C but I don't know how it is the other way around, e.g. C code calling zig functions and using zig types? If it is seamless then that would be great

Personally I wouldn't rewrite existing C parts into zig unless there are significant benefits, like memory safety, much simpler code. I know there's some really hairy code in the project to do with the GUI, and the need for manually freeing stuff, strings and hashmaps etc, so those would be good candidates, but realistically I'm going to prioritise fixes and new features over rewriting existing, working code. For example the codebase uses two incompatible JSON libraries, because I started with one and then found a better one; this sucks and it would be better to just have one, but I've never gotten around to doing so

[malespiaut]

$> scc (fd -t f -e h -e c)
───────────────────────────────────────────────────────────────────────────────
Language                 Files     Lines   Blanks  Comments     Code Complexity
───────────────────────────────────────────────────────────────────────────────
C                          297    106736     9116     10148    87472      15459
C Header                   219     52709     4699     13038    34972       4346
───────────────────────────────────────────────────────────────────────────────
Total                      516    159445    13815     23186   122444      19805
───────────────────────────────────────────────────────────────────────────────
Estimated Cost to Develop (organic) $4,206,585
Estimated Schedule Effort (organic) 23.74 months
Estimated People Required (organic) 15.74
───────────────────────────────────────────────────────────────────────────────
Processed 4902161 bytes, 4.902 megabytes (SI)
───────────────────────────────────────────────────────────────────────────────

According to scc, the code base is 122k lines long. It's going to be a fun experience for those who want to dive in. But bear in mind that it won't be trivial, because while C can easily be translated by hand into Zig, Zig offers new features that you need to be aware of to simplify the software architecture.

I support this approach, because I'm doing it myself on a relatively small C project and it's an excellent learning exercise. I also think that translating your C code to Zig will allow you to discover new bugs and help you fix them! I wish you the best of luck!

[erlend-sh]

Cheers :) Do note this particular comment from Congus above:

Personally I wouldn't rewrite existing C parts into zig unless there are significant benefits, like memory safety, much simpler code.

The game is already feature-complete. This issue is mainly about making it capable of being extended with Zig contributions by getting the build pipeline in order.