Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Part II, Lesson 1 #12

Closed
ISSOtm opened this issue Jul 10, 2022 · 2 comments
Closed

Part II, Lesson 1 #12

ISSOtm opened this issue Jul 10, 2022 · 2 comments
Assignees

Comments

@ISSOtm
Copy link
Member

ISSOtm commented Jul 10, 2022

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.

@evie-calico
Copy link
Contributor

I can help out with this :)

@ISSOtm
Copy link
Member Author

ISSOtm commented Aug 13, 2022

Done in #21. Thank you @eievui5, and @avivace! 🎉

@ISSOtm ISSOtm closed this as completed Aug 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants