[KDL2 Enthusiast]

Hello RHDN! As my username implies, I am a huge fan of Kirby's Dreamland 2. Something I've always wanted to do is make a DX hack with color and minor level modifications to remove bits of artificial difficulty and forced ability usage, potentially with altered game modes (think: Rick only or 3 HP cap). I know this is not an easy task, but I'm willing to put in the time and effort necessary to do it, if I can just begin to figure out how.

Help getting started would be greatly appreciated. I am more or less completely new to ROM hacking outside of a few graphical edits I've done years ago on a different handle, so when it comes to actual code modifications I don't even know where to begin. Does anyone here have suggestions for what I should look into, or perhaps a tutorial demonstrating an example of a non-graphical GB edit?

Apologies if it seems like I'm in over my head. I probably am, and wish to start small before moving onto my bigger goals, but I'd like to at least make attempts to learn these things and create what I've always wanted to.

[Jorpho]

Well, there's always this:

The Newbie Package of REQUIRED Material
 
ROMHacking.net FAQ: You ask, we answer!
ROMHacking.net Getting Started Section: Newbies Go HERE!
ROMHacking.net Documents Section!
How to ask questions the smart way.
On the Essence of ROM Hacking
Talk with experienced people in our IRC chat and ask specific questions there.

[FAST6191]

I go more for the GBA and DS than the GB/GBC but
The previously linked documents are good stuff.

As I already know enough of what they contain then should I head into a new system I will look to see if someone has documented the hardware
In the case of the GB/GBC there is the fantastic set of documents called the pandocs.
http://bgb.bircd.org/pandocs.htm

Also you will want a debugger for such things if it exists
I am not sure what we are suggesting for such a thing these days
The old standbys were
http://problemkaputt.de/gmb.htm
and bgb debugger
http://bgb.bircd.org/

They are not quite as shiny as some of the things we see on the NES, SNES, GBA and DS but those seeking debuggers for other consoles would probably be delighted to get something like the bgb stuff.

As far as demonstrating then it is all pretty similar between systems -- if you know enough to do it on one system and actually know what you are doing you can usually fairly easily convert to another system.

As far as making a DX hack and bringing something to the GBC/making use of the extra stuff on the GBC it is possible, several have done it for other games, but it is a fairly involved thing. I should note however that it is one of the few titles to have something worth speaking of for the super game boy ( http://loveconquersallgam.es/post/2487450388/fuck-the-super-game-boy-kirbys-dream-land-2 ).

"minor level modifications to remove bits of artificial difficulty and forced ability usage"
Editing levels allows a lot of changes to be done. Many times you can change a game radically by simply operating within the framework the game provides (see all those games that turn metroid into a boss rush or some such).
That said what new hackers often fail to realise is how quickly it can turn from that to being something you end up elbow deep in the game's underlying code for, especially on older systems. I have then seen many find it really stifling, some use it as a motivation to gain more skills, others quit.

"potentially with altered game modes (think: Rick only or 3 HP cap)."
You might be able to do the former with a cheat (somewhere in the memory will be a character selected, force that with a cheat and you have your thing).
Doing it properly would probably involve a tiny bit more -- I would be lazy and say whatever gets called then always return the hamster but you could do other things.

Health wise there are two main approaches I would use. 1) In games like Zelda you could edit the maps and bosses to remove all the heart upgrades.
2) Cheats again. The GB/GBC does not have the most robust cheat systems like newer consoles
http://doc.kodewerx.org/hacking_gb.html (by the way the bottom of that page has something like some working/discussion on GB/GBC specifics).
Newer ones have logic available to them so you can do things like "if health greater than 3 set 3" where you are limited to simple forced writes here.
That said somewhere in the "inventory" will probably be a count of whatever health containers you have. Set these to three and you have your result.

[KDL2 Enthusiast]

Thank you for both of your responses!

Well, there's always this:

The Newbie Package of REQUIRED Material
 
ROMHacking.net FAQ: You ask, we answer!
ROMHacking.net Getting Started Section: Newbies Go HERE!
ROMHacking.net Documents Section!
How to ask questions the smart way.
On the Essence of ROM Hacking
Talk with experienced people in our IRC chat and ask specific questions there.

I went through all of these (and joined the Discord to ask some basic questions), should I go ahead and check out "A 65816 Primer" by Brett Tabke as a start?

I go more for the GBA and DS than the GB/GBC but
The previously linked documents are good stuff.

As I already know enough of what they contain then should I head into a new system I will look to see if someone has documented the hardware
In the case of the GB/GBC there is the fantastic set of documents called the pandocs.
http://bgb.bircd.org/pandocs.htm

Also you will want a debugger for such things if it exists
I am not sure what we are suggesting for such a thing these days
The old standbys were
http://problemkaputt.de/gmb.htm
and bgb debugger
http://bgb.bircd.org/

They are not quite as shiny as some of the things we see on the NES, SNES, GBA and DS but those seeking debuggers for other consoles would probably be delighted to get something like the bgb stuff.

As far as demonstrating then it is all pretty similar between systems -- if you know enough to do it on one system and actually know what you are doing you can usually fairly easily convert to another system.

As far as making a DX hack and bringing something to the GBC/making use of the extra stuff on the GBC it is possible, several have done it for other games, but it is a fairly involved thing. I should note however that it is one of the few titles to have something worth speaking of for the super game boy ( http://loveconquersallgam.es/post/2487450388/fuck-the-super-game-boy-kirbys-dream-land-2 ).

"minor level modifications to remove bits of artificial difficulty and forced ability usage"
Editing levels allows a lot of changes to be done. Many times you can change a game radically by simply operating within the framework the game provides (see all those games that turn metroid into a boss rush or some such).
That said what new hackers often fail to realise is how quickly it can turn from that to being something you end up elbow deep in the game's underlying code for, especially on older systems. I have then seen many find it really stifling, some use it as a motivation to gain more skills, others quit.

"potentially with altered game modes (think: Rick only or 3 HP cap)."
You might be able to do the former with a cheat (somewhere in the memory will be a character selected, force that with a cheat and you have your thing).
Doing it properly would probably involve a tiny bit more -- I would be lazy and say whatever gets called then always return the hamster but you could do other things.

Health wise there are two main approaches I would use. 1) In games like Zelda you could edit the maps and bosses to remove all the heart upgrades.
2) Cheats again. The GB/GBC does not have the most robust cheat systems like newer consoles
http://doc.kodewerx.org/hacking_gb.html (by the way the bottom of that page has something like some working/discussion on GB/GBC specifics).
Newer ones have logic available to them so you can do things like "if health greater than 3 set 3" where you are limited to simple forced writes here.
That said somewhere in the "inventory" will probably be a count of whatever health containers you have. Set these to three and you have your result.

Thank you for such a detailed and helpful response, again! I'm probably not supposed to understand that bgb page until I have basic ASM/coding knowledge, right? Once I do, I'm not quite sure how to apply a debugger either. I guess to see where errors occur?

Yeah, I basically expected making a DX hack to be an extremely difficult and involved process, as well as modifying the level as there's no existing editor for it. I'm willing to keep trying until I succeed, though.

I was thinking about making those restrictions extra modes that exist in the game, if possible. Including potential changes like DL1 style sprite swaps on the 3 HP mode or a Kirby-less Rick in Rick only mode. This is also probably going to be hell to implement, but it's a long term goal I've set for myself.

[KingMike]

should I go ahead and check out "A 65816 Primer" by Brett Tabke as a start?

Probably not, because GB/GBC uses a Z80 CPU (and one that has been modified by Nintendo at that). So you'd want to look at Z80 documentation and especially one specifically about the Game Boy variant.

[KDL2 Enthusiast]

Probably not, because GB/GBC uses a Z80 CPU (and one that has been modified by Nintendo at that). So you'd want to look at Z80 documentation and especially one specifically about the Game Boy variant.

Alright, thanks for the heads up! Is this something safe to dip into for a start if I have no coding experience but wish to learn?

[FAST6191]

Motivation is the big one for ROM hacking, and programming in general if you are not being compelled to learn it.

If you so happened to be really into your NES or SNES games then there are loads of worked everything, tools and more besides.

You are not without options for the GB/GBC (far from it) but you don't have as many. If it is what motivates you to learn then carry on -- I did not come up through those (instead blundering my way through the GBA and DS) but I might well have had some different background to you.

The pandocs link? It won't teach you assembly and such in and of itself but you will find it useful long before you reach that point -- it covers how a lot of the hardware works and that in turn influences how you approach cheats, some aspects of graphics, file formats and more besides.

Applying a debugger? You can find bugs with it, it is what they are named for after all. Around here though they are the top tier tools for hacking purposes.
Eventually you will go into tracing (more on that in a moment) but before then the tile viewers, memory viewers, palette viewers, background viewers, audio register readouts... have a lot of value.
Tracing then. It is the top technique of hackers -- it will find anything you want if the game reads it, allow you to learn whatever you want about how a game functions and then start to tweak how it works at a fundamental level. There are many techniques before then but they are all niceties some games share and guesswork, which is often more than enough but this will get it.
A code debugger then allows you various features, different systems and emulators will have fewer or more of them but the idea remains the same.
Some of the functions include break on read (it stops and says something read this location), break on write (something wrote here), break on specific value being written, run the next ? lines, run to this line of code...
If you say found the location of the health via a cheat search (start with full health, do nothing in the game other than take some damage, search, damage, search... you find it eventually) you can then tell the game to watch for anything writing that area. Guess who now knows the instructions dealing with the damage calculations? More useful still in the case of an RPG where you might have monster def you can then trace back and find where it all is in the ROM (it is usually all together or near enough).
I am supposed to note though that infinite lives and such can be harder than a simple cheat which only has to hold one location the same. The classic example being deaths in mario. Pits, hazards, poison mushrooms, enemies, time, being crushed... all take from the lives counter and may do it in different ways/as a result of different routines. Likely no different here for Kirby.

For the basics of assembly I always liked http://www.plantation-productions.com/Webster/ and https://stuff.pypt.lt/ggt80x86a/asm1.htm , both are for the PC but cover lots of good stuff more than most of the specific stuff we see with the consoles. If you get even the basics from those then you can load up the pandocs thing mentioned earlier and see what it gives you, what things do and start going from there.

[KDL2 Enthusiast]

Motivation is the big one for ROM hacking, and programming in general if you are not being compelled to learn it.

If you so happened to be really into your NES or SNES games then there are loads of worked everything, tools and more besides.

You are not without options for the GB/GBC (far from it) but you don't have as many. If it is what motivates you to learn then carry on -- I did not come up through those (instead blundering my way through the GBA and DS) but I might well have had some different background to you.

The pandocs link? It won't teach you assembly and such in and of itself but you will find it useful long before you reach that point -- it covers how a lot of the hardware works and that in turn influences how you approach cheats, some aspects of graphics, file formats and more besides.

Applying a debugger? You can find bugs with it, it is what they are named for after all. Around here though they are the top tier tools for hacking purposes.
Eventually you will go into tracing (more on that in a moment) but before then the tile viewers, memory viewers, palette viewers, background viewers, audio register readouts... have a lot of value.
Tracing then. It is the top technique of hackers -- it will find anything you want if the game reads it, allow you to learn whatever you want about how a game functions and then start to tweak how it works at a fundamental level. There are many techniques before then but they are all niceties some games share and guesswork, which is often more than enough but this will get it.
A code debugger then allows you various features, different systems and emulators will have fewer or more of them but the idea remains the same.
Some of the functions include break on read (it stops and says something read this location), break on write (something wrote here), break on specific value being written, run the next ? lines, run to this line of code...
If you say found the location of the health via a cheat search (start with full health, do nothing in the game other than take some damage, search, damage, search... you find it eventually) you can then tell the game to watch for anything writing that area. Guess who now knows the instructions dealing with the damage calculations? More useful still in the case of an RPG where you might have monster def you can then trace back and find where it all is in the ROM (it is usually all together or near enough).
I am supposed to note though that infinite lives and such can be harder than a simple cheat which only has to hold one location the same. The classic example being deaths in mario. Pits, hazards, poison mushrooms, enemies, time, being crushed... all take from the lives counter and may do it in different ways/as a result of different routines. Likely no different here for Kirby.

For the basics of assembly I always liked http://www.plantation-productions.com/Webster/ and https://stuff.pypt.lt/ggt80x86a/asm1.htm , both are for the PC but cover lots of good stuff more than most of the specific stuff we see with the consoles. If you get even the basics from those then you can load up the pandocs thing mentioned earlier and see what it gives you, what things do and start going from there.

Well, I'm definitely motivated and dead set on trying my best to accomplish this. When I get great replies from people like you, it inspires me even more to keep going. The help really does mean a lot to me.

Over the past few days I've been reading and watching a number of tutorials related to Z80 (GB) assembly, and I guess I'm still trying to wrap my head around everything.

I'm seeing a lot of talk of how the CPU works, what segments of it there are, what registers you use the most, how many you can do at once, what calls from what, etc. but I'm not sure how to apply any of it to anything that would be meaningful gameplay-wise.

Like... taking Mario's jump and extending the height, or changing some of his animations/hitboxes. I'm probably supposed to trace the functions for these things, but I'm a bit lost on how to do that and alter it right now. Whenever I look things up there's never basic gameplay related examples for GB stuff, which makes me wonder if I should be starting out with this or jumping into things that are a bit more common first.

Would you happen to know of any examples demonstrating how to trace and modify game aspects (even if it's for a different platform like the NES or MS)? Apologies if it seems like I'm just asking to be spoonfed here, I'm just trying to figure out how to get started in a way where I can tell what I'm doing, so I could build myself up to this.

[FAST6191]

Assembly wise you might have tried running before you can walk as far as your learning choices go, your examples of potential projects are fine for early stages and I will cover something of them shortly.
I find it useful to gain an understanding of the core commands and then branch from there. In this case you don't have much in the way of extraneous commands (compared to say someone learning modern X64 where it will have things nobody really ever uses but have to be there for completion) but you can shrink it down.
It is important to understand concepts of timings, what registers are traditionally used for what and so forth but for now if you are editing within parameters of a game they are less important -- back to the idea of infinite lives before, say you find the thing that adds lives in this game and instead of giving you one extra life you make it give you two (maybe you are making a kind of easy mode hack). Timing differences between add r1, #1 and add r1, #2 (that might be the wrong syntax for this but hopefully it still makes sense) are nothing but you still have just done an assembly hack, and might well have radically changed how the game plays out for most people.

Moon jump then.
1) If you see it rendered as a cheat then it will mostly be for a game with a double jump. I mention it mainly so you are aware of such things. The idea is the game will do the second jump in the air, set a flag and then not allow another double jump. Your cheat forces the part from "set a flag" to always be "no second jump done yet" and thus pressing jump sees you able to fly to the moon.

2) Actual jump tweaks. The character will be on the screen and its location controlled in some way. Most characters in 2d games are sprites and thus taken care of by whatever passes for the OAM on that system (here it is called the OAM http://bgb.bircd.org/pandocs.htm#vramspriteattributetableoam ). 3d is also similar in many ways but on rare occasion the whole world might move instead or it might be the camera that moves, enough of that though.
So you find what OAM value controls your sprite -- these nice OAM/sprite/tile viewers being there for a reason. Failing that most systems rarely have more than a few hundred sprites they support so you can load up the memory viewer for that area, make sure it updates in real time and jump a few times, any changes should be fairly obvious.
What you do here is up to you. You can watch that area, start a jump, advance a frame and see what changed it. Follow that back and you eventually find the thing controlling jump height. Alternatively you could set a break on write for that OAM area and it will pause the emulation and say "this instruction wrote this area, this is where the instruction is and what immediately follows and precedes it".
Said jump height instructions might be slightly complicated by it not being a simple "add 2 per frame until you hit 20, then minus two until you hit something you can land on" type affair -- proper acceleration due to gravity/parabolic curves were popular from way early on.

Ultimately it might be something else that controls the height and the OAM is just a side show* but as it is directly linked to it then you will find your height variables soon enough. What they might be in a given game varies, especially if different characters have different abilities, but should be able to be found.

*similar to how the text on the screen is probably not going to reference the text in memory after it is drawn on the screen and thus you can change the nice text in memory all you like but it is not going to be reflected in the contents of the screen.

Hitboxes can be marginally more complicated ( http://dammit.typepad.com/blog/2010/09/street-fighter-ii-hitboxes.html ), and some systems (usually older or odd arcade ones) don't actually use them and instead have automatic collisions in the OAM/sprites, but follow much the same logic and will have the OAM involved somewhere. This even if it is just deciding how to do the maths to send the relevant sprite in a recoil animation.


Also it is for the GBA but you might like
http://www.coranac.com/tonc/text/video.htm
It covers how the video side of things works on the GBA (and it is not far removed from the GB/GBC, or indeed most other 2d devices).

[Jazz]

This all looks too complicated for a beginner.

1. Get a game that a table file is already available. Table files are for text hacking. I'd suggest starting with Pokemon Red/Blue to learn from as there's a lot of resources.
  -- You can use utilities that change certain things in the game. Then with the below Hex utility you can compare a changed game with a non-changed game to see where the edit was made.
2. Get a Hex utility - I recommend Windhex32
3. Get a graphics tile editor - I recommend Tilelayer Pro
4. Worry about the programming and stuff for later. Just have a play around and see what happens to start with

[KDL2 Enthusiast]

Assembly wise you might have tried running before you can walk as far as your learning choices go, your examples of potential projects are fine for early stages and I will cover something of them shortly.
I find it useful to gain an understanding of the core commands and then branch from there. In this case you don't have much in the way of extraneous commands (compared to say someone learning modern X64 where it will have things nobody really ever uses but have to be there for completion) but you can shrink it down.
It is important to understand concepts of timings, what registers are traditionally used for what and so forth but for now if you are editing within parameters of a game they are less important -- back to the idea of infinite lives before, say you find the thing that adds lives in this game and instead of giving you one extra life you make it give you two (maybe you are making a kind of easy mode hack). Timing differences between add r1, #1 and add r1, #2 (that might be the wrong syntax for this but hopefully it still makes sense) are nothing but you still have just done an assembly hack, and might well have radically changed how the game plays out for most people.

Moon jump then.
1) If you see it rendered as a cheat then it will mostly be for a game with a double jump. I mention it mainly so you are aware of such things. The idea is the game will do the second jump in the air, set a flag and then not allow another double jump. Your cheat forces the part from "set a flag" to always be "no second jump done yet" and thus pressing jump sees you able to fly to the moon.

2) Actual jump tweaks. The character will be on the screen and its location controlled in some way. Most characters in 2d games are sprites and thus taken care of by whatever passes for the OAM on that system (here it is called the OAM http://bgb.bircd.org/pandocs.htm#vramspriteattributetableoam ). 3d is also similar in many ways but on rare occasion the whole world might move instead or it might be the camera that moves, enough of that though.
So you find what OAM value controls your sprite -- these nice OAM/sprite/tile viewers being there for a reason. Failing that most systems rarely have more than a few hundred sprites they support so you can load up the memory viewer for that area, make sure it updates in real time and jump a few times, any changes should be fairly obvious.
What you do here is up to you. You can watch that area, start a jump, advance a frame and see what changed it. Follow that back and you eventually find the thing controlling jump height. Alternatively you could set a break on write for that OAM area and it will pause the emulation and say "this instruction wrote this area, this is where the instruction is and what immediately follows and precedes it".
Said jump height instructions might be slightly complicated by it not being a simple "add 2 per frame until you hit 20, then minus two until you hit something you can land on" type affair -- proper acceleration due to gravity/parabolic curves were popular from way early on.

Ultimately it might be something else that controls the height and the OAM is just a side show* but as it is directly linked to it then you will find your height variables soon enough. What they might be in a given game varies, especially if different characters have different abilities, but should be able to be found.

*similar to how the text on the screen is probably not going to reference the text in memory after it is drawn on the screen and thus you can change the nice text in memory all you like but it is not going to be reflected in the contents of the screen.

Hitboxes can be marginally more complicated ( http://dammit.typepad.com/blog/2010/09/street-fighter-ii-hitboxes.html ), and some systems (usually older or odd arcade ones) don't actually use them and instead have automatic collisions in the OAM/sprites, but follow much the same logic and will have the OAM involved somewhere. This even if it is just deciding how to do the maths to send the relevant sprite in a recoil animation.


Also it is for the GBA but you might like
http://www.coranac.com/tonc/text/video.htm
It covers how the video side of things works on the GBA (and it is not far removed from the GB/GBC, or indeed most other 2d devices).

Alright, it looks like I'm gonna have some fun with the debugger and take a look at how this stuff works. Thank you again for your insight on this. ^^

I'll try this stuff gradually and see how it goes, using what all I've learned here. If I have any more questions or updates, should I continue to post in this thread? I'm completely new to this and a bit out of my element, so I don't know if I'm overstepping any boundaries or asking too much here.

This all looks too complicated for a beginner.

1. Get a game that a table file is already available. Table files are for text hacking. I'd suggest starting with Pokemon Red/Blue to learn from as there's a lot of resources.
  -- You can use utilities that change certain things in the game. Then with the below Hex utility you can compare a changed game with a non-changed game to see where the edit was made.
2. Get a Hex utility - I recommend Windhex32
3. Get a graphics tile editor - I recommend Tilelayer Pro
4. Worry about the programming and stuff for later. Just have a play around and see what happens to start with

I can definitely see where you're coming from; it probably seems like I'm way in over my head, but I've actually already done somewhat extensive tile editing work, and I've also done my fair share of edits just using the utilities that are available for specific games. I've even done hex edits for personal projects, like doubling my magic use early in LttP and changing palettes for my tile/character edits in various NES titles. I want to grow and move past that, and assembly seems like the only way forward here (especially for this project, which I've wanted to do for over a decade now).

I'm still most likely in over my head, but I want to try my hardest to learn this.

[Squall_FF8]

I want to grow and move past that, and assembly seems like the only way forward here (especially for this project, which I've wanted to do for over a decade now).

Woah its very very rare to see such mature thinking around! Respect!

I would like to help you. Unfortunately I know nothing about Kirbi/GB/GBC, but I will keep an eye on your thread, who know what will come in future.

My advice: keep that spirit, start small, ask many questions.

[KDL2 Enthusiast]

Woah its very very rare to see such mature thinking around! Respect!

I would like to help you. Unfortunately I know nothing about Kirbi/GB/GBC, but I will keep an eye on your thread, who know what will come in future.

My advice: keep that spirit, start small, ask many questions.

Thank you for the compliments!

And don't worry about that, ahaha. I expect this to be a pretty niche thing, since DL2 isn't exactly the most popular Kirby title.

Work's made it a bit hard to make progress the past few days, but I've been reading up on GB docs and ASM tutorials in my free time to try and get a better understanding. Though, it's a bit rough with no prior coding experience. Lots of unfamiliar terminology and concepts for me.

[Squall_FF8]

Though, it's a bit rough with no prior coding experience. Lots of unfamiliar terminology and concepts for me.

And this is where 'ask many questions' come in play 

Grasping the concepts is essential. How about you start small - pick one that you came across in your study recently and lay it down here?

[KDL2 Enthusiast]

And this is where 'ask many questions' come in play 

Grasping the concepts is essential. How about you start small - pick one that you came across in your study recently and lay it down here?

I guess so far, partially because I haven't gotten the chance to sit down and mess with the debugger yet, I'm having a hard time grasping how the assembly commands I see tie to game elements. Like... for numeric changes, I get that.  But when it comes to these commands somehow reading an input and moving an object on the screen a particular way, I don't understand how that works yet.

I'll be able to do a lot this weekend, hopefully! I just found more resources, so I'm going to keep reading up in the meantime.

[Psyklax]

I'm having a hard time grasping how the assembly commands I see tie to game elements. Like... for numeric changes, I get that.  But when it comes to these commands somehow reading an input and moving an object on the screen a particular way, I don't understand how that works yet.

I haven't got much experience with the GB, but I can say that on the NES, the information on which button is pressed is stored in a register.

Basically, each button and D-pad direction can be either on or off, so they're like bits (binary digit). Every single frame, the system looks at the player input register to see which bits are activated, and based on that information, decides whether to do something. So if you're at the title screen of Megaman, for example, the game checks for input every frame and does one check of what it finds: is the bit connected to the Start button active? No? Carry on. Yes? Ah, time to start the game!

The same applies during the game. Is the user pressing A, or B, or a direction? The game code does something based on what it sees there, it's as simple as that. Let's say you want to switch the A and B button actions around. Simple: you break on a read from the input register, then look where it stores the result, and find that check. Then just swap the bits around.

That's the basic idea of that, but I'm sure you have many more questions.

[KDL2 Enthusiast]

I haven't got much experience with the GB, but I can say that on the NES, the information on which button is pressed is stored in a register.

Basically, each button and D-pad direction can be either on or off, so they're like bits (binary digit). Every single frame, the system looks at the player input register to see which bits are activated, and based on that information, decides whether to do something. So if you're at the title screen of Megaman, for example, the game checks for input every frame and does one check of what it finds: is the bit connected to the Start button active? No? Carry on. Yes? Ah, time to start the game!

The same applies during the game. Is the user pressing A, or B, or a direction? The game code does something based on what it sees there, it's as simple as that. Let's say you want to switch the A and B button actions around. Simple: you break on a read from the input register, then look where it stores the result, and find that check. Then just swap the bits around.

That's the basic idea of that, but I'm sure you have many more questions.

That's actually a great reply, thank you! I'm a bit confused as to how you would move or animate things on screen with assembly, too. Would forward movement also be a value that works the same way?

What exactly is covered in the OAM is also a mystery to me. I know it covers sprite attributes, but would that extend to movement/collision and not just graphical things?

[FAST6191]

That's actually a great reply, thank you! I'm a bit confused as to how you would move or animate things on screen with assembly, too. Would forward movement also be a value that works the same way?

What exactly is covered in the OAM is also a mystery to me. I know it covers sprite attributes, but would that extend to movement/collision and not just graphical things?

http://bgb.bircd.org/pandocs.htm#vramspriteattributetableoam

Byte0 - Y Position
Specifies the sprites vertical position on the screen (minus 16).
An offscreen value (for example, Y=0 or Y>=160) hides the sprite.

Byte1 - X Position
Specifies the sprites horizontal position on the screen (minus .
An offscreen value (X=0 or X>=168) hides the sprite, but the sprite
still affects the priority ordering - a better way to hide a sprite is to set its Y-coordinate offscreen.

Byte2 - Tile/Pattern Number
Specifies the sprites Tile Number (00-FF). This (unsigned) value selects a tile from memory at 8000h-8FFFh. In CGB Mode this could be either in VRAM Bank 0 or 1, depending on Bit 3 of the following byte.

Byte3 - Attributes/Flags:

  Bit7   OBJ-to-BG Priority (0=OBJ Above BG, 1=OBJ Behind BG color 1-3)
         (Used for both BG and Window. BG color 0 is always behind OBJ)
  Bit6   Y flip          (0=Normal, 1=Vertically mirrored)
  Bit5   X flip          (0=Normal, 1=Horizontally mirrored)
  Bit4   Palette number  **Non CGB Mode Only** (0=OBP0, 1=OBP1)
  Bit3   Tile VRAM-Bank  **CGB Mode Only**     (0=Bank 0, 1=Bank 1)
  Bit2-0 Palette number  **CGB Mode Only**     (OBP0-7)


Writing Data to OAM Memory
The recommened method is to write the data to normal RAM first, and to copy that RAM to OAM by using the DMA transfer function, initiated through DMA register (FF46).
Beside for that, it is also possible to write data directly to the OAM area by using normal LD commands, this works only during the H-Blank and V-Blank periods.

Movement is then likely to be a feature that adds or subtracts from a value over the course of so many frames, or if you prefer then add 10 pixels each time and you move 10 pixels each time. I imagine you are familiar with sprite sheets -- change what the sprite is displayed (or maybe cycle between two and hiding them on some older systems or more simplistic animation routines) and you can effect a walking/hitting/whatever animation.
Collisions are not hardware based in this one it seems so likely a software thing governing it, if indeed the "method is to write the data to normal RAM first, and to copy that RAM to OAM by using the DMA transfer function" then you have a copy of the relevant coordinates of everything you care about in RAM and thus can compare it and see what overlaps and go from there.

[KDL2 Enthusiast]

http://bgb.bircd.org/pandocs.htm#vramspriteattributetableoam

Movement is then likely to be a feature that adds or subtracts from a value over the course of so many frames, or if you prefer then add 10 pixels each time and you move 10 pixels each time. I imagine you are familiar with sprite sheets -- change what the sprite is displayed (or maybe cycle between two and hiding them on some older systems or more simplistic animation routines) and you can effect a walking/hitting/whatever animation.
Collisions are not hardware based in this one it seems so likely a software thing governing it, if indeed the "method is to write the data to normal RAM first, and to copy that RAM to OAM by using the DMA transfer function" then you have a copy of the relevant coordinates of everything you care about in RAM and thus can compare it and see what overlaps and go from there.

That was quick! Thank you again for the detailed rundown. I think I get it now, I'm just going to have to start debugging tonight and see what I can find.
April 13, 2018, 06:15:14 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Looking at wla-dx documentation, it looks like I'll be using .enum and .define to put proper labels on all of the values I find, right?

[Squall_FF8]

Looking at wla-dx documentation, it looks like I'll be using .enum and .define to put proper labels on all of the values I find, right?

.define and .enum are optional. You can use .define to name values, addresses,... but its not required.

Let say that Joypad is read from address $200 and Button1 has value 5

Code: [Select]

Not named:
 LDA $200
 CMP 5
 ...

Named:
.def Joypad $200
.def Button1 5

 LDA Joypad
 CMP Button1
 ...The 2 pieces of code do the same, produce the same code, but the second is more obvious (easy to read).