• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

Chit-Chat: ROM Hacking Daily Chit Chat

PokéMew1

Pokémon Fuchsia
484
Posts
10
Years
I'll agree with you. Advance Map does have its flaws. But think about it, Advance Map honestly saves every ROM hacker a load of time, rather than doing all of its features manually. You can map edit, insert new tilesets, redo the world map, edit events and insert custom XSE scripts, and all of its other little tweaks (movement perms, changing map names, and all the other features in the header section). I can tell you that every single good ROM hack used Amap at some point, (I honestly can't think of a scenario where one wouldn't) I would say Lu-Ho deserves SOME credit for the work behind it. Again, it does have flaws, but it definitely gets around.
 
Last edited:

GoGoJJTech

(☞゚ヮ゚)☞ http://GoGoJJTech.com ☜(゚ヮ゚☜)
2,475
Posts
11
Years
I'll agree with you. Advance Map does have its flaws. But think about it, Advance Map honestly saves every ROM hacker a load of time, rather than doing all of its features manually. You can map edit, insert new tilesets, redo the world map, edit events and insert custom XSE scripts, and all of its other little tweaks (movement perms, changing map names, and all the other features in the header section). I can tell you that every single good ROM hack used Amap at some point, (I honestly can't think of a scenario where one wouldn't) I would say Mastermind-X deserves SOME credit for the work behind it. Again, it does have flaws, but it definitely gets around.

1: Lu-Ho developed advance map, not Mastermind-X
2: While all of that is fine and dandy, amap is still very bad and we need an alternative. Especially with Lu-Ho refusing to share its source even though he had many opportunities, which only goes to show that it's not the greatest thing ever.
 

PokéMew1

Pokémon Fuchsia
484
Posts
10
Years
1: Lu-Ho developed advance map, not Mastermind-X
2: While all of that is fine and dandy, amap is still very bad and we need an alternative. Especially with Lu-Ho refusing to share its source even though he had many opportunities, which only goes to show that it's not the greatest thing ever.

Damnit once again I got their names mixed up.. I'll agree with you there that we need an alternative. Advance map has been out for many many years, and the program has since been given up on. But all I'm saying is, with what we have, its most definitely the best option.

Now I think this thread is getting a little off topic maybe? ...
 
1,344
Posts
14
Years
  • Seen Dec 10, 2021
It labels lots of things wrongly, sometimes even makes editing them impossible (the out of border cut tree to the east of Cerulean City for example, which requires Blue Spider). But most of all, a rotten potato is probably more future-proof than Amap.

Correct me if I'm wrong but could you not just expand the borders of the map temporarily to move it's position? Or just select it by going through the event IDs until you find it? It doesn't make it clear, sure, but I'm pretty sure it is possible to edit (you even get a warning, something like "there are events outside of the map").
 

daniilS

busy trying to do stuff not done yet
409
Posts
10
Years
  • Age 24
  • Seen Jan 29, 2024
Correct me if I'm wrong but could you not just expand the borders of the map temporarily to move it's position? Or just select it by going through the event IDs until you find it? It doesn't make it clear, sure, but I'm pretty sure it is possible to edit (you even get a warning, something like "there are events outside of the map").

You can select it going through the event IDs, but if you edit it and edit it back it will break :P
 
17
Posts
9
Years
  • Age 29
  • Seen Apr 6, 2015
A-map is slow, sometimes buggy, eats memory like shit (also does have a memory leak) and it's just poorly designed. However, making a new map editor would be damn easy for me in C# and .NET, as I'm a performance expert in this framework and language, who worked with memory manipulation for bitmaps and also fast binary reading from a ROM. Write me if you're interested and send me some research stuff and I might do one ;)
 
190
Posts
14
Years
  • Seen Apr 14, 2016
Where has the map rating thread gone? It's not stickied anymore and I can only find it via google search. And it didn't look like it was locked. What happened to it?
 
6,355
Posts
18
Years
  • Seen Apr 16, 2020
Where has the map rating thread gone? It's not stickied anymore and I can only find it via google search. And it didn't look like it was locked. What happened to it?

http://www.pokecommunity.com/showthread.php?t=226711

The ROM Hacking Hub section usually only shows threads posted in since the last month so it didn't show up. If you change it so that older threads show up it's in the second page. You can still post there.
 

Joexv

ManMadeOfGouda joexv.github.io
1,037
Posts
11
Years
A-map is slow, sometimes buggy, eats memory like shit (also does have a memory leak) and it's just poorly designed. However, making a new map editor would be damn easy for me in C# and .NET, as I'm a performance expert in this framework and language, who worked with memory manipulation for bitmaps and also fast binary reading from a ROM. Write me if you're interested and send me some research stuff and I might do one ;)
Dude a new map editor would be awesome if it got done relatively soon.
 
5,256
Posts
16
Years
A-map is slow, sometimes buggy, eats memory like **** (also does have a memory leak) and it's just poorly designed. However, making a new map editor would be damn easy for me in C# and .NET, as I'm a performance expert in this framework and language, who worked with memory manipulation for bitmaps and also fast binary reading from a ROM. Write me if you're interested and send me some research stuff and I might do one ;)

It would be far more worth your time to contribute to the already open-source Map Editor of Happiness (MEH) which is in-progress than starting a new one again.
 

Blah

Free supporter
1,924
Posts
11
Years
It would be far more worth your time to contribute to the already open-source Map Editor of Happiness (MEH) which is in-progress than starting a new one again.

MEH is being re-written from Java to C. Shinyquagsire says he doesn't like pointer handling in Java. Anyways, I don't see the whole map editor going anywhere anytime soon because Shinyquagsire is still doing stuff for NDS iirc. Blue spider, corsara's map editor, on the other hand could use the love :P
 
12
Posts
15
Years
  • Seen Jul 28, 2023
So, it's been a few years since I was last here, and it seems like there's been a LOT of progress. Great job everyone!

I have some things I'm looking for, but can't seem to find, because the search function on this site likes to give way too many irrelevant results, even when I do my best to filter them. Here's my shopping list:

  • Is there a Yellow remake out there yet? If not, is there a follow-me script capable of producing something similar? Where can I find these things?
  • Are there 386 hacks for all the gen 3 games? If so, where can I find those?

EDIT: Found my answer to the second question with google. Sorry to bother everyone with a dumb question.
 
Last edited:
2
Posts
9
Years
  • Age 29
  • Seen Mar 24, 2015
What's up guys, this is my first post so hopefully I haven't done something wrong.

Anyway, I'm looking for a ROM hack that I'm not sure exists but it's worth a look.

I'm looking for a gen 4 game. Doesn't matter what, be it Diamond/Pearl/Platinum or HeartGold/SoulSilver, I don't really care. The only thing I want that's actually different from the standard gen 4 game is to have every Pokemon added, up to and including Volcanion and Hoopa. There doesn't need to be an actual way to get them in the game, I'm planning on using a randomizer anyway, so they just need to be in the game files.

Other things that are OK to have but aren't absolutely necessary are, in order of importance, new abilities, new TMs and new Megas. Other than that, I'd prefer to have it vanilla. Minor changes that aren't too game changing (Cut being Grass type like in Drayano hacks etc.) are OK.

Thanks!
 

Alexander Nicholi

what do you know about computing?
5,500
Posts
14
Years
MEH is being re-written from Java to C. Shinyquagsire says he doesn't like pointer handling in Java. Anyways, I don't see the whole map editor going anywhere anytime soon because Shinyquagsire is still doing stuff for NDS iirc. Blue spider, corsara's map editor, on the other hand could use the love :P
THANK YOU!
Holy crap I was waiting for him to dump the Java train.


There are some definite distinctions I wish to make with Sapphire from cosarara's Red Alien. But for now I'll leave those to be trade secrets :A
 

Alexander Nicholi

what do you know about computing?
5,500
Posts
14
Years
Well you don't need to dereferencing pointers, most of the RAM pointers are statically allocated to specific portions which are flagged. \What you'd need to do is find these static RAM blocks equivalents in your game of choice.

Anyways, why do you want support for R/S or LG? They're all pretty bad bases to use. The biggest problem is their lack of research. It's pointless to research something for R/S when it's already been discovered for Emerald, because Emerald will be better than Ruby as a base, but never vise versa. It's just not worth the time researching things for a ROM base which is inferior.

Fire Red has the most research done, and in my opinion, is the best base to use. Second comes Emerald, and finally the rest are trash.

But, yeah, if you wanted to port them, the pointers are all that needs changing (for the ones you've linked). Actually, the surf one may be a little different depending on the base. Fire Red launches that routine when "A" is pressed on any tile. Other bases may be a little different.
That sounds lazy to me lawl. "Well it's not researched, so why research it lol" is a horrible line of reasoning.

Ruby doesn't have a giant chunk of wasted free space, and lets you manipulate more flags (albeit outside normal RAM) than FR or E. Using the debugger to find RAM offsets of things is far easier (say, with graphics). I see little reason not to research it.

I'm figuring out assembly at the moment so I'd love to do all the dirty work but can't right now. :/
 
5,256
Posts
16
Years
That sounds lazy to me lawl. "Well it's not researched, so why research it lol" is a horrible line of reasoning.

Ruby doesn't have a giant chunk of wasted free space, and lets you manipulate more flags (albeit outside normal RAM) than FR or E. Using the debugger to find RAM offsets of things is far easier (say, with graphics). I see little reason not to research it.

I'm figuring out assembly at the moment so I'd love to do all the dirty work but can't right now. :/

The reasoning is more "people willing to research are scarce as it is so focusing our efforts onto the same two, most powerful / useful / well-documented ROM bases instead of spreading ourselves thin for what is basically completionist / superficially different reasons that are otherwise basically redundant" than what you listed. FireRed already has a hack by Jambo51 to allow the use of lots of flags, so that isn't really an advantage for Ruby, either.
 

Alexander Nicholi

what do you know about computing?
5,500
Posts
14
Years
The reasoning is more "people willing to research are scarce as it is so focusing our efforts onto the same two, most powerful / useful / well-documented ROM bases instead of spreading ourselves thin for what is basically completionist / superficially different reasons that are otherwise basically redundant" than what you listed. FireRed already has a hack by Jambo51 to allow the use of lots of flags, so that isn't really an advantage for Ruby, either.
The reason I use Ruby is because it's easier to hack, period. The transition to extended ROM support isn't quite complete yet and its nice not worrying about that.

Because you think Emerald and FireRed are programmatically superior is no reason to other people regarding what's most comfortable with them. If they're picking their fruit over which ones others are picking as opposed to what tastes best to them they're missing the point.

As for the topic, I don't think it's right that the elitism promoting only those two bases shortchange Ruby from having more assembly work done for them. I'd like to see better hacks for Ruby, and while I really don't care about Sapphire or LeafGreen, I'm not against using them simply because I prefer something else. My opinion weighs the same as everyone else's.

I'll likely end up doing this myself later on anyway so it doesn't matter.
 
5,256
Posts
16
Years
The reason I use Ruby is because it's easier to hack, period. The transition to extended ROM support isn't quite complete yet and its nice not worrying about that.

Because you think Emerald and FireRed are programmatically superior is no reason to other people regarding what's most comfortable with them. If they're picking their fruit over which ones others are picking as opposed to what tastes best to them they're missing the point.

As for the topic, I don't think it's right that the elitism promoting only those two bases shortchange Ruby from having more assembly work done for them. I'd like to see better hacks for Ruby, and while I really don't care about Sapphire or LeafGreen, I'm not against using them simply because I prefer something else. My opinion weighs the same as everyone else's.

I'll likely end up doing this myself later on anyway so it doesn't matter.

I'm curious about your assertion that Ruby is easier to hack than FireRed.

I never said either ROM was "programmatically superior" (although there are claims made by others that I'm not knowledgeable enough to dispute which do indeed suggest that Ruby is an inferior base from a programming standpoint, such as its Pokédex which is supposedly exceptionally difficult to expand), I'm saying that at the moment the community is lacking the amount of people willing to do research into the ROMs' workings themselves for us to really have the luxury to spread ourselves so thin and research all five ROMs in Gen 3 instead of just focusing on the two with the most groundwork done already, i.e. FireRed and Emerald. I'm not saying your opinion on which game is better is wrong, I'm saying that it isn't unreasonable for researchers / developers to only develop for ROMs they're comfortable with. It's not a matter of "shortchanging Ruby," and is more just working with what they're comfortable, familiar and are sure will reach and be used by the broadest audience.
 
Last edited:

Blah

Free supporter
1,924
Posts
11
Years
lol, relax dude {XD}


Does your upcoming "- OAM generation/manipulation routine" might deal with that? I mean, altering existing OAMs, or just generated ones?

Yeah it does. I'm still working on making it load arbitrary images too, but that will take a little more time.

The reasoning is more "people willing to research are scarce as it is so focusing our efforts onto the same two, most powerful / useful / well-documented ROM bases instead of spreading ourselves thin for what is basically completionist / superficially different reasons that are otherwise basically redundant" than what you listed. FireRed already has a hack by Jambo51 to allow the use of lots of flags, so that isn't really an advantage for Ruby, either.

That and FireRed has over 511 Safe-non-temporary flags to use as it is (without the hack).

That sounds lazy to me lawl. "Well it's not researched, so why research it lol" is a horrible line of reasoning.
I'm figuring out assembly at the moment so I'd love to do all the dirty work but can't right now. :/

Yeah, it is lazy. I don't have time or patience to hack something that's not my preferred base. Ruby is like Emerald with less features and more bugs. Anyways, I'll address your points now.

Ruby doesn't have a giant chunk of wasted free space, and lets you manipulate more flags (albeit outside normal RAM) than FR or E. Using the debugger to find RAM offsets of things is far easier (say, with graphics). I see little reason not to research it.
There is no such thing as "wasted free space". File Sizes for the GBA are static sized because the cart size is 32MB max. When dumping the ROM, the dumpers trim the file size down to just the amount used (for Pokemon games that size is 16MB). If your argument is that the free space appended to the end of the file isn't present in Ruby while it is for other bases, then that just means you have less free space to hack the ROM with and add features to it. Though ROM expansion is very easy these days with tools existing to do the process for you. However, this should be testament to show you how much more efficient Emerald is than Ruby if Emerald has more features and a smaller base file size.

As for the GBA's RAM, it's the same amount of RAM for each. See http://problemkaputt.de/gbatek.htm#gbamemorymap for a full RAM Map out for the GBA. Also without a free chunk of RAM space (like FR's 0x203C000 area) you cannot repoint the save blocks to include more flags, saved datastructures ect.. in general. Finding RAM offsets for structures are generally easy IF you know what the structure is like, and what to look for (this is where the superior research of the other bases come into play).

The reason I use Ruby is because it's easier to hack, period. The transition to extended ROM support isn't quite complete yet and its nice not worrying about that.
What? Ruby is in no way "easier" to hack than the other bases. If anything, it's harder and less fruitful. Fire Red is the easiest to hack out of all the bases, period. Other more popular bases are starting to require expansion support because they're so far ahead of R/S that all the wonderful hacks can't possibly be supported with the original file sizes. Anyways, this whole issue with expansion dis-compatibility was caused by poor programming practice in general by tool writers. However, you can't blame those who are working for free, and three years ago, probably couldn't imagine we'd have this many new things!

Because you think Emerald and FireRed are programmatically superior is no reason to other people regarding what's most comfortable with them. If they're picking their fruit over which ones others are picking as opposed to what tastes best to them they're missing the point.
You're partially right here. Everyone has their preferences, my favourite ROM is FireRed. It's a nice coincidence that FireRed is pretty much the awesomest base ever. In general, hack what you want, but if you're hacking a low resource ROM, then I will tell you what the disadvantages are and the better options. From there it's your choice on whether or not you prefer quality over a sense of nostalgic likeness or whatever. No one will ridicule you for hacking what you want, we're all doing this as a hobby :)

As for the topic, I don't think it's right that the elitism promoting only those two bases shortchange Ruby from having more assembly work done for them. I'd like to see better hacks for Ruby, and while I really don't care about Sapphire or LeafGreen, I'm not against using them simply because I prefer something else. My opinion weighs the same as everyone else's.

I'll likely end up doing this myself later on anyway so it doesn't matter.

The elitism is well justified. This is something you need to understand. These popular ROMs ARE better alternatives. Initially, the most popular ROM was Ruby, but people figured out why it wasn't the best. Which led to the ROM hacking trend we have now. Anyways, as I said prior, it's always your choice to hack what you want. I for one, have no interest in hacking Ruby.
 
Back
Top