83881067 visitors

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 - snarfblam

Pages: [1] 2 3 4 5 6 ... 20
Gaming Discussion / Re: Contra the way God intended
« on: October 21, 2014, 06:04:01 pm »
The only way I can really play the original Contra and find it interesting is to try to beat it without dying. But I am a big fan of the spread weapon. It helps balance the challenge of beating the game without dying, and it's just plain fun to send some bullet hell back at the enemies.

ROM Hacking Discussion / Re: Screenshots
« on: October 20, 2014, 05:15:47 pm »
In grammar school I was taught the no word ending in s gets an 's.

This is also what I was taught, but to be fair, English teachers tend to pick pet "rules" to teach and enforce even though there may more than one "rule" considered acceptable, and many of the grammar rules that you see people calling each other on have no basis beyond that one person one day decided that something was no longer proper, even though it was considered 100% acceptable for ages beforehand.

Personal Projects / Re: Metroid Blast
« on: October 17, 2014, 06:28:39 pm »
The calls to the sound engine are part of the NMI routine; one of the last calls it makes. My point, though, is that any changes to banking will cause problems that will need to be fixed.

Personal Projects / Re: Metroid Blast
« on: October 16, 2014, 05:30:36 pm »
If you're only modifying data in the address range reserved for the sound engine ($B000-$BFFF), this shouldn't cause problems with Editroid. One thing Editroid certainly won't like is if you try to open a ROM that is output from a project build or a test room.

If you insert a more complex music engine, you'll probably need to put it in its own bank, which calls for bank swapping. Bank swapping during gameplay (or while NMI is enabled, to be specific) causes problems, and Editroid inserts some code to fix this but that wouldn't be able to accommodate additional bank swapping without modification.

ROM Hacking Discussion / Re: Screenshots
« on: October 13, 2014, 04:51:15 pm »
I'm not usually a big fan of RPGs but Lagrange Point certainly looks like it's worth checking out. I tried playing it before but I'm sure I'll stick with it a lot longer when I have some idea of what's going on.

Site Talk / Re: Add game genie codes to Datacrystal WIKI?
« on: October 05, 2014, 05:28:51 pm »
Game genie codes should be decoded and their information added to the relevant RAM/ROM map. There are utilities that can decode them. Many emulators do this as well.

Unfortunately, many hacks simply aren't tested on hardware, and some hackers aren't even interested in whether or not their hack works on actual hardware. If a hack doesn't work on hardware, this can be noted as part of the description or a review.

General Discussion / Re: Data Crystal Website has no text
« on: September 28, 2014, 07:17:11 pm »
At the moment, I'm as confused as anybody else, but it seems to be back up now. I'm not sure exactly what the issue was, but it looks like the wiki software was updated to a newer version. Maybe the wiki was in some kind of glitched maintenance mode, or maybe the wiki was updated to fix the issue. At any rate, no pages were lost. The source for every article was still accessible the whole time.

Newcomer's Board / Re: !!! Mario Kart on Game Boy Color project !!!
« on: September 27, 2014, 06:53:23 pm »
No, I don't want necessarily someone to do it for me, but rather that it becomes a cooperative work. First, it would be nice if you could explain to me how to edit a file .gbc because when I open it with Tile Layer Pro I can not see in more of 4 colors (and even other editor).

A couple of things to understand. One, it's near impossible for a less experienced hacker to pull together a group project involving more experienced hackers. Group projects tend to fall apart unless they're run by a skilled, driven person who can hold everything together and push the project forward, so people tend to shy away from cooperative hacking unless you have some demonstrable progress and experience right off the bat. The other thing is that, from what I understand, the race tracks, graphically, are stored as some sort of compressed video. Tile editors will be useless if this is the case. You would need to reverse engineer the video format, write a dumper and inserter, and finally edit the graphics.

ROM Hacking Discussion / Re: Porting a Gameboy game to NES
« on: September 27, 2014, 06:42:35 pm »
You could remake the games for NES based on the GB/C versions. You could probably even reuse most of the data and graphics, but all the game's code would have to be re-written from scratch. The two systems have completely different architectures and different capabilities. For example, NES has much more screen real estate, whereas GBC has better palette support.

Due to copyright reasons, RHDN does not distribute ROMs. We distribute patches, which you apply to a copy of the original game. The FAQ addresses patching (soft patching and hard patching), although I'll admit the explanations are brief and outdated.

At any rate, the short version is that you need the original ROM the hack/translation is based on (you can verify you have the right version of the ROM with the ROM/ISO information listed on the hack/translation page using a utility like the one linked to in my signature), and then you can extract the patch from the archive and apply it to a copy of the ROM using an appropriate utility: Lunar IPS for .ips files, beat for .bps files, xdelta for .xdelta files, etc..

Front Page News / Re: Utilities: IPS Patch Checker
« on: September 20, 2014, 02:34:16 pm »
More or less what I was thinking. Patches don't always need to overwrite each other to conflict. In rare cases, I've seen patches overwrite each other without causing issues, too, but, then, that's a scenario a tool like this couldn't account for. There is also the occasional patch that is intended to be applied on top of another. I'd also be concerned about "99%" compatible patches. If that 1% is code or important data, there's a pretty good chance you're 100% screwed.

As long as the user understands exactly what "compatible" means here, I suppose there isn't an issue. Maybe something like "No conflicts detected" vs. "Warning: Patches conflict (x bytes, y%)" would be clearer.

ROM Hacking Discussion / Re: Animating Tiles in SMB1
« on: September 17, 2014, 03:12:49 pm »
Do you understand, in theory, how you would even do something like that? You would either need to animate the CHR (which requires a mapper conversion or a conversion to CHR RAM) or add new tiles (good luck, there's no free space in the CHR ROM) and animate the nametable (good luck keeping track of what needs to be animated). It sounds like a simple modification, but unless I'm overlooking an easier option, SMB lacks the necessary features out of the box and as I understand it, there's very space in the ROM to add new data/code/GFX without expanding the ROM and using a mapper.

Site Talk / Re: Submission questions
« on: September 11, 2014, 05:49:20 pm »
why do some submissions have the CRC calculated for the main data, when they require the headered rom
This seems to be a common point of confusion. There are two different things you can calculate a hash for: a ROM image, and a file. Sometimes they're the same thing (headerless SNES ROM for example). Often times they aren't (iNES ROM, SMD format Genesis ROM, etc.).

There is an advantage to using a ROM hash instead of a file hash: it will tell you if you have the right ROM, even if it's in the wrong format or has a corrupt header. We recently had a few submissions to "correct" hashes for SNES hacks. Different people got different file hashes from different copies of the same valid ROM, due to differences in the SMC header. This is why emulators only deal with and provide ROM hashes.

You can specify either a ROM or a file hash for a submission. Both would be preferable, but at the very least, you should specify whether the hash is calculated based on the ROM or the file.

Now let me shamelessly plug this little doohickey: ROM Hasher. It calculates the preferred hashes and presents them to you in a ready-to-copy-and-paste format specifically for RHDN submissions. It's also good for verifying ROMs. It checks them against the No-Intro database, and provides details about the format, headers, etc.

Front Page News / Re: ROM Hacks: Legend of Link 1.2 Released
« on: September 06, 2014, 03:17:35 pm »
Yep, the RHDN page has been updated.

Site Talk / Re: Submission questions
« on: September 05, 2014, 10:24:21 pm »
FWIW, you're welcome to include both so people can confirm the patch is applied correctly, but the hashes for patched ROMs are entirely optional.

Newcomer's Board / Re: how to submit a patch
« on: September 04, 2014, 04:41:44 pm »
You need to install dropbox to your computer to be able to upload files onto the Net.
I'd advise against this. Dropbox no longer supports a "public" folder for new users. This is problematic when you need a direct link. At best you can rely on undocumented features (changing www.dropbox to dl.dropboxusercontent) and hope they work, at worst staff has to decide between rejecting a submission because it links to a Dropbox download page and manually fiddling with the download link to make it work.

There are third-party hosting solutions that do the job nicely. If all else fails, there is a reason Nightcrawler was nice enough to provide a feature to upload files specifically for submissions.


Site Talk / Re: Obsolete hack reviews
« on: September 03, 2014, 07:36:10 pm »
Unfortunately, this tends not to be followed, but for this sort of reason, the guidelines state:
Whenever possible you should state the VERSION of the item you're reviewing. This is to ensure users will know what version you reviewed in the future when newer versions are released.

Perhaps it would be a good start if this information were automatically inserted into the text box when a user clicks "Add Review".

Sorry, guess I spaced a bit there. I didn't realize that the MMC50x5130 variable was used right above where it is assigned. Hard for me to follow what you were doing too, since my ASM skills are limited to 6502. Please disregard my nonsense.

Pages: [1] 2 3 4 5 6 ... 20