Contributions

[dogruis]

Hi Damien,

I'm about 200 hours into building a 2D platformer on a game engine of my own —
portable C that runs the same game code on both PC (SDL3) and the Neo Geo through
ngdevkit. The port is what got me reading the toolchain sources closely, and that's
where the recent activity from me comes.

I have more queued up — a few further findings from the same review effort
(including one I'd rank high: bios_frame_skip declared u16 at an odd address,
which shifts the bios-RAM symbols that follow it — verified with nm), plus some
API/ergonomics ideas (P2 mirrors for ng-input.h, palette/sprite helpers). Before
filing anything else, I'd rather ask how you like to work than flood the tracker:

• One issue per finding, or a single batched issue you can triage at your own pace?
• For small, clear fixes: issue first, or just a direct PR?
• For new API surface (new headers, helpers): discussion before any code?
• Any preference on pacing — e.g., should I wait until the current batch is
  reviewed before sending more?
• How can I become a contributor?

Happy to adapt to whatever works best for you.
Thanks for ngdevkit — it's been a great foundation to build on.

Ismaïl (dogruis)

[dciabrin]

Hey Ismaïl,

Thanks for your interest, I saw that you file a fair amount of issues already, it's nice to get to know the context of it. A good chunk of the issues you filed are sufficiently tricky that I haven't got the time to give a proper answer..

I have more queued up — a few further findings from the same review effort (including one I'd rank high: bios_frame_skip declared u16 at an odd address, which shifts the bios-RAM symbols that follow it — verified with nm),

Ouch! not good. Let's fix that as soon as we can

plus some API/ergonomics ideas (P2 mirrors for ng-input.h, palette/sprite helpers). Before filing anything else, I'd rather ask how you like to work than flood the tracker:

I saw this one, and I have an issue with the approach and the way it would work with both C and C++. More generally, I have not settled on the API that I want to expose for those bios values, because I'm trying to achieve various conflicting goals:

• I don't want a function to cost any byte in ROM if it's not used. To achieve that, I'm using the pattern found in newlib that is "make one function per file in libngdevkit, so at linktime, no matter the optims used, only functions used will get linked".
• That being said, I'm not sure if I want to expose macros, or function - which would give typing hint and help with autocomplete in the editor.
• Using static is making me nervous as its semantic is not strictly the same in C and C++, and I'm sure it will bite us in the end.
• I'm very much considering a big band in a future version of ngdevkit where all bios variables will be defined as field in a single struct called bios_ram or something. The reason for that is that accessing a var in RAM will then be compiled as accessing an offset from a based pointer, which in the case of the 68k makes a lot of sense because the base pointer is 32bit, and the rest is less than 16bit offset, which decrease the code size and thus speeds us execution. I'm not clear on how I want to expose that transition yet, and right now I don't have time to think of a nice transition.

I saw your question w.r.t the volatile nature of bios variable, which I think is a very valid question, but again I have a hunch that this can be resolved differently, I'll add my remarks in this ticket shortly. Thanks for filing it anyway.

* One issue per finding, or a single batched issue you can triage at your own pace?

One issue per finding works best for me. I prefer issue along with PR as the intent usually better described.

* For small, clear fixes: issue first, or just a direct PR?

for small things a PR is OK. Although we might disagree on small. For instance I saw your filing for the credits in nullbios, and while originally I thought that I did a bad copy and paste, I seem to remember that the original BIOS does things in a fairly convoluted way; adding a coin on the player2's chute would add a credit in player 1, because credits are usually counted for the cabinet and not for the players... I tried to mimick what I could understand but this is unclear, so in this case, I would probably argue in the PR that there's more than meets the eye :D

* For new API surface (new headers, helpers): discussion before any code?

Yes this one requires discussions, because I have strong opinions on what should land in the devkit and what should be an extension on top of it.

* Any preference on pacing — e.g., should I wait until the current batch is
  reviewed before sending more?

So as you saw I usually prioritize the maintenance of the devkit (CI breaks, bug fixes) rather than add more features. This is mostly due to the time that I'm able to allocate to the project. Try to push the ones you feel important first, as I'll most probably get them merged quicker if they fix something.

* How can I become a contributor?

I don't have strict rule, only informal ones for the time being. Basically:

• Give me confidence that you have a deep understanding of the thing you want to fix/improve. This happened once when a contributor changed the crt0.
• Try not to bombard me with GenAI reviews. The asymmetry that is produces drains me, and I get frustrated fairly quickly if I get the impression that the effort put in the contribution doesn't match the effort I put in the review.
• Don't get mad if I take time to answer, or if I seem to nitpick reviews. This usually means that I have something in mind, which at the time is still a bit too blurry to put into words :)

Hope this helps