Adding GingerBread and Game Boy Assembly Programming for the Modern Game Developer #152
Conversation
Added GingerBread and the book Game Boy Assembly Programming for the Modern Game Developer. I added a new section for "Software libraries" as it didn't really fit "Sources" or "Boilerplates"...
|
I've been waiting for this day. 😄 Thanks for all the hard work you've put into the library and book, @ahrnbom. I look forward to reading it. |
|
Not a bad idea, there's probably some other stuff that could be moved to this new section. |
|
Oh hey! This looks really interesting and I loved the e-book organisation. That's one of the few complete resource on learning this subject.
@tobiasvl Can you expand on this?
About the book:
About the GingerBread library:
About adding you in the "Acknowledgements" list:
Looking forward to hear from you! I'd really appreciate if any other @gbdev/awesome-gb member could take a look at this and hopefully give an opinion / review. |
avivace
added
addition
|
Hi!
4 and 5. I'll consider this too. Maybe people could open issues on GingerBread's GitHub page, even if they're about the book? I'm not sure about hosting the source to the book, but I'll consider it.
|
Well, you mentioned ZGB. I guess I'm not married to the idea of a new Software Libraries section, but there's other stuff on the list that could fit together with GingerBread in one. |
|
I released the source code to the book here: https://github.com/ahrnbom/gbapfomgd |
There was a problem hiding this comment.
I have noticed a bunch of issues (some objective, some subjective) while reading the book itself. I planned to write a big list once I was finished, but I will open issues on that repo instead (give me a couple days first, though). Until they are resolved either way, I'm against merging.
|
Sounds good to me. I guess I didn't understand just how curated this list was. If you guys finally decide against adding my stuff on here, that's absolutely fine. |
Nice! Thank you for doing that!
Yes, Issues are more fit to publicy discuss and work with feedback.
I honestly want this in the list. I think it'd be a nice and costructive addition to the small set of complete book/tutorials we have. I'll keep a watch on th repo and wait for @ISSOtm reporting Issues on the ebook and/or the library |
|
I had written this twice before, but it got deleted because of software crashes. Sorry for the delay, it's just hard to muster the courage to write it all again for the third time :P First, I do want this on the list as well, as it has a different angle from other material there, and is also more complete—my own tutorial hasn't received and update for far too long, I'll admit, but all of us are busy—so it'd be a very welcome addition. I have, however, two remaining issues on a more ideological level. I was reluctant to bring them up initially because the last time such issues were brought up, feedback was fairly negative. Here they are:
Let's detail. Cargo cultThe tutorial has a companion library (GingerBread), which I do not agree wholly upon, but I've come to accept not everyone has the same programming style and habits. The problem is something that I have heard about a specific section of the most widely-accepted GBA programming tutorial Tonc. I've heard people complain that its affine OBJ section (if memory serves right) relies too much on the library and does not explain how the library works. This problem is everywhere in gbapfomgd, since it always relies on GingerBread functions. I'd say one of the more egregious examples is printing a string: ld b, 150 ; End character
ld c, 0 ; Draw to background
ld de, 5 + 32*6 ; Position number
ld hl, TextWithEndCharacter ; Address to text start
call RenderTextToEndByPositionHere is the function's code, when it could be summed up to this: ld de, BACKGROUND_MAPDATA_START + 6 * 32 + 5
ld hl, TextWithEndCharacter
.printChar
ldh a, [rSTAT]
and STATF_BUSY
jr nz, .printChar
ld a, [hli]
cp 150
jr z, .done
ld [de], a
inc de
jr .printCharThis is much more lightweight, and does not need to be an entirely separate function, which incurs penalties for calling, computing values that are known at build time ( This segways somewhat into the next problem, which is the tutorial staying Too high-levelThe problem seems to be trying to apply programming principles suited to compiled languages to ASM. For example, if we take the problem of the tilemap offset being known at compile time in the example above, a C compiler would be able to infer it and add the offset to And this is another part of the problem relying too much on the library: it's an optimization and comprehension barrier, especially problematic on a system where everything is done so close to the hardware, and even hardware bugs and idiosyncracies leak through. Another problem in this regard is the sacrifice of micro-optimization for the sake of legacy. For example, any seasoned ASM developer would have optimized the ld b, 150 ; End character
ld c, 0 ; Draw to backgroundabove to lb: MACRO
ld \1, (\2) << 8 | (\3)
ENDMThis was brought up in a PR I made, where @ahrnbom replied he favors readability to optimization. I strongly disagree with this, for the reason that readability can be enhanced through the use of comments and macros (where appropriate, though), but optimization cannot. It's important, in a tutorial explaining how to program on a 1 MHz CPU, to explain how to be efficient; instead of introducing better programming in comments, which imply they're not important, it would be a better idea to introduce the macro at some point, and keep using it throughout the rest of the tutorial. I think GingerBread itself could benefit from a lot of such optimization—which I suppose can be accounted to some lack of experience from the author, so I wouldn't blame him—but I think there is a greater problem to it. I have more disagreements with GingerBread itself, most notably the following three:
|
|
If a program prints more than one string, the loop portion (from
I personally use buttons in the lower nibble on Game Boy because it matches the nibble ordering of the Game Boy Advance and Nintendo DS input registers. But Super Game Boy ICD2 has D-pad in the lower nibble, as do the Z80-based Sega Master System and Game Gear. |
A program wishing to print characters one per frame may either use a function that loops on its own, or a function that is called as part of a loop. My point is that forcing either in the lib is not a good option. Whether the user wants to call this function or variations of it is also up to them. |
|
Thank you for your well written comment @ISSOtm, because it really points towards a big mistake I have made in the communication of my work. I thought putting it in the title of the book, and spending most of the first chapter on it would be sufficient, but that's clearly not the case. GingerBread itself in particular needs to communicate this point very clearly: Both the book and GingerBread are designed with a specific audience in mind: modern game developers who are used to making games for modern platforms but have no experience with ASM or Game Boy development If you do not belong to this group, or cannot imagine their situation, few of the decisions I made are going to make any sense, making it difficult to separate real problems from things that just make sense for one group and not for another. It seems to me that you (@ISSOtm) either didn’t understand this intention, or for whatever reason chose to ignore it, because nowhere in your discussion do you mention the learning process for these people, and this quote shows this problem clearer than anything else:
That’s not what I said at all! I never said my solution was better than yours, I said it was easier for beginners to understand which is something very different! This example appears quite early in the book, where the reader should not be expected to have such familiarity with writing ASM code, especially not highly optimized lines. That’s not to say people should never learn optimized ASM, all it means is that was not the right time to introduce it. Modern game development libraries are designed to let the programmer focus on implementing the game logic as soon as possible. For example, a Hello World program in Löve is just three lines long. While ASM code for the Game Boy will never be as simple as that, but I tried to at least meet people half-way by only including in the book those things that are most essential to get started in making games. If I had to write down all the details needed to get started without relying on GingerBread, it would have the following devastating issues:
I therefore realized that something like GingerBread is simply a necessity in order to be able to write a (relatively) short, to-the-point tutorial that let’s people get started with implementing game logic as quickly as possible. GingerBread also only superficially functions like a standard library: It contains a bunch of functionality that I think is useful for most games when getting started. But the similarity to standard libraries probably ends there. There is was no intention for people to not modify it for their needs, for example. So I disagree that GingerBread “forces” decisions onto people; it really doesn’t. Rather, it provides (what I consider to be) sane defaults to get people started. Once people have finished the book and maybe written a simple test game (like a Pong clone or whatever), and try to move onto more ambitious projects, the limitations of GingerBread will become obvious, but at the same time, they’ll have the basic understanding and experience to utilize all the other documentation and tutorials out there that require so much previous knowledge. Maybe they’ll start by modifying GingerBread to their needs, and finally decide they want to code their games from scratch when they feel comfortable doing so. In other words: When GingerBread is incapable of handling the kind of game someone wants to make, and that person decides to either modify it or abandon it altogether, @ISSOtm will probably consider this a failure of the library, when in reality it is a success: it means that someone actually learned Game Boy ASM! And that’s the end goal. With this in mind, let’s go through all the criticism @ISSOtm brought up and I’ll respond to each thing separately.
To summarize, I am more convinced than ever that I made several key design decisions correctly in my work. I’m not going to sacrifice that just to be included on this list. Even if you guys decide to not include my stuff on here, I hope you’ll at least consider what your definition of “awesome” is, so that it doesn’t become “only good for people who already know this stuff already”. What I do need to do is to fix some of the real problems in my book and code, and communicate better how it should be used. |
|
Martin, thank you for taking the time to handle every raised issue. This essentialy goes down to the never ending discussion between me and @ISSOtm on his radical (and basically correct) viewpoints vs me accepting "less perfect" and opinionated resources. We have to embrance and accompany different target of users, and providing assembly optimisation tips to beginners shifting from gbdk (or starting from the ground up) risks to overhelm and turn them away. We do not want that. We are not training a crowd of assembly developers, we have to provide fashionable entry points for anyone. AND THEN make them progressively shift to more accurate and advanced styles of coding and approaches. Politics apart, I've had the chance to read a bit of the book and I think this definitely fits the list. Even if it isn't perfect and it's opinioted in a number of ways it is a good resource in a category lacking quality content. It would be very good to report (a kind of "disclaimer") some of the raised points by ISSO directly on the GingerBread repo (both on the book and the library, splitting them), so the users can acknowledge the opinionated parts and critical choices made in this resource, providing a more informated position on the subjects. |
Added GingerBread and the book Game Boy Assembly Programming for the Modern Game Developer (both made by me). I added a new section for "Software libraries" as GingerBread didn't really fit "Sources" or "Boilerplates" in my opinion. If you/someone feels GingerBread should belong to some other category, feel free to change it (or let me know).