You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first lesson of Part II should be about setting up a new project, this one from scratch. This is meant both as a base to everything else that will follow in this Part, and as a bit of a breather after the long info dump in Part I.
Notably, no new concepts shall be introduced. The new project should only use a simple build script (making it "plain Windows"-compatible would be a plus, but not strictly necessary), which only assembles a single file, following the three commands presented in "Hello World!".
This first lesson should display the Arkanoid clone's playfield (i.e. the borders, maybe a side bar with some score, etc.). Neither the paddle nor the ball should be present; but the bricks should. Graphics will still be written manually, this time using dw `.123 syntax (as the "raw" bitplane format has already been explained in Part I). (Automatic gfx generation using external tools will be dealt with in Part III.)
Part II is not meant to have things always done the proper way—if the "proper" way introduces significant complexity (including cognitive load) over a simpler way, the simpler way should be prioritized. gb-asm-tutorial as a whole is intended to be a progressive introduction to GB dev concepts, and Part II is only a single step in this process; Part III will "clean up" organization once the reader has solidified their understanding of the hardware interface.
Part II is also meant to introduce common mistakes, and "show, don't tell" why they are mistakes. For example, at first, variables should be allocated manually using equ; this way, a mistake can intentionally be made at some point, which can then lead into (1) demonstrating how to debug such issues (as debugging is often an aspect forgotten by programming tutorials), and (2) making the reader experience why doing so is a bad idea—then labels and ds can be introduced.
The text was updated successfully, but these errors were encountered:
The first lesson of Part II should be about setting up a new project, this one from scratch. This is meant both as a base to everything else that will follow in this Part, and as a bit of a breather after the long info dump in Part I.
Notably, no new concepts shall be introduced. The new project should only use a simple build script (making it "plain Windows"-compatible would be a plus, but not strictly necessary), which only assembles a single file, following the three commands presented in "Hello World!".
This first lesson should display the Arkanoid clone's playfield (i.e. the borders, maybe a side bar with some score, etc.). Neither the paddle nor the ball should be present; but the bricks should. Graphics will still be written manually, this time using
dw `.123
syntax (as the "raw" bitplane format has already been explained in Part I). (Automatic gfx generation using external tools will be dealt with in Part III.)Part II is not meant to have things always done the proper way—if the "proper" way introduces significant complexity (including cognitive load) over a simpler way, the simpler way should be prioritized. gb-asm-tutorial as a whole is intended to be a progressive introduction to GB dev concepts, and Part II is only a single step in this process; Part III will "clean up" organization once the reader has solidified their understanding of the hardware interface.
Part II is also meant to introduce common mistakes, and "show, don't tell" why they are mistakes. For example, at first, variables should be allocated manually using
equ
; this way, a mistake can intentionally be made at some point, which can then lead into (1) demonstrating how to debug such issues (as debugging is often an aspect forgotten by programming tutorials), and (2) making the reader experience why doing so is a bad idea—then labels andds
can be introduced.The text was updated successfully, but these errors were encountered: