Sonic and Sega Retro Message Board: Changing Sonic 2's level format - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 4 Pages +
  • 1
  • 2
  • 3
  • 4
    Locked
    Locked Forum

Changing Sonic 2's level format

#16 User is offline Quickman 

Posted 09 January 2006 - 02:20 PM

  • Posts: 5584
  • Joined: 03-December 03
  • Gender:Male
  • Location::x
  • Project:omg porjcet
  • Wiki edits:10
Seems like jman wants to write his own Sonic game for the Megadrive. It's something I was looking at for a while.

#17 User is offline Ultima 

Posted 09 January 2006 - 02:48 PM

  • Games Publisher
  • Posts: 2394
  • Joined: 26-January 03
  • Gender:Male
  • Location:London, England
  • Project:Publishing mobile games!
Ahahaha, you can ask Stephen - I was considering the exact same scheme, but for 16x16 instead of 64x64 XD

#18 User is offline jman2050 

Posted 09 January 2006 - 04:16 PM

  • Teh Sonik Haker
  • Posts: 625
  • Joined: 10-December 05
  • Wiki edits:4

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

#19 User is offline Ultima 

Posted 09 January 2006 - 04:55 PM

  • Games Publisher
  • Posts: 2394
  • Joined: 26-January 03
  • Gender:Male
  • Location:London, England
  • Project:Publishing mobile games!
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.

#20 User is offline jman2050 

Posted 12 January 2006 - 11:58 AM

  • Teh Sonik Haker
  • Posts: 625
  • Joined: 10-December 05
  • Wiki edits:4
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

#21 User is offline drx 

Posted 12 January 2006 - 12:07 PM

  • <Shade> fuck MJ
  • Posts: 2156
  • Joined: 02-March 04
  • Gender:Male
  • Project::rolleyes:
  • Wiki edits:8
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

#22 User is offline Tweaker 

Posted 12 January 2006 - 01:25 PM

  • Posts: 12389
  • Joined: 27-June 04
  • Gender:Male

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?

#23 User is offline jman2050 

Posted 14 January 2006 - 08:05 PM

  • Teh Sonik Haker
  • Posts: 625
  • Joined: 10-December 05
  • Wiki edits:4
Posted Image

An uninteresting picture, save one little detail :thumbsup: (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 :)

#24 User is offline LocalH 

Posted 14 January 2006 - 10:39 PM

  • roxoring your soxors
  • Posts: 3210
  • Joined: 11-January 03
  • Gender:Male
  • Location:wouldn't you like to know
  • Project:Guitar Hero II: Rhythm Games Community Edition aka Pizza Hero II: Electric Pizza
  • Wiki edits:3
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.

#25 User is offline jman2050 

Posted 14 January 2006 - 10:50 PM

  • Teh Sonik Haker
  • Posts: 625
  • Joined: 10-December 05
  • Wiki edits:4
Too bad I have no way to test on real hardware. Not to derail, but what would be the best way to do that?

#26 User is offline LocalH 

Posted 14 January 2006 - 11:35 PM

  • roxoring your soxors
  • Posts: 3210
  • Joined: 11-January 03
  • Gender:Male
  • Location:wouldn't you like to know
  • Project:Guitar Hero II: Rhythm Games Community Edition aka Pizza Hero II: Electric Pizza
  • Wiki edits:3
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).

#27 User is offline Quickman 

Posted 15 January 2006 - 09:37 AM

  • Posts: 5584
  • Joined: 03-December 03
  • Gender:Male
  • Location::x
  • Project:omg porjcet
  • Wiki edits:10
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

#28 User is offline jman2050 

Posted 15 January 2006 - 10:31 AM

  • Teh Sonik Haker
  • Posts: 625
  • Joined: 10-December 05
  • Wiki edits:4
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...

#29 User is offline Sonic Hachelle-Bee 

Posted 15 January 2006 - 07:43 PM

  • Lost in Wood zone
  • Posts: 720
  • Joined: 03-March 04
  • Gender:Male
  • Location:Paris, France
  • Project:Sonic 2 Long Version
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? :thumbsup:

Else, it seems a good work.

#30 User is offline jman2050 

Posted 15 January 2006 - 09:36 PM

  • Teh Sonik Haker
  • Posts: 625
  • Joined: 10-December 05
  • Wiki edits:4
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.

  • 4 Pages +
  • 1
  • 2
  • 3
  • 4
    Locked
    Locked Forum

2 User(s) are reading this topic
0 members, 2 guests, 0 anonymous users