Register»Forums»Work-in-Progress»Astera - A 2D C99 Game Library / Framework (0.01 alpha released)
2 posts / 2 projects
Astera - A 2D C99 Game Library / Framework (0.01 alpha released)
1 month, 3 weeks ago Edited by Devon on June 18, 2020, 3:41 p.m. Reason: Initial post
Hey! I just went thru and finished the early versions of my game framework / library! If you're interested in checking out / giving some feedback here’s a brief overview of what astera supports / does:

Batched 2D Rendering
Baked Sheet (Tiled or Bounded boxes)
Post Processing Effects
Custom Particle Simulation (user defined custom)

Vector Graphics based User Interface
Supports programmatic input (aka controllers, mouse, keyboard, etc)

3D Audio
Quick Sound Effect playback (OGG Vorbis & WAV)
Song / Stream playback (OGG Vorbis (WAV soon))

ZIP & PAK File Management
General asset management
An input system that works
Really bad INI File writing & loading

I also wrote a short FAQ about the release if you're looking for more info:

GitHub link
39 posts / 1 project
Astera - A 2D C99 Game Library / Framework (0.01 alpha released)
1 month, 2 weeks ago
* How about putting a screenshot on the front page to hook the right users quickly before they move on to something else?
* A folder with regression tests works as both examples of what to expect and a list of what has been properly tested on the low level.
* A little bit of documentation directly in the source code can go a long way to help navigating while the library grows bigger. It's easier to do while you still remember how it works in a small scale.
* Names like "d_post_to_err" can be harder to remember than "debug_print_error". The human mind uses one redirection per word and another for special spelling, so this goes from 6 to 3 in difficulty to remember.
* Types like "r_ctx" (RenderingContext) look too much like the convention used for method calls. A common solution is to begin with upper case for types. It's not a law, but you need a convention to separate them and names that can be understood out of context by someone not familiar with the library. Lower learning threshold means more users and more contributors.
* Because this is not C++ with namespaces, you need a prefix that's unique to your library at the beginning of each method, so that other libraries can be combined. Maybe "ast_" if you want something short? Then the developer can search for all methods beginning with "ast_" to find where the library is being called from the application.

Biggest Linux fears to address:
* Many libraries based on OpenGL cannot handle pixel exact drawing on Linux because each driver acts differently and many OpenGL implementations are simply full of bugs in core features. Most commercial games will fail on Linux if no GPU drivers could be installed for the graphics card. A fully specified reference implementation on the CPU or in OpenCL will serve as both a fallback solution and exact documentation. Guarantees about seam free rendering, pixel exactness or even bit-exact determinism in colors would put your library ahead of many others.
* How will full-screen and up-scaling be handled? Linux usually don't come with GPU drivers and therefore no scaling for LCD displays.
* Have you profiled sprite drawing on the GPU against memcpy on the CPU? If you have many separate draw calls in low resolution, chances are that CPU rendering would be faster. Run-time profiling from thousands of sprites drawn using multiple back-ends can tell which are correct and which among them is the fastest when starting a game for the first time. If the results say that my OpenGL drivers are too old, missing an important OpenGL extension, drawing funky colors by mixing up texture slots, crashing, leaking memory, not pixel-exact or slower than the CPU, a simple fallback would still allow me to enjoy the game in 800 frames per second.