Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Single header C library for parsing/using exported data and playing animations

Open
  • Is something wrong?
#84 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
15/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Stale
Tech stack
c
Domain
developer-experience

Research direction

The payload names no source files or tests. The exported JSON shape is in the issue body: sprites entries with origin and source, and animations with frames holding sprite_index and ms. Start by agreeing with the maintainer on a better name for origin, since the first checkbox is a naming decision. The C library is an open design question with no scope, so a newcomer should not start it without a maintainer decision. Done means an agreed field name and a settled library scope.

Written by the indexing model from the issue text.

Description

@ZackeryRSmith

Reasoning

This is an extension of a note that parsing the atlas requires a lot of manual labor. The goal of the project was to export a simple json file that included all the data needed to align the sprites back to a grid using the offset and source for each sprite, and then animations being just lists that include timings for each sprite index.

{
    "sprites": [
        {
            "origin": [
                0,
                22
            ],
            "source": [
                0,
                0,
                22,
                22
            ]
        },

...

"animations": [
        {
            "name": "pencil_default",
            "frames": [
                {
                    "sprite_index": 0,
                    "ms": 1000
                }
            ]
        },
...

this describes the pencil used in Pixi as a cursor. It is the first sprite in the atlas, and the origin is set to the pencil tip such that it is drawn at the mouse position offset from the top left.

However, It seems to really trip people up that this origin value includes the origin of the sprite set through Pixi. We currently do not have UI to set the sprite origin, so every sprite currently defaults to an origin at the top left corner.

This means the exported atlas data includes the distance the sprite shrunk when it was packed, such that each sprite can be back aligned to stack with other sprites of the same origin.

When Pixi allows users to set a per-sprite origin, this will allow the artist to specify the origin point at design-time and the programmer no longer has to choose and set an origin, or manage setting these origins per sprite later on when drawing them in-game. The idea would be that the final sprite rendering code just offsets the sprite position by the origin value and the sprites would be drawn correctly. i.e. origin at characters feet rather than the top left of the sprite.

Proposed changes

I don't really believe theres much of an issue with the data we are exporting. But I want to make using that data easier.

  • Potentially just find a better name for origin such that it better describes that the value includes the offset to realign the sprite at the origin the user specifies.

  • Eventually write a small portable single-header C library that can be consumed in other languages that can help users interpret the data Pixi exports. I think this would be a great bridge to allow other frameworks and engines to very simply import and use Pixi data

Dominant language
Zig
Stars
1.5k
Forks
40
Avg merge
5h 35m
Merged PRs (30d)
151

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fizzyedit/fizzy

All issues in fizzyedit/fizzy

Similar issues

More DevTools issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.