To C or Not to C: Initial rework #27
Conversation
|
That's great, it already looks super nice. Thanks for your efforts on this, @bbbbbr |
|
I made a couple small corrections and fixes. I wasn't sure if it was ok to add was a link to the gbdk/zgb specific discord server. If the preference is to not have it I'm happy to roll that back. I also made it via the GBDK github page to avoid having to update in multiple places if the link was to change later on. I updated the expired Discord link for gbdev - though maybe it's better to point that one to the gbdev community page so it remains current? Now that I've given it a once over I think it's good to go. I'm still happy to integrate further feedback and changes if anyone has ideas. |
Yes, definitely. |
Done. Note- there isn't an id="..." anchor target for the discord heading in the gbdev.io landing/community page, so it doesn't scroll down to that section automatically. But there is a discord icon near the top, maybe that's fine? |
|
Maybe this one? https://gbdev.io/chat.html |
|
Haha, not sure how I missed that! 🤦 |
|
Hey folks, what's the news on this? Any additional requests for changes or does it look ok to merge? If you'd rather not merge it, that's ok too. |
|
Sorry, I have my terms coming in 3 weeks, so I really have no time to get involved in that for now. Please understand that it's still at the top of my priority list, though. Sorry. |
|
Thanks, that's helpful to know. I'll check back afterward and good luck. |
|
Let me say that that the document is currently too biased and aggressive, it's clear we need a profound revision to keep it as an official intro document. I finally had some time to read the revision this honestly looks pretty good, especially because it's removing a lot of strong opinions on GBDK, while still allowing an informed choice. However, I'd still like to have some kind of (objective) comparisons of the performance between the two approaches, highlighting how different the two tasks are and how "taxing" it is to write ASM vs GBDK but how it actually affects CPU cycles. Thanks @bbbbbr for taking the time and the patience to work through this. |
The version online right now has a comparison using last crown warriors, however that's (presumably) compiled with the ancient SDCC and GBDK. It would be better to use a comparison that reflects the current state of the tools. While I think comparisons are useful to illustrate, they should probably carry a caution not to draw broad, general conclusions from individual examples. Comparisons will be highly sensitive to context: what's being done, how complex is it, how important is the performance/code size, how much of an existing code library is available to draw from, how skilled and familiar is the person with ASM vs C, etc. Case in point: I recently rewrote a C function in ASM. The ASM version benchmarked about 2x faster, it also took about 10+ times as long to write (I'm slow at ASM, despite being able to integrate some existing code). The speed bump was nice and it was a useful learning experience, but it didn't incentivize me to rewrite any of the other code. For another person that might have been sufficient motivation though. Or, it might have taken them the same or a smaller amount of time to write it in ASM at the outset. |
|
@ISSOtm can we start merging the current status of the PR, even if it's a draft? It's better than keeping the outdated version online :/ |
|
I'd also change the title to "C vs ASM for gbdev" or something similar |
Would you prefer a more specific title (like above) versus something general such as "Choosing tools for Game Boy development"? |
|
Agreed, we ought to also point at GB Studio too, or at any other usable worflow/toolchain that may emerge in the future. |
Yes but please in a second moment, let's try not pack too many things for the first rework |
Do you mean on this page, or elsewhere on gbdev.github.io? GB Studio is already mentioned in the new revised version and includes a link to their website. |
|
That's what I mean: the document should point to those, and I also think that the title would be better if updated to reflect that. The document isn't just "C vs. ASM" anymore (and that was a fairly stupid thing, anyway). |
|
@ISSOtm A part from the generalities of the document (which I'll be working on too), can you give some feedback on the contents so we can start merging it? |
|
I have a bit of breathing room now, so please just give me until Sunday. |
|
Any news on this, or anything that should be changed/improved? |
@avivace @ISSOtm
All,
This is an start at reworking the To C or not to C doc by ISSO. After some discussion we decided that instead of just making minor updates to bring the document up to the current state, it might be better to change the approach. To that end, this restructures it to be a little more broad and general- how to choose the tools that will work best for one's goals and abilities. It tries to include all current tools (including GBStudio) and give people a sense of their limitations and strengths.
Where it needs help:
RGBDS Strengths & Weakness could stand to be filled in by someone with more experience
Should the document be renamed to something like "Choosing tools for Game Boy development"?
Please consider this more of a rough draft than a PR that is expected to merge. Feedback and direction is very welcome.
I haven't looked at it for a little bit now and may want to change a bunch as well, but would rather collect changes and do a bunch of editing all at once.