nesdev.org

I actually fixed palette changes last night. Just a simple oversight. It totally breaks compatibility though. The standard hashing algorithm is still in flux despite the 1.0 release, so these things are unavoidable. Hopefully I can finalize the algorithm soon. Until then, any changes I make are liab...

Okay, thanks for the quick explanation :) So how feasible would it be for GBE+ (the next iteration of this project, with GBA support) to run PocketNES and replace the graphics? Very plausible, in theory. Replacing graphics in GBA games itself is not a big deal on a technical level. As long as Pocket...

@GGuy - This solution only masks the problem of why GBE thinks the two sprites are the same. It still has drawbacks (if the sprite is the same, but uses two different tile numbers at different times, you have one redundant tile that is also mandatory to edit).I still have not figured out the source....

The thing is, it doesn't look like a hash collision at all on closer inspection. It's just that the hashing itself is incorrect. That is to say the algorithm generates two separate hashes (in stand-alone tests) but for some reason when applied in real-time it generates the same hash for the sprites ...

@Teeples - Unfortunately, there is no cute way to handle those cases. If the games split the text between OBJ and BG tiles, that's how the emulator will dump them and that's how users have to edit them. That would potentially result in hundreds of unique tiles. Ideally, any sort of mass editing will...

That reminds me, I still haven't published my general theory about Tile Replacement for systems with tile-based graphics (the SNES included). The paper I'm working on outlines the methods I used, how they are implemented, the specific challenges that require more advanced algorithms and techniques t...

When you say duplicate tile issue, I assume you're talking about the issue brought up on Google Code (involving Metroid II?) I'd love to know (on a technical level) just what exactly is causing that and how to reliably reproduce it myself. I think root may be an issue with XORing the palette data on...

Just be sure to post the source code eventually, since the GPL requires that when distributing binaries based on modded source code. I don't know much about ZSNES (I always used SNES9x) but apparently wikipedia suggests that this netplay functionality was stripped some years ago? In that case, it's ...

Actually, to my knowledge, on the GBA OAM and OAM VRAM are read-only during scanline rendering* They can only be written to during HBlank, VBlank, or Forced Blank. For HBlank, there is the additional requirement that you flip a certain bit in one of the GBA's display registers (DISPCNT) to allow the...

For what's worth, as far as I know the Wii doesn't use 24/32-bit RGB for its framebuffer, but 16-bit YUV (which results in artifacts even with a pure signal since the UV part is given less space). I wouldn't be surprised if it's possible to use the YUV format directly. Does anybody know what's the ...

Not sure if this will help someone make a patch, but I know for a fact that Lufia: The Legend Returns sets the High 9th Bit of the MBC5 ROM Bank even though this technically points to non-existent ROM Banks. Only the low 8-bits of the ROM Bank number should be used in this game. This was an issue I ...

It's more so having dealt with audio software (prior to my involvement in emulator programming) that gives me the impression that Sound Channel 0 sounds weird. Hardly any software I used referred to channels as 0, so to me (even though I've been programming waaay longer than I have making 8-bit musi...

I was pointing out that Sound Channel 0 sounds weird to me. It kind of implies something like it's not used or is muted or something, a /dev/null for sound output or something. Maybe it's just me. I wasn't implying 0 based numbering sounds weird in and of itself, however.

I can't speak personally about SNES development, but I've been doing a lot of GBA work lately. This is just speculation, but perhaps Nintendo tried to make the documentation more straightforward or intuitive for the GBA? That is to say, many programmers are likely used to (and may even expect) numbe...

It would also be possible to do something like: 1) Examine each of the color palettes, calculate the brightness of each color 2) Based on the brightness, try to map this to an equivalent DMG shade of gray when drawing 3) Hope for the best It's something that crossed my mind, although I'm not certain...