Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
libgamearchive
Library and command line utilities for examining and editing archive/group files used by DOS games
What a fun little format that I just wrote my own little extractor for run: glb.c. It even appropriately works in DOS.
Your code is very nicely written. Do you know much Javascript? I'm always looking for help with Camoto, which I am in the process of rewriting from C++ into Javascript so it can run inside a web browser.
If you're interested in a comparison (to see how much you'd have to write to do something similar to your glb.c) here is the GLB format code along with the encryption/decryption algorithm.
If you're interested in a comparison (to see how much you'd have to write to do something similar to your glb.c) here is the GLB format code along with the encryption/decryption algorithm.
Replace libpng and png++ with an embedded copy of stb_image.h. Honestly, libpng is neither great nor well-maintained. (Case in point: The main website still doesn't support HTTPS despite hosting security-sensitive information and hosting critical source code. All the download links are still shitty SourceForge redirects.)
To illustrate how simple building can be, lets look at libgamecommon. I untarred Boost (not installing it or otherwise touching it) adjacent to libgamecommon, and doing all the rest of this with my own development kit (Mingw-w64 distribution plus tools, fitting entirely inside a portable 66MiB zip). First of all, this works right out of the box:
libxml2 was just for storing information about the games for UI display. Back in 2010 when the project was started it was the go-to file format for this kind of thing :) It has been replaced in the JS version by code as gameinfojs. It is much more flexible doing this in code instead of static data, as you can do things like look in the .exe file to figure out what the filenames are for the other data files, avoiding the need to hard code all the filenames into an .xml file, and display level titles extracted from the level files instead of just their filenames.
A rewrite was also sorely needed, even without changing the language. One of the "mistakes" I made with the C++ architecture of libgamearchive for example, was to try to modify archive files in-place, as opposed to writing a new archive file out from scratch and then moving it over the top of the original file. While it can be significantly quicker editing in-place, it introduces a huge amount of complexity and to be honest, the amount of time spent debugging problems caused by this is just not worth it. The compression and encryption algorithms as well, they are streaming so work whether you write one byte at a time or one megabyte at a time (and will process terabytes of data without issue), but having them track what point they are up to across multiple calls like that adds a huge amount of complexity (just look at all the case statements in the Monster Bash RLE encoder so the function can resume at the correct point in subsequent calls). So regardless of language, it was due for a major refactor anyway as continuing with this amount of complexity was just not worth the headaches it brings. Especially on today's hardware, writing out a 40 MB .GRP file from scratch will take well under a second, so spending hours, sometimes days, debugging write-in-place problems just isn't worth the benefit.