Zelda 1 in Links Awakening for the gameboy.

[daid]

I made a hack for Link's Awakening for the gameboy a year ago. Where I implemented the whole overworld and dungeons of NES Zelda1 into it.

The patch file is here:
https://daid.eu/dump/zelda1.ips

It needs to be applied on an english 1.0 version of "Links Awakening DX".
(Common filename is "legend of zelda, the - link's awakening dx (u) (v1.0) [c][!].gbc")

Now few notes:
* This only works on GBC, not on DMG, no classic gameboy support due to needing more VRAM.
* It does NOT work in VBA, this is intentional. This emulator causes random glitches in vanilla LADX. Stop using it. BGB, Sameboy or mGBA are valid replacements. If you get the BAD EMU message, then this is very intentional.
* It's build on my randomizer tech, https://daid.github.io/LADXR/ feel free to check that out as well. I've done a lot of cool stuff with LADX.

Finally, I submit this to the queue. But, the reviewer rejected it with:

After testing, this seems incomplete. There are several problems with it. First, it doesn't seem to work in some emulators or on real hardware. Second, the seems to be no way to beat the boss in Level 2.

This project looks very promising and seems almost there, but needs some polish. It would be a good idea to open a thread for this in the Personal Projects section of the forums to show everyone what you have so far and seek assistance refining it.

As there is no way to tell this person "You are wrong". I'll just leave it at a forum post. As this was played on real hardware (GBC and Gameboy-Player). And it was completed AND speedrun by multiple players, so it's not incomplete and unfinishable. It's just like the Zelda1 NES, where things are a bit "random" in which order you can do things and where items are located. It's not a straight forward path like later games.

As this was made over a year ago, I don't know the exact details of everything anymore.

Quick prove that it is fully playable: https://www.youtube.com/watch?v=dIbU5FHlNHo

[kemenaran]

This may be the largest rom hack for Link's Awakening ever.

Daid patched so many things in the game engine to get this working – and then created an terrific amount of content to go along – throwing a few original puzzles as well. The result blends Zelda 1 and Link's Awakening almost to perfection.

Please let this submission be approved and published!

[Rabite890]

I've had no problems running this on my Everdrive GB X7. Still playing it, but I see no reason to prevent this from being uploaded if there's a mention of it not working in certain emulators or on original GB.

[PowerPanda]

This is seriously cool. I just ran into 1 problem. By replacing one of the keys in the dungeon with the big key, my normal route through the Eagle dungeon ended up with me at a locked door that I couldn't get through. i need to go grab the bombs, then come back.

[lexluthermiester]

It does NOT work in VBA, this is intentional.

See below.

This emulator causes random glitches in vanilla LADX. Stop using it.

That might happen in older versions of VisualBoyAdvance. VisualBoyAdvance-M 2.1.4, the latest version, works perfectly with all GB, GBC and GBA games.
https://github.com/visualboyadvance-m/visualboyadvance-m/releases/tag/v2.1.4

Finally, I submit this to the queue. But, the reviewer rejected it with:

After testing, this seems incomplete. There are several problems with it. First, it doesn't seem to work in some emulators or on real hardware. Second, the seems to be no way to beat the boss in Level 2.

This project looks very promising and seems almost there, but needs some polish. It would be a good idea to open a thread for this in the Personal Projects section of the forums to show everyone what you have so far and seek assistance refining it.

As there is no way to tell this person "You are wrong". I'll just leave it at a forum post. As this was played on real hardware (GBC and Gameboy-Player). And it was completed AND speedrun by multiple players, so it's not incomplete and unfinishable. It's just like the Zelda1 NES, where things are a bit "random" in which order you can do things and where items are located. It's not a straight forward path like later games.

You might want to review RHDN policy.

https://www.romhacking.net/policy/#Hacks

https://www.romhacking.net/policy/#Homebrew_Non-Permitted_Items
"Emulator Specific Hacks: Any hacks that are known to only run properly on a single emulator such as ZSNES or Nesticle only hacks."

This policy also includes limitations imposed to exclude any one emulator. The fact that you are seemingly excluding certain emulators is very likely why it was rejected. This is not allowed.

All hacks submitted to RHDN are required to be emulator agnostic.

So if you are deliberately excluding compatibility with certain emulators, it's going to get rejected for violating the above policy. If you remove those limitations, you'll likely get your project approved.

Hope this helps clarify things a bit.

[ifightdragons]

See below.
That might happen in older versions of VisualBoyAdvance. VisualBoyAdvance-M 2.1.4, the latest version, works perfectly with all GB, GBC and GBA games.
https://github.com/visualboyadvance-m/visualboyadvance-m/releases/tag/v2.1.4
As there is no way to tell this person "You are wrong". I'll just leave it at a forum post. As this was played on real hardware (GBC and Gameboy-Player). And it was completed AND speedrun by multiple players, so it's not incomplete and unfinishable. It's just like the Zelda1 NES, where things are a bit "random" in which order you can do things and where items are located. It's not a straight forward path like later games.
You might want to review RHDN policy.

https://www.romhacking.net/policy/#Hacks

https://www.romhacking.net/policy/#Homebrew_Non-Permitted_Items
"Emulator Specific Hacks: Any hacks that are known to only run properly on a single emulator such as ZSNES or Nesticle only hacks."

This policy also includes limitations imposed to exclude any one emulator. The fact that you are seemingly excluding certain emulators is very likely why it was rejected. This is not allowed.

All hacks submitted to RHDN are required to be emulator agnostic.

So if you are deliberately excluding compatibility with certain emulators, it's going to get rejected for violating the above policy. If you remove those limitations, you'll likely get your project approved.

Hope this helps clarify things a bit.

Isn't it about time the policies are updated, though?

In my experience, they are not being applied equally or consistently, and I've come across a lot of hacks here that certainly are _not_ "emulator agnostic".

Reviews are often declined, citing policies. But I weekly see reviews accepted, though being just as non-adhering to outdated policies. For instance, if someone posts a hack that is buggy, or in the wrong category (happens daily), pointing this out in a review is not allowed, unless you also write an essay on the entire hack. That's ridiculous. Yet still, a ton of reviews like these exist on the site, and most people find them useful for staying away from buggy or bad quality hacks.

Not to mention the categories. Way too many hacks fall under the "Improvement" category, whilst objectively _not_ being improvements at all. Perhaps introducing another category besides "Complete" would fix this. A suggestion would be "Alteration".

This is meant as respectful criticism.

[Shadic]

Yeah - there's a huge difference between "your hack can't rely on a specific emulator" and "your hack can't exclude a specific emulator (while working on hardware".

One means it wouldn't work as a game for the specific console it's made for, and the other, it would.

Which ultimately is what it should be about, isn't it?

[PowerPanda]

So, as a suggestion, daid, why not remove the restriction from the rom itself, and put in the readme and patch description that people using VBA might experience glitches or other issues.

If the goal is that every patch on RHDN is truly emulator agnostic, then half of them would need to be taken down, as they don't work with Nintendo's official Canoe emulator running on the NES and SNES mini.

But back on topic, this patch is way too cool to not be hosted by RHDN. Our community would be losing something if we didn't grant access to it.

[lexluthermiester]

Isn't it about time the policies are updated, though?

In my experience, they are not being applied equally or consistently, and I've come across a lot of hacks here that certainly are _not_ "emulator agnostic".

Reviews are often declined, citing policies. But I weekly see reviews accepted, though being just as non-adhering to outdated policies. For instance, if someone posts a hack that is buggy, or in the wrong category (happens daily), pointing this out in a review is not allowed, unless you also write an essay on the entire hack. That's ridiculous. Yet still, a ton of reviews like these exist on the site, and most people find them useful for staying away from buggy or bad quality hacks.

Not to mention the categories. Way too many hacks fall under the "Improvement" category, whilst objectively _not_ being improvements at all. Perhaps introducing another category besides "Complete" would fix this. A suggestion would be "Alteration".

I didn't chime in to start an argument or debate about site policy or how they are administered in general, only to offer clarity about this particular situation.

This is meant as respectful criticism.

I can appreciate that. However, the matter is not open for debate. The OP is deliberately sabotaging the functionality of their hack. VBA was not the only emulator tested. It would seem it failed to run on several emulators.

Additionally, there is another policy that such exclusion violates:
https://www.romhacking.net/policy/#Hacks_Non-Permitted_Items
Disablers: Hacks that deprive a player of basic gameplay elements or contain incomplete or game breaking changes are not permitted. Some examples include invisible player sprites, corrupt graphics, nonsensical text, broken sound, removing basic player movements, or disabling all attack possibilities.

Excluding specific emulators qualifies as disabling and thus is disallowed for this reason also.

So, as a suggestion, daid, why not remove the restriction from the rom itself, and put in the readme and patch description that people using VBA might experience glitches or other issues.

This would be acceptable.

If the goal is that every patch on RHDN is truly emulator agnostic, then half of them would need to be taken down, as they don't work with Nintendo's official Canoe emulator running on the NES and SNES mini.

Incorrect. Just because a particular ROM hack does not run perfectly on a particular emulator is not the problem or responsibility of the author. The general(but not exclusive) goal of game modders is to make sure their efforts can run on the original platform, which emulators emulate. Therefore, making a hack in a way that deliberately excludes any one emulator, or group of emulators, is unacceptable.

But back on topic, this patch is way too cool to not be hosted by RHDN. Our community would be losing something if we didn't grant access to it.

Agreed.

Folks, the discussion about site policy is off topic, does not belong in this Forum section or this thread. The pertaining matter was discussed and addressed. Any further off topic discussion will result in moderation. Please get back on topic. Thank You.

[MathOnNapkins]

I just want to chime in that if there are any issues with getting something approved on the site, the forum is not the appropriate avenue. Please use https://www.romhacking.net/contact/ to establish a dialogue with the Submission staff when you have a problem.

There is, of course, nothing wrong with making a thread to show off your hack even if RHDN isn't hosting it, provided it meets other requirements of this subforum.

~Thanks

[Trax]

I gave it a try, and so far it's a nice project. However, it is obviously not complete, in an unambiguous manner. Mostly because of text dialogues.

• The telephone tip line is "TODO" text.
• Granpa dialogue is "TODO" text.
• In the first dungeon, far left room, the old man says a line of gibberish letters, which I guess is equivalent to a "TODO" text, but it could be a bad pointer.
• The dream level is impossible to complete or exit once you jump down one stage. You have to force save. The place feels like an incomplete level.
• I saw one place with glitchy graphics during the transition between two Overworld screens. This one is minor, in my opinion.
• I saw one place where Link becomes glitchy tiles when stepping in shallow water, and stays that way until you leave the screen.
• The locked door problem in the first dungeon, like PowerPanda pointed out. This one is more in the questionable design category.

I don't know a lot about the differences between emulators, so I can't really evaluate the hack in that regard, but for the actual content, I would not approve this hack based on the issues above. I see this as a very advanced WIP, with mostly good material so far.

[daid]

All hacks submitted to RHDN are required to be emulator agnostic.

In that case, I won't be submitting it anymore. As I refuse to support something as broken as the old VBA (VBA-M is fine). It needs to die, it's broken, buggy, unsupported and a curse on the gameboy homebrew development scene.

As for accuracy, VBA passes like 40 of the ~240 emulator accuracy tests. But that's not the biggest issue, the biggest issue is that they added some hacks to make certain games work, but those hacks do not match real hardware at all and cause random glitches.
The gameboy develement scene is pretty clear on this, VBA = Very Bad Accuracy. It's only good at emulating VBA, not GB/GBC.


But, as this is the rule. Then, almost ALL hacks should be removed. As they won't work on the https://binji.github.io/posts/pokegb/ emulator. (just to point out how stupid the rule is)

• The telephone tip line is "TODO" text.
• Granpa dialogue is "TODO" text.

[/list]

Oh, I left TODO texts in? I should update that indeed.

• In the first dungeon, far left room, the old man says a line of gibberish letters, which I guess is equivalent to a "TODO" text, but it could be a bad pointer.

[/list]

Actually, every old man says gibberish. It was actually part of a bigger puzzle that the rando community solved. I should remove those texts as solving the puzzle leads to nowhere now.

• The dream level is impossible to complete or exit once you jump down one stage. You have to force save. The place feels like an incomplete level.

[/list]

This is actually intentional. The idea was that you need to break the 4th wall to escape the dream. But you're not the first to be confused by it.

• I saw one place with glitchy graphics during the transition between two Overworld screens. This one is minor, in my opinion.

[/list]

This is really really hard to prevent in all cases due to how the game works. LADX did a very good job at managing this without ever causing graphic glitches.

• I saw one place where Link becomes glitchy tiles when stepping in shallow water, and stays that way until you leave the screen.

[/list]

oh? I would like to see that, remember which room?

• The locked door problem in the first dungeon, like PowerPanda pointed out. This one is more in the questionable design category.

[/list]

Yeah, it's one of those "how close should I stay to the Z1 design" for that dungeon. As it's the first dungeon, I wanted to stay very close to Z1, but still introduce the boss keys. And that indeed makes logic a bit complex.

[xenophile]

* This only works on GBC, not on DMG, no classic gameboy support due to needing more VRAM.

I'm hesitant to touch on this, except to note Nintendo it's self published plenty of GBC games that didn't run on DMG. Talking to the reviewer and getting more details at the time might have been enlightening.

* It does NOT work in VBA, this is intentional. This emulator causes random glitches in vanilla LADX. Stop using it. BGB, Sameboy or mGBA are valid replacements. If you get the BAD EMU message, then this is very intentional.

This is the real reason I'm replying: I'm curious what you are doing to detect VBA? If the check you are running is checking for functionality this hack requires that VBA hasn't bothered to emulate correctly, I would find that really interesting.

Even if it isn't something you can strictly point to as causing problems, in my opinion you should "name and shame" the bug (because it's got to be a bug) that you are detecting in VBA.

The thing about emulators (once again, IMHO) is if a game can detect that it's not running on real hardware, then whatever happens is the emulator's fault. To take a page from the C's policy on undefined behavior, "it is legal for it to make demons fly out of your nose", and any responsibility for said nasal demons would be the VBA author's fault.

That said, I've put a fair amount of effort in my own main hack to working around a very common emulator bug (including in my go-to emulator for debugging) triggered by choices the original programmers made. Namely, Final Fantasy Adventure "mutes" the music by setting it to a pitch above what the human ear can hear, and it seems when you you digitally synthesize the sound in an emulator you actually need to special case these ultrasonics to avoid an annoying buzzing.

Lastly, thank you so much for your work disassembling Final Fantasy Adventure, and your patience dealing with my questions and patches. It has been a huge help to me allowing me to do a lot more than I would have been able to do otherwise.

[eeHeeY]

This is actually amazimg.

[Trax]

The thing with the Dream Level is, there is no way for the player to know that. Even though I think it's a wonky gimmick, at least if there was a hint about it, it would make a bit of sense.

As for glichy transitions, I wouldn't mind that much. Many games of that time had minor visual glitches, but we just ignored them. Out of curiosity, what would be the process for removing those glitches? It seems like it happens because the game must switch to a different graphics bank before the transition starts.

As for glitchy Link, after playing a bit more, I realized it was not related to any specific tiles, but only because of a specific combination of inputs, including left+right, which is not possible on real hardware. I think the original game also does this glitch on emulator.

For the first dungeon, I suggest you remove the door (right wall in map room), and use the Old Man to hint about the need for bombs.

[daid]

As for glichy transitions, I wouldn't mind that much. Many games of that time had minor visual glitches, but we just ignored them. Out of curiosity, what would be the process for removing those glitches? It seems like it happens because the game must switch to a different graphics bank before the transition starts.

Yeah, it happens because the game switches out the graphics on map transition. The vanilla game prevents this by never having enemies that use the same graphic "slots" in rooms next to each other. I didn't bother to check that, as it's quite complicated to get right.

The thing with the Dream Level is, there is no way for the player to know that. Even though I think it's a wonky gimmick, at least if there was a hint about it, it would make a bit of sense.

When I get around to update this hack, I'll most likely add a kid with a 4th wall breaking hint. As the kids also break the 4th wall in vanilla LADX.

As for glitchy Link, after playing a bit more, I realized it was not related to any specific tiles, but only because of a specific combination of inputs, including left+right, which is not possible on real hardware. I think the original game also does this glitch on emulator.

Yep, that's a stock glitch. Normal hardware doesn't allow left+right or up+down. Most emulators also block this input. (some replacement shells do not properly block this)

For the first dungeon, I suggest you remove the door (right wall in map room), and use the Old Man to hint about the need for bombs

Note that bombs are only needed if you go "up" first, if you go "right" first you do not run into this issue.


EDIT: This is my last note on the blocking emulator issue. It's my decision as an author to do that. It's romhacking.net decision to not allow that. And I'm keeping it at that. Note that this hack is just an spinoff of my main project, which is the randomizer, which has a lot of potential for bugs, so that's where the block comes from. As I put in a lot of effort to chase down bugs in the randomizer. Any more mention of the emulator block will be ignored by me to keep the focus of this topic on the hack itself. You're free to discuss this elsewhere.

[lexluthermiester]

In that case, I won't be submitting it anymore. As I refuse to support something as broken as the old VBA (VBA-M is fine).

The problem there is that VBA-M is based on VBA and shows the "BAD EMU" screen. The only emulator I can get it working on is BGB in Windows. This is unacceptable. VBA-M is an amazing emulator and my go to emulator as it does everything GB/GBC/GBA. I was able to run it on GBC-Emu from Robert Broglia on Android, another amazing emulator and my other go to. It will not work on my GBA ROM player on my NDS.

The reality is that you as an author should be focused on the hack itself, not what emulator people are running it on. It is especially disingenuous for anyone to be codifying such limitations.

If you choose not to list is here, that is unfortunate as this is an especially interesting project, you've done something very cool with Links Awakening!

You can always remove the limitation and make suggestions in the description for what emulator you recommend and why. No rule against doing that.

For the first dungeon, I suggest you remove the door (right wall in map room), and use the Old Man to hint about the need for bombs.

Level 1 doesn't seem to have enough keys. I had to go looking for bombs to finish it.

[erpster2]

The problem there is that VBA-M is based on VBA and shows the "BAD EMU" screen. The only emulator I can get it working on is BGB in Windows. This is unacceptable. VBA-M is an amazing emulator and my go to emulator as it does everything GB/GBC/GBA. I was able to run it on GBC-Emu from Robert Broglia on Android, another amazing emulator and my other go to. It will not work on my GBA ROM player on my NDS.

The reality is that you as an author should be focused on the hack itself, not what emulator people are running it on. It is especially disingenuous for anyone to be codifying such limitations.

totally agree on this part.  the game seems to have poor or bad detection of VBA-M and can't reliably distinguish between the old VBA and new VBA-M emu.  I had no problems running it in BGB and TGB Dual (don't ask why I ran it in tgb dual as that is my secondary emu on my Win10 computer)

If you choose not to list is here, that is unfortunate as this is an especially interesting project, you've done something very cool with Links Awakening!

I think the OP already made that choice and it is best that he do NOT submit it here in the RH site if he can't follow the RH site rules and insists on following his own rules, which makes him even more "disingenuous." while the game is fully playable, it is still incomplete as I found some other minor issues (no  "magnify glass" item which is needed to read that certain "book" in the library room to obtain the correct path in the Wind Fish Egg maze [aka. Level 9]; the "entrance" to that Wind Fish's Egg does not stay open after playing the Ballad of the Wind Fish song and exiting Wind Fish's Egg - the Ballad of the Wind Fish song has to be played again to "reopen" the entrance; also the Moblin Chief or Moblin King in the Moblin Cave area can be battled many times - does not stay beaten after exiting Moblin Cave & re-entering that cave resets or "respawns" those Moblins and the Moblin Chief; and of course those missing "Old Man" tips which to me feels like an unfinished or incomplete beta version)

I'll wait a few months from now and I'll check back in 2023 to see if the OP will make an improved version with the Old Man tips included along with other bug fixes

Level 1 doesn't seem to have enough keys. I had to go looking for bombs to finish it.

I did not encounter that specific problem when I fully played the 1st dungeon, maybe because I got the bombs first before entering level 1.  though I got free bombs from the 2nd dungeon (level 2) since I do some "level skipping" or "level hopping", something that was kinda necessary from the old Zelda Challenge Outlands NES hack.