I've done a similar thing with Sonic 1 once. I changed the 256x256 mappings to 128x128 (http://www.hacking-cult.org/html/128.png)... It worked quite well =P
Wouldn't that involve rewriting hardcoded tile effects such as auto-spin in tubes and path swappers on loops?
An uninteresting picture, save one little detail (hint: look at the HUD) As of now, it works perfectly, although right now it decompresses each level block all at once instead of gradually as I originally intended. No slowdown though interestingly enough (though EHZ isn't exactly the best example when testing slowdown). The BG warping does get weird past a certain point, though I'm not too concerned about it. Now all I have to do is finish this makeshift editor I'm doing, and then I'm in business for the rest of ym hack
If you really want to test for slowdown, convert CPZ to that format and see how it runs on real hardware. CPZ always exhibits more lag on real hardware, at least concerning NTSC.
Too bad I have no way to test on real hardware. Not to derail, but what would be the best way to do that?
You can do it yourself either with a Tototek flash cart or an old-school cart copier. Or, you can send the ROM to someone who has the capability for doing the same. I'd be willing to test it out, as long as your ROM isn't larger than 2MB (although I doubt it is at this point).
Considering EHZ 1 required 14 different compressed files as well as some extra binary files that I added jump tables for EHZ 1 only at this point, I imagine it would crash horribly. And on another note, found out why my level wasn't decompressing using my routine. Stupid retarded me forgot that the stack pointer is like any other pointer in that it must be even to be able to read words from it correctly... took exactly 30 seconds to fix. I hate programming sometimes...
Strange screenshot jman2050. First, where is the background deformations lines not defined at the bottom? Well, you may have fixed these ones manually. Second, I don't know how your HUD is working, and I'm curious. This is pixel by pixel coordinates that you show here, one for the character and one for the foreground camera. There is almost nothing to do with 128x128 tiles. Third, both Y coordinates are same as normal. Can you explain that points a bit more please? Else, it seems a good work.
Well, it was more a demonstration that I had extended the size of the level. I assure you, the 64x64 level format is working (almost) correctly. I'm sure could get something together to demonstrate it in action, though. Oh, and for the record, the level in that screenie is the data for EHZ1 and EHZ2 spliced together very roughly. Just because. As of now, objects work correctly (though I'm worried the respawn-tracking array might be too small, but I'll relocate it if neccesary), but the rings don't work, so I'll look more into that. I'm more intrigued by how I could screw around with the terrain with the 64x64 tiles, but I need more work on my editor before I can do that effectively.
On Tweaker's suggestion, I'm releasing a rough, unfinished, but working proof-of-concept rom. http://www.cgi101.com/~jman2050/bullet.bin ONLY EHZ 1 1P works. Don't try anything else on this rom, as very bad things will probably happen. It's pretty much the exact same zone as before, but with a twist (hint: read my previous posts). You can't complete the level per se (there'll be a sign, but it's garbled and you won't be able to exit the level), but it is a full zone. My editor isn't far enough along to demonstrate the 64x64 tile format fully, but you can dump the RAM with KMod to see how much space has been freed up. Plus, there is a tiny, almost unnoticable section of the level that is quite impossible to draw using 128x128 tiles Tell me what you think. You want to see a fully expanded level to demonstrate the changed level format, or should I get around to actually implementing this into something great?
It works on hardware, but there's the same bug I saw in Cinossu's hack and mentioned here, regarding VRAM. Other than that, I didn't notice any problems that you didn't already mention (like what happens when you hit the end sign).
That's actually kind fo odd. The only thing I remember changing as far as loading level art loading is concerned is making two passes to the routine instead of one (soit doesn't decompress beyond address $4000 of ram). Don't know why that would trigger the bug. Just asking, but you sure it isn't a problem with the disassembly itself?
Very Cool I wonder if you could make it dynamically reload levels as well, so suddenly you're in CPZ at the end of EHZ.
That might be a bit harder since you pretty much have to reload with the new art. You could have the pallet fade to black, load new art, and fade back up. Or, you could do something like AIZ where you run through a small tunnel and the pallet changes, although this way you couldn't reload all the art, but only part of it.
Nice work! I like the way you pass trough one act to another. I'm absolutely certain (100% sure) that you can reload all the art and all the whole level to switch to another quickly. I was going to do something similar than this hack to test (without 64x64 tiles obviously), but with all levels linked. I scrapped the idea, because I tested by doing something else, and then, this was more wasted time than anything else.
