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 ... 24
Site Talk / Re: Forum Rule #1
« on: July 22, 2015, 05:57:56 pm »
I don't know if PMing somebody who is being antagonistic is really going to be all that constructive. If someone says something worth responding to, respond. If they're being obtuse, insulting, or if you just find them irritating, ignore them. Don't give them the satisfaction. Don't encourage the behavior. Some things shouldn't be enforced by rules and warnings. In matters of respect and manners, a lot is open to interpretation. Just be mature, give people the benefit of the doubt, and when there is no doubt be the bigger man.

Well, if Trax has any kind of document detailing the relevant data, I'd be glad to whip up a Windows equivalent. I just don't really have the time or patience right now to go through the process of distilling the necessary info from a disassembly or through Red Falcon's source code (objective-C gives me headaches).

They actually remind me of Link's Awakening. Good stuff.

Newcomer's Board / Re: Hacking my own homebrew NES games
« on: July 10, 2015, 05:29:24 pm »
Seeing as you're working with Shiru, I'm a bit surprised you're not looking for help on NesDev, instead. Like henke said, ideally, the customizations would be part of the build process rather than hacking them in afterwords. The degree to which things are automated (slicing graphics into tiles, laying them out in the CHR, palette data, etc) depends on what Shiru has set up. Hacking changes in afterwords would still be doable. From the sound of it, you should be able to whip up a rather straightforward utility that will arrange the CHR, provide basic tile editing capability, and basic palette editing capability. But if you have a repeatable build process in place, creating a new utility is just a redundant effort.

General Discussion / Re: Romhacking tools and a new computer
« on: July 09, 2015, 09:35:37 pm »
Windows 8 is just Windows. It's much like Windows 7, except uglier, slightly more optimized and secure, and there's some silly "metro" thing that I haven't even seen in over a year that some people are still upset over. Also, Windows 10 is supposed to fix all the things that everyone got so mad about in Windows 8. I've been happily hacking with Windows 8 for some time now. Haven't run into any compatibility issues with emulators or anything else that might hinder my hackinations.

Personal Projects / Re: Revenge of the Red Falcon - Final Level
« on: July 01, 2015, 05:46:56 pm »
The difficulty level for this hack is perfect for the handful of us who have been playing Contra for 20+ years. For a lot of people this hack is going to be well over the top. Hell, plenty of people find the original game to be very challenging.

Personal Projects / Re: Revenge of the Red Falcon - Final Level
« on: June 28, 2015, 10:42:22 am »
It looks like bwass.org is serving the IPS as a text document (it shows up in text in-browser for me instead of prompting me to save it). So either right-click the link and select "Save link as..."/"Save target as..." or once you've opened the IPS file as a text document in the browser, just save it from the file menu.

Once you have the IPS file saved, Trax's directions above give you everything you need to know.

Site Talk / Re: Annoying search issue
« on: June 24, 2015, 05:28:12 pm »
Where are you entering "Super Metroid"? Not all Super Metroid hacks have "Super Metroid" in the title, but when I select "Super Metroid" from the game dropdown, I get 83 search results.

Newcomer's Board / Re: Legend of Zelda NES Tile Combos Q
« on: June 19, 2015, 06:58:07 pm »
I wrote a separate program to edit the vertical columns screens are made from (and was actually able to hand-compress them to significantly smaller than they originally were to make space for new columns) but somehow the program seemed to corrupt the ROM I was working with, so I shelved it.

I can share the executable and the source, but I made this over a decade ago, and my programming style was a little more... terrible back then. https://dl.dropboxusercontent.com/u/12027218/Temp/Combificator%20Incomplete.zip

Honestly, though, it would probably be easier and more flexible to re-point the data and edit it with a hex editor. There is a document floating around somewhere that documents the format of this data.

Site Talk / Re: Mapper hacks
« on: June 14, 2015, 09:21:35 am »
Mapper hacks can be useful in theory. If you provide documentation (ideally including source code for the modifications and some template ASM that can take advantage of the mapper change), someone can take it and immediately do something interesting. Much moreso if the author does more than the bare minimum. Although it won't be distributed as a patch, the upcoming version of Editroid converts a Metroid ROM to MMC3. In the process it fully expands it, converts it to CHR ROM, adds CHR animation (via cycling) for backgrounds, modifies some code to allow level data to be stored in any bank, and has routines that can be used to safely perform bank swaps (they aren't atomic/thread-safe, on MMC3) so new code and data can be easily accessed.

Now, hypothetically, if I distributed this conversion for Metroid as patch, should it be allowed on RHDN? If you simply apply the patch, you won't notice any difference in gameplay, but if you intend to hack it, it instantly opens many doors.

In general, we try not to judge the quality or usefulness of a hack. There are certain exceptions to this (e.g. no half-baked naked mario hacks), but for the most part, people's perspectives and opinions can vary widely so we try to be inclusive. Although you or I might find a particular submission to be useless, somebody else is bound to disagree.

I think a mapper conversion should at the very least state in the description that it makes no changes to gameplay or content, and should document its "API" (i.e. where and how do you call the routines to take advantage of mapper features). I don't see a need to ban them though.

Site Talk / Re: Mapper hacks
« on: June 09, 2015, 04:54:14 pm »
Quote from: Submission Guidelines
Improvement hacks are often ones intended to be used as a base for other hacks.

Mapper hacks are permitted as "improvement" based on the rationale that they can be used as a base for a hack that utilizes the new mapper. Although mapper hacks don't add any content to the game per se, they make it possible to add more content or new mechanics when it wouldn't be possible on the original mapper. And incorporating mapper changes into hacks seems to be pretty popular lately.

It's true that repro makers can take advantage of mapper hacks, and it's true that RHDN has no interest in helping repro makers. That doesn't mean that we should restrict submissions on the basis that something might inadvertently help a repro maker.

Another problem I know (by experience!) is that mapper hacks are likely to get rare random crashes. For example in a MMC3 target mapper, $8000 is written to by main code, then is interrupted, $8000 and $8001 are written to by interrupt code, it returns, and $8001 is written to by main code, switching in a bank in the wrong slot, resulting in a crash. It's easy for the hacker to release the hack without noticing this kind of bugs if he does not spend hours playing the hacked game, since in the original games, it wouldn't happen as writes were done by only one instruction.

This is definitely a problem. It's pretty easy to overlook the fact that even on an NES, certain things need to be thread-safe. I'd recommend that anyone planning on doing NES mapper hacks spend some time on the NesDEV wiki and forums. Without those resources, I don't think I'd have been able to do the mapper conversions I've done.

ROM Hacking Discussion / Re: Make a program all in one
« on: June 05, 2015, 05:53:04 pm »
I've released the source code to my ROM Hasher utility, which locates the SNES header to verify the internal checksum. It's written in C#, so maybe it will help. Relevant code would be found in \ConsoleTools\SNES.cs. It doesn't decode the entire header, but if you know how to find the header and you have header documentation, the rest is pretty straightforward.

In most cases, people looking to put together a team are people who are less experienced. They want to do something but they don't know what, or they don't know how to manage a project, or their goals exceed their capability. Add to that that in a hobby setting people are simply less inclined to adhere to their own role and fulfill their assigned responsibilities. Not generally a formula for success.

In my experience, (constructive) collaboration is something that is most likely to happen organically. A project is already started and people who know eachother or that already have some projects under their belt realize they have interests that align and skills that complement eachother's. I haven't done a ton of collaborative work, but when I've worked with others, it was when they already had something good going and I thought I had a way to make it better.

I don't think this is unique to ROM hacking, either. I thing it's something you'll see with most hobbies.

Newcomer's Board / Re: Need help with ZeldaTech
« on: June 03, 2015, 05:19:58 pm »
High nibble is that map Y coordinate, low nibble is the map X coordinate. So for example, if the screen in question is in the fourth row down, eleventh column over, that would be $3A.

General Discussion / Re: Your projects and Repro Carts
« on: June 03, 2015, 05:15:10 pm »
At least as far as NES goes, you can actually buy new cart shells and new boards for certain mappers (I think RetroUSB uses all new carts, boards, and chips including the CIC). Personally, I don't have an issue with repros in principle. The issue is that so many repro makers trash old games to make repros and then sell them without giving any credit to hackers or making any attempt to educate purchasers as to where the hardware comes from or the fact that you're paying for the hardware and labor and not for software.

Also, my Powerpak has a 4GB flash card (which I believe loads MUCH faster than an SD card, suck it SD2SNES :P).
From what I understand, PowerPaks use CompactFlash because the parallel interface allows faster ROM loading (which is driven by the console's CPU). I've never used any other flash carts, and I don't know how they're implemented, but it's certainly possible that a flash cart with more complex hardware could load faster from an SD card.

Newcomer's Board / Re: Need help with ZeldaTech
« on: June 02, 2015, 09:28:06 pm »
The game has a list of warp screens somewhere. If you place a warp cave on a screen not in that list, it will freeze when you try to go through one of the stairways. Looks like the list is at 0x19344 in the ROM file.

Site Talk / Re: Submit Files "Author" menu
« on: May 26, 2015, 05:41:28 pm »
I'm not dismissing your point, but this might help. In typical (desktop) browsers, you can click on the box and type the first few letters of the name you're looking for.

Bad part is, the more attention it gets, the more likely you are to receive a C&D order.

Well, let's hope we don't get the wrong kind of attention. Anyways, congrats Grimlock.  :thumbsup:

Site Talk / Re: Tools mistakenly listed as DOS programs?
« on: May 17, 2015, 07:57:24 pm »
How many of the utilities currently listed as being for MS-DOS are actually command-line programs for Windows?

Unfortunately, many people don't understand there is a difference between the two. I've corrected a couple myself in the past.

Edit: I started sorting through these myself. I went through everything starting with an "A" or "B", and found and edited five mislabeled utility pages. The dead give-away in most cases is the standard MS-DOS stub found at the beginning of windows executables ("This program can not be run in DOS mode").

ROM Hacking Discussion / Re: fceux debug/CDL strange behavior
« on: May 08, 2015, 06:21:08 pm »
At DD2C there is a table that is accessed here:

The table is five bytes long:
1E 1B 1C 21 1F

There is an instruction that immediately follows the table:
07:DD32:A9 00     LDA #$00

Now, here is how the disassembler works: it starts by looking at the first byte at the offset you specify (the up button on the scroll bar moves back one byte at a time) and assumes everything is ASM. It does its best to interpret the data as code. So if you scroll up to DD31, it will see that 1F byte, which corresponds to the ORA absolute,X opcode, which accepts two bytes for its operand. The A9 00 that follows (which is supposed to be an LDA #$00) is incorrectly interpreted as the address $00A9, because the disassembler has no way of knowing better. (It could take the CDL into account, but that could potentially do as much harm as good.)

Or, to put it more simply, if you have the data byte 1F, followed by the instruction LDA #$00, that will take the form of 1F A9 00, and if you have the instruction ORA 00A9,X, that will take the form of 1F A9 00. You can see why the disassembler would mistake one for the other, since they are in reality identical.

why are they logged as data?
I doubt that anything but the first of the three bytes is logged as data, but if you're seeing something different, maybe post a screenshot or the relevant part of the CDL. It could be a bug with FCEUX of some sort.

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