Libgamearchive Alternatives

Similar projects and alternatives to libgamearchive

stb

164 25,071 6.7 C libgamearchive VS stb

stb single-file public domain libraries for C/C++
w64devkit

72 2,375 7.6 C libgamearchive VS w64devkit

Portable C and C++ Development Kit for x64 (and x86) Windows
WorkOS

workos.com sponsored

The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
scratch

51 333 9.0 C libgamearchive VS scratch

Personal scratch code
studiojs

1 6 0.0 JavaScript libgamearchive VS studiojs

Web interface for editing DOS games
gameinfojs

1 2 0.0 JavaScript libgamearchive VS gameinfojs

High level interface to the functionality provided by the other game* libraries
gamearchivejs

1 14 0.0 JavaScript libgamearchive VS gamearchivejs

Read and write archive files used by DOS games
gamecompjs

1 11 0.0 JavaScript libgamearchive VS gamecompjs

Apply and remove compression and encryption algorithms used by DOS games
InfluxDB

www.influxdata.com sponsored

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.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better libgamearchive alternative or higher similarity.

Suggest an alternative to libgamearchive

libgamearchive reviews and mentions

Posts with mentions or reviews of libgamearchive. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-05-02.

What's the GLB file format?
8 projects | /r/dosgaming | 2 May 2022

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.