[Quickman]

Seems like jman wants to write his own Sonic game for the Megadrive. It's something I was looking at for a while.

[Ultima]

Ahahaha, you can ask Stephen - I was considering the exact same scheme, but for 16x16 instead of 64x64 XD

[jman2050]

Ultima, on Jan 9 2006, 11:48 AM, said:

Ahahaha, you can ask Stephen - I was considering the exact same scheme, but for 16x16 instead of 64x64 XD

16x16? Ok, that's just nuts :P

[Ultima]

Yep. Hence why I didn't take it any further XD

Good luck with this, it'll be awesome if you can get it working.

[jman2050]

Actually, after looking at it and running a small test, I'm thinking it probably won't be too much of a performance hit if I read all the 128x128 chunk definitions directly from ROM without moving them to RAM at all. From what I've seen, the chunk definitions are read from, at most, only about 50 times during the drawing routines, plus the small number of times it's read for Sonic's (and other objects') collision code. Playing through EHZ, CPZ, and HTZ jury rigged to read chunk data from the ROM incurred absolutely no discernable slowdown or odd effects, even in CPZ 2 with the water. Of course, I don't know how this will affect my routines once I get all the extra functionality in, but I definitely want to prioritize this.

If it works as I like, not only do I not have to worry about cumbersome chunk switching mid-level (I would've hated that), but it also frees up a crapload of RAM. Assuming I change the Primary/Secondary level layout switches to 4 bits per 128x128 chunk reference instead of 1, this would free up $3400 bytes of RAM. I could do all sorts of crap with $3400 bytes :D

[drx]

I've done a similar thing with Sonic 1 once. I changed the 256x256 mappings to 128x128 (http://www.hacking-c...rg/html/128.png)... It worked quite well =P

[Tweaker]

drx, on Jan 12 2006, 12:07 PM, said:

I've done a similar thing with Sonic 1 once. I changed the 256x256 mappings to 128x128 (http://www.hacking-c...rg/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?

[jman2050]

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

[LocalH]

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.

[jman2050]

Too bad I have no way to test on real hardware. Not to derail, but what would be the best way to do that?

[LocalH]

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).

[Quickman]

For kicks, what happens when you load an unconverted level? Crashy = fun.

This post has been edited by Quick Man: 15 January 2006 - 09:38 AM

[jman2050]

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

[Sonic Hachelle-Bee]

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.

[jman2050]

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.