News: 11 March 2016 - Forum Rules

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - KDL2 Enthusiast

Pages: [1]
1
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 18, 2018, 12:13:02 am »
Yup, that is how things works. When you try to do/understand many thing at the same time (short period), the feeling of overwhelming will come, frustration will start and raise constantly to a point where you must take a decision to stop or burn out. Somehow every humans tend to slide in that cursed loop, regardless is it for work, games, hacks, ....

Anyway, lets focus on hacking.Positively! The asm instructions are like the alphabet of a spoken language. Only after you learn the alphabet you will learn to 'read'. Regardless how complicated a code is, it can be divided to a smaller pieces that convey standalone meaning. When you start with few instructions and combine them in what the task is, you will learn not just to read individual 'letters' but consequence of letters as a 'word', later on combing 'words' as a 'sentences' and so on. Same goes with the 'writing'.
But don't fool yourself, this doesn't happen in a moment, just by reading a reference doc. It require work, work and more work  :happy:
And with the risk to repeat myself, that's why a good tutorial is a crucial for your growth. A good one will 'shoot you high in the sky'. A bad one will just add more frustrations.
Yep. This is probably going to take me a long time to learn, but for now I am going to go through the resources on gb-dev and study the source codes for other existing GB hacks. It might take me a long time to fully grasp, but I promise I'll be back eventually! Should I post here if I need any help, or should I head on over into programming for that?

2
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 16, 2018, 05:38:32 pm »
I can see you're a bit confused, so let me try and help: I've used BGB before to hack a couple of GB games.

Let's look at the debugger window and help you understand what each of the four windows are. The bottom-left window is the address space. For the CPU to read and write what's going on in the computer/console (the RAM, the ROM, other things) it needs an address space. The GB uses a Z80 CPU, which has a 16-bit address space: this means the most it can address is 64 kilobytes, or from $0000 to $FFFF. This space is shared by different things, and if you want to know precisely where everything is, you can look at a memory map.

Helpfully, BGB tells you exactly what the memory is mapped to at any given moment: in your screenshot you can see ROM0:0000, which means that that part of the address space is what's in ROM bank 0. 64KB isn't a lot to work with, so the GB uses bank switching to have bigger games (the NES does the same thing).

You'll notice that from $0000 to $7FFF, there are two ROM banks, usually 0 and 1, but the game can switch these at will during play - sometimes even during a single frame. After that you have VRAM (where the video information is stored); SRAM (kept on cartridges that need to save games, or just have a bit of extra RAM); WRAM (work RAM, the main RAM used by the console to do general stuff during a game); ECH (echo RAM, just echoes what the work RAM does); OAM (object attribute memory - sprites, in other words); an unused area; I/O (all the hardware registers that control different things like player input); and HRAM (high RAM, often used for regular things because it's a bit quicker than the work RAM).

Phew! Anyway, the top-left window is the actual game code. This is what's being executed to run the game, and is generally stored in ROM (usually bank 0 because that never changes). From left to right: the address; the bytes (opcodes) that are used for this instruction; a disassembly of that instruction; and a bit that I'm not sure about - maybe just a comment on each line? I don't know what the numbers mean, but it doesn't matter.

Top-right you'll see the current state of the Z80's registers. These are small bits of memory that the CPU uses to do things. For example, if you kill a baddie and get 100 points, the game might find the points value in ROM, load it to BC, load your current points to AF, add the two together, then store AF back to RAM.

The bottom-right is the stack: this is a temporary RAM area that acts like, well, a stack. You put something on top of the stack, and you can pull stuff off the top, too. It's commonly used by games because it's very fast - you can pile a whole load of things on the stack before pulling them off in quick succession. Sometimes when you're hacking, you need to find stuff that is on the stack.

So now hopefully you at least understand what you see, though I'm sure there are plenty of things you still need to know. Let me help you figure out that first idea you mentioned: giving two for a star instead of one.

Yes, you need the cheat searcher, so here's how to use it. I've never played the game so forgive me if I don't understand something... :) Open the cheat searcher (it's a bad name, it should be a RAM searcher because it's not just for cheating), and search for an 8-bit value equal to 0 (because I guess you have zero stars at the beginning, right?). 8-bit values go up to 255, so I don't think you'll be needing to look for 16-bit values here.

Once you've done the search, you'll see a ton of RAM addresses with zero in them, so now go collect one star and now search for 1 instead of 0. See, what we've done is say "only show the addresses that had zero when I first clicked, and one when I clicked again", therefore severely limiting the possibilities. Go get one more star and search for 2. I'd be very surprised if you haven't narrowed it down to a single address, so assuming you have, right-click the address and go there in the debugger.

Remember that the Z80 is little-endian, so if you were to have more than 255, the larger byte would go second (i.e. 02 01 equals 258). Try changing the "02" you see to "09" or something, and see if the total in the game changes. If so, great! We know where the stars are stored in RAM, so now to change the code. This is the tricky bit, because you need to understand assembly, but it's not as hard as it sounds.

Right-click the address and "set access breakpoint", and add a breakpoint "on write" (because we want the game to stop when it writes to that address with the new star value). Now get another star and the game should freeze with the debugger on the instruction that's writing to the address.

Now, without actually doing it myself, I can't say what is going to happen. :) But I can say that, unfortunately, this may be where you encounter the problem with this kind of hack. :) See, there's an instruction on the Z80 that lets you add one to something, which is easier than saying specifically "add x amount to this". So changing 1 to 2 isn't easy, because you need a new instruction - and that instruction needs at least two bytes, unlike the INC command. Since you can't even move the code a single byte without crashing the game, you'll find it difficult to do this. There IS a way which involves jumping to an empty part of the ROM and putting the new code there, however, but I think this is enough for one day. :D

So, read what I said, play around a bit, and I hope you'll figure a few things out! ;)
I'd like to start by thanking you for your in depth reply explaining everything about the debugger there, and what sections do what. Even after reading the pandocs page I wasn't too sure about the differences between say, RAM or SRAM.

I followed what you said with the cheat searcher and... it worked! I had to collect 4 stars and update it every time, but it eventually narrowed down to the point where I could find one value in the cheat searcher that was indeed a 4, and when I modified that to a 5 it properly updated on the next room switch! Following what you told me, I was even able to set a breakpoint on write successfully and find the code related to it. And, well, I don't think I can actually do what I had in mind, but I think this is progress still. Now I know how to properly search for changes in RAM, and how to break on write to find assembly code related to the thing I'm tracking. Thank you so much, again! I still have a long way to go, though. This was easy to track because it's a numeric value that I can see normally, but I'm not sure how to actually do things like find code related to Kirby's commands...

My next goal would to be to somehow track his forward walk speed and boost it, somehow. Before this I might need to go and study other source codes, and maybe see if I can get semi-functioning homebrew going.

KDL2 Enthusiast, hold your horses  :laugh:

As I told you earlier: "start small". Trying to do do many things, to grasp many concepts at the same times is the fastest way to burn out very easy!

As you said wisely: "assembly seems like the only way forward here". Start there, forget about everything else for the moment, and try to learn all of the z80 asm instructions. Just by reading the description of the asm commands or even memorizing them by heart will not lead to learning the language. As with real language: you know a language only when learn to talk.
In order to do so - find a good tutorial, not reference doc. A good tutorial group few instructions in a logical unit that is enough to be able to accomplish some tasks. This way you will learn the meaning of the used instruction AND you will be able to read a code that use them and even do some practical tasks! Doing things that way will produce long term practical knowledge!!!
You're probably right, sorry if I came off a bit overwhelmed and frustrated there. I think I was just expecting too much and I jumped in without enough knowledge of how things work. I'm going to probably try my hand using the many gb-dev tutorials, and see if I can get basic homebrew running first. Do you think this would help me when it comes to reverse engineering existing games?

3
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 14, 2018, 10:51:04 pm »
I've been trying to figure out the BGB debugger for the past two days, sorry for the super late follow up. To be honest, I feel completely lost right now. In the main window, I can identify one segment that is obviously HEX, which seems to update in real time... then there's a segment that is definitely ASM, but I don't believe that updates as the game goes. I can't tell what anything on the far right is, aside from the z80 CPU register names.


I also found the VRAM viewer, which was pretty self explanatory. Background viewer, loaded tiles, palette info, and then the OAM viewer. I basically understand what all of this does, although I don't know how to properly apply the OAM viewer here. It tells me the x/y coordinates and everything else about the graphics on the screen, but I don't know if the OAM address is anything meaningful that could lead me to related code.


FAST wisely advised me to start simple, so I decided to go with something along the lines of the 1up idea he suggested (when you collect one star in the game, I'd have it give you two instead). However... I don't know how to track things in the game using these tools. There's a cheat searcher, which I used to compare save states before and after getting a star. There were basically no differences in the 16 bit values, and a good number of them in the 8 bit values. I couldn't find any that really went from 01 to 02, though. I'm not really sure how I could use the cheat searcher to modify gameplay elements that aren't simple number changes, either. How would I know what value Rick is demanding when he jumps?

For whatever reason, I was expecting to be able to pause the game and track the differences/what it's being fed frame by frame to determine what is what, but now I'm not quite sure. I don't know how one would even begin reverse engineering a game/ASM hacking like this.

4
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 13, 2018, 01:58:04 pm »
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?

5
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 13, 2018, 01:39:04 pm »
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?

6
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 12, 2018, 07:31:22 pm »
And this is where 'ask many questions' come in play  :laugh:

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.

7
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 11, 2018, 10:47:05 pm »
Woah its very very rare to see such mature thinking around! Respect! :thumbsup:

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.

8
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 10, 2018, 06:48:01 pm »
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.

9
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 09, 2018, 06:40:42 pm »
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.

10
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 08, 2018, 03:28:14 pm »
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?

11
Newcomer's Board / Re: Looking to start with GB/GBC modifications
« on: April 08, 2018, 01:47:32 pm »
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.

12
Newcomer's Board / Looking to start with GB/GBC modifications
« on: April 07, 2018, 05:32:05 pm »
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.

Pages: [1]