rainwarrior wrote:Yes, I knew about that bug. It's been fixed for a long time, but there was never any intention to update that demo. (There will be a new demo several weeks from now with the final release.) Thanks for the report, though.
By the way, it's not a "secret world" or anything. You've just wrapped to the top of the screen and ended up touching the trigger to enter the room above. You can get there normally.
Oh! Good to know that you fixed it already. Can't have something silly like that, slipping through!
I'm well aware of what's "technically" going on. I said secret world, in reference to a famous glitch in Metroid. It is the same glitch, with incorrect tile-sets between areas. (But correct object formations)
Once in a blue moon it'll just do this randomly while walking around. While holding still it might flip back to being normal, and do it a few times. Most of the time it does not do it at all. No flickering during, just wrong tiles. A CHR bankswitch gone wrong?
That's really odd. CHR is non-bankswitched RAM, so I don't think it should be possible for the CHR to be "bankswitching". CHR-RAM is written during room transitions, but there should be no hardware mechanism that lets the titles change while playing. CHR-RAM is also written in contiguous 1K blocks, and what you're showing looks like an address mangling.
If you compare the CHR layout that's supposed to exist at that moment to what you've got, it's really weird. It's like any tile in the columns 0-3 / 8-11 are reading from columns 4-7 / 12-15 instead, which I think might correspond to PPU A6 being forced to 1 when reading CHR (but not nametable)? (Or alternatively: D2 of the nametable fetch read?)
Does transitioning between rooms fix this, or does it just flip randomly while playing?
I'm pretty sure this is a hardware failure for the Everdrive, you might send a report to Krikzz.
Well if it's CHR RAM then probably no, not bankswitching related I would blame the cartridge edge, but as you mentioned it doesn't look like the nametable was having any addressing issues.
The sprites were also fine during. I'll hook up the NES again (it's in a box) and see if I can coerce it into doing it again. I don't remember if a room transition helped, but I do remember it flipping to this and back to normal without me doing anything, just holding still. The owl above moved like nothing was wrong.
Actually I think we can rule out the nametable fetch getting corrupted, because in your screenshots the sprites are showing the exact same corruption. I think this is PPU A6 being forced to 1 during CHR fetches.
The owl looks fine because its sprites are in columns 13-15, all unaffected.
The lizard sprite look mostly normal because the body sprites are arranged in pairs of columns across all columns. The face, however, is susceptible to corruption and you can see it in the picture you took. Face tile $2A has been replaced with cigarette tile $2E.
rainwarrior wrote:Actually I think we can rule out the nametable fetch getting corrupted, because in your screenshots the sprites are showing the exact same corruption. I think this is PPU A6 being forced to 1 during CHR fetches.
The owl looks fine because its sprites are in columns 13-15, all unaffected.
The lizard sprite look mostly normal because the body sprites are arranged in pairs of columns across all columns. The face, however, is susceptible to corruption and you can see it in the picture you took. Face tile $2A has been replaced with cigarette tile $2E.
You're right. It's possible the cartridge edge's A6 was simply making intermittent contact. I didn't play any other games during that sitting so I didn't see the possible effect on other games.
I've been silently following the Twitter and Kickstarter updates, and I'm so exited for how Lizard has been shaping up. I wish I had the proper equipment and internet connection to live stream Lizard once it's released, but I'll still enjoy it.
The trick of updating the tint color is a great idea for performance profiling...I used it on a well known game to get an idea of how much "frame time was left".
I ended up using greyscale because it was the easiest to notice for the game I was looking at
That's not comparable. You only do prototyping, revision, iteration, etc. in one language. The other one is just a port, basically. For analogy, it's sort of like asking whether it took longer to write The Three Musketeers in French, or the English translation.
If you're asking whether I think it's quicker to do things in C++, my answer is absolutely. It's hugely more efficient, and that's the main reason I do it.
Programming is probably only <20% of the work on this project though. By far what has taken the most time overall has been building/editing/revising/testing the world.