don't click here

Sonic Classic Heroes

Discussion in 'Engineering & Reverse Engineering' started by flamewing, Nov 2, 2010.

  1. Spyro Cool

    Spyro Cool

    Member
    12
    0
    1
    I've found a glitch in the hack.

    I was playing as Tails and Knuckles alone, and in Emerald Hill Zone Act 2, when I walk into most springs (usually diagonal ones), I kinda teleport backwards (usually into a wall and then I die).

    Hope I helped!

    EDIT: Same for those different kind of springs (near the life) in CPZ Act 2 (I was using Tails and Sonic alone)
     
  2. Lanzer

    Lanzer

    The saber calls for its master... Member
    6,845
    4
    18
    Glendale, AZ
    Living life.
    Just a curious question.

    Should this project be moved to SEGA-CD type format at some point? I heard theres limitations to Genesis rom formats that stops projects from going any farther then a certain point whereas the SEGA-CD rom formats don't have soo many limitations.

    Wasn't that the reason Megamix was transfered from Genesis to SEGA-CD?

    Anyways, can't wait to see what else you implement flamewing. this project is one of my favorites.
     
  3. Covarr

    Covarr

    Sentient Cash Register Member
    4,233
    3
    18
    Trapped in my own thoughts.
    Two stageplays, a screenplay, and an album
    SEGA CD has the same palette limitations as a stock Genesis. These palette limitations could be overcome by a move to 32x, but not SEGA CD.
     
  4. muteKi

    muteKi

    Fuck it Member
    7,941
    170
    43
    Well there are space limitations, but there are also different (and potentially more restrictive) limitations on the Sega CD; you can only work with like 256kb or at a time. As it so happens, though, a standard Sonic 1 cart is only twice that size. It's unlikely a Sonic hack would end up hitting that limit unless it tried to create a Sonic game with only a single level spanning the entirety of the game.

    Now, if a 1MB expansion RAM cart (like they have for the Saturn that some games need, I don't mean a second save-backup cartridge) existed for it, then there'd be lots of memory to use.

    However, if you can break things up into that restriction you have
    • HUNDREDS of MB to work with otherwise, given that whole CD has lots of space.
    • The ability to play on real hardware without the use of a flash cart (which is probably going to be more expensive than a Sega CD + Genesis combo on, say, eBay).
    • Scaling/rotation in hardware for sprites or background layers, as long as there's room in the VDP to support it -- even the SNES didn't support sprite scaling!
    • CD audio support and more PCM channels to work with for music and sound playback
    "Limitations" here is extremely vague and depends very strongly on the scope of the hack.
     
  5. theocas

    theocas

    Tech Member
    346
    0
    16
    I'm sure you're not quite aware of what a beast the Sega-CD is to program. Essentially, you need to have every level be it's sort of own self-contained code that contains the engine, objects from that level and stuff like that. That way, you can fit the code into the SCD's program RAM. To load all your art, you'd need a sort of bootstrap code that loads it from the CD, then a program on the MD's main CPU that DMA's it to the VDP or some shit like that. During that time of DMA, no new art can be loaded.

    Scaling and rotation of sprites is a HUGE pain. There's literally no documentation on the SCD's Video ASIC, and scaling and friends essentially doesn't work on sprites, but little art tiles that you'll need to DMA into the VRAM on the MD to get a good effect.

    As for palette limitations - you can get around them even on a regular stock MD. Just change the palette mid-display, or use a technique known as "Hold and modify" which is when you place two graphics on top of each other to get more colours.

    No.

    (Geeky mini-rant: Kb implies Kilobits meaning you'd only have 32 KB (kilobytes) to work with, which is definitely not true.)

    A 1 MByte RAM expansion cart has NOTHING to do with this, since a) the sub-CPU can't execute any of that code since the cartridge port isn't mapped in it's memory as far as I know, and the main MD CPU still needs a sort of bootstrap to jump it to the correct location. As a matter of fact, I'm not even sure if the cart port is mapped into the MD CPU's address space when the Sega CD is attached.

    The Sega CD places quite some limitations on the programmer. The way the CD is laid out is a huge pain, as you need to use pointers and it just gets incredibly messy after a while, which is when you want to shoot yourself in the head. There's only about 256 KB of "Word RAM" or RAM that'll hold data such as art and the like for your game while it's running. There's 512KBytes of program RAM that you can store your program to run on the Sub-CPU in, but some of this is used as a CD data buffer (IIRC it's 128KB) and some other beginning regions are used by the BIOS.

    I've been programming the Sega CD (albeit in Mode 1, which means code runs from the cartridge but uses the Sega CD hardware (which may be more fitting for this occasion, like for example, enhancing the game with a CD-DA soundtrack) and the limitations are a pain. Unless you have a burning reason to port all your code to it (which by itself is like a marathon of work by itself) and then make a ton of adjustments for it to run properly, it simply isn't worth it, so it's best to just stay away from the Mega Drive peripherals unless you 110% know what you're doing.

    *dial tone*
     
  6. LazloPsylus

    LazloPsylus

    Buried under SSRG Somewhere Tech Member
    154
    0
    0
    Academy City
    SSRG, world domination, a billion and one research projects...
    To tack on to theocas's post, there are actually two modes that the Sega CD can run in, generically titled Mode 1 and Mode 2. The mode that the Sega CD runs in depends on arrangement and coding.

    Mode 2, which a grand majority of Sega CD titles use, use the Sega CD as the source for the code to be executed. The reason that the code on the Sega CD has to be broken into executable chunks (and why it's such a pointer nightmare) is because the data on the CD has to be passed from the Sega CD to the Genesis in order to be displayed and run. Despite the code being stored on a CD and read by the Sega CD first, it is the Genesis that has to carry out the final processing and execution of the code. The size limit exists so that the code can be loaded into the shared RAM bank between the Sega CD and Genesis and then finally executed by the Genesis. As mentioned on this board in the past, each of those binary chunks are essentially self-contained games, each containing all the data needed to run the game, as well as pointers to the next binary needed in the . To better understand, look up how Sonic CD's MMDs work. Anyway, the size limit exists simply because of the shared RAM bank. If the chunk is too big, it can't be handed over to the Genesis and finally executed. Mode 2 is the best way to take advantage of the Sega CD's hardware, since the work required to handle things such as Cinepak processing and scaling can be processed by the Sega CD before the interrupt is signaled to transfer access to the Genesis.


    Mode 1, on the other hand, is very uncommon. Being used in a very small selection of games (Flux and Pier Solar are the only two titles I can recall at the moment), the game data is primarily stored on the cartridge, with the ability to access the Sega CD. Details on Mode 1 are not too easy to come by, seeing as the number of people who have dealt with Mode 1 is extremely low, and is complex in execution (to understand why, you'd have to understand some of the more intricate details about how the Sega CD works). So, to summarize, only two games used it, and almost no one knows how to use it.


    To get Genesis code to work with the Sega CD is no small task for either mode, and the advantages aren't too applicable for this particular hack. Really, if flamewing were to port his hack to one of the add-on systems for the Genesis, the most beneficial would be 32x. That being said, however, the porting to 32x is still an undertaking, and flamewing seems to be handling things just fine on the Genesis. There's not really a reason to consider porting as a major reason right now unless he really wants to, and considering the work that entails, I'd guess that he doesn't. Let him be and watch what he can pull off. The Genesis can do quite a lot more on its own than people really give it credit for.
     
  7. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    69
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    For what is worth, I am not too worried about size limitations yet; with everything that is in the hack, it is less that 2 MB in size -- less enough that, were I to disable padding, I could almost paste the entire Sonic 1 ROM at the end and still be below 2 MB. Size limit for a ROM -- without using the SSF2 mapper -- is 4 MB: this means I still have a lot of space even without the mapper. I could fit 3-4 teams in there, depending on art size.
     
  8. Ralbalboa

    Ralbalboa

    Member
    31
    0
    6
    Please paste Sonic 1 = Sonic 1 & 2 Heroes. Someone already said that :) . It would be owesome!!!! This hack is great. Thanks a lot for your hard work. Thanks.
     
  9. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    69
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    Pasting Sonic 1 on the end would just add a bunch of useless data at the end; to actually make Sonic 1 & 2: Heroes takes a lot more than pasting. I used that only as an example of just how much padding there is at the end of Sonic 2: Heroes because it has a more visual appeal than saying 'I have about $99D7A bytes of padding at the end of the ROM'.
     
  10. Ralbalboa

    Ralbalboa

    Member
    31
    0
    6
    Yeah... I know... was just saying. You didn't even finished sonic 2 heroes... so... I was just remembering someone at the very beginning of this thread saying it.
    Sorry. Keep the hard work, please, hope to see this one finished some day, cause I'm a Sonic Heroes fan and when I saw this, well, simply amazing. Thanks a lot!!!!
     
  11. The Shad

    The Shad

    ↑ & ↓ & ↻ Oldbie
    3,073
    8
    18
    Finally gave the newest revision a spin and oh my god, I wanna put this game on a cart and make it my standard way to play Sonic 2. Truth be told, I'm not 2's biggest fan but this really makes it worth it!
     
  12. For what it's worth, how long would it take to make a Sonic 1 Heroes Rom? Because of the jumbled palette, code and all things Knuckles, I'm sure it wouldn't be as easy as copying and pasting the companions coding from one place to another, or copying the level data over Sonic 2's existing code.

    More on the subject of balancing, I wouldn't be against totally nerfing areas that characters like Knuckles and Tails thrive in a Sonic 1 Rom. (Marble Zone, A1, Going over that wall.)
     
  13. Endgame

    Endgame

    Formerly The Growler Member
    Has the bug where in Barrier Eggman when you switch characters you end up above the fight been fixed yet? I still haven't managed to get past that yet (although it may have been a few revisions before the latest one since I've played it)
     
  14. muteKi

    muteKi

    Fuck it Member
    7,941
    170
    43
    Well, that's the problem, isn't it? Aside from those areas there's not much benefit to having the other two characters around in the first place!
     
  15. Intense Co-op Usage, Activate!
    [​IMG]
    The only problem is, you'd have to code when the other characters are missing.
     
  16. flamewing

    flamewing

    Emerald Hunter Tech Member
    1,161
    69
    28
    France
    Sonic Classic Heroes; Sonic 2 Special Stage Editor; Sonic 3&K Heroes (on hold)
    Yes, quite a few revisions ago.

    On a totally different front -- I am looking at UI ideas, and want to know which one is your favorite:
    1: [​IMG]
    2: [​IMG] 3: [​IMG]
    4: [​IMG] 5: [​IMG]
    (and no, I have nothing against keeping the current one (1) -- just brainstorming)
     
  17. amphobius

    amphobius

    not so gone, after all Member
    2,133
    19
    18
    Thrash '25
    You know, this just seems like trying something different for the sake of it. As well as it being weird to have the lives in the upper right, it's also obstructing the view. It's in an area where you need to look where you're going, and there's probably a good reason why that isn't used in the original games.

    Yes, I realise Generations is doing the exact same thing, but it's a lot more minor considering the FOV and screen size.
     
  18. Miles3298

    Miles3298

    Member
    590
    30
    28
    Definitely 1, for reasons made clear above.
     
  19. The Shad

    The Shad

    ↑ & ↓ & ↻ Oldbie
    3,073
    8
    18
    Having just beat the latest revision (like 10 minutes ago), I gotta definitely say 1. It's just natural to glimpse at the bottom left when you're checking your lives/order. While I see what you're trying to do, I just don't think it'll work in a 2D game where you usually need that area to see what's coming up. It just feels in the way.

    Also, has anyone mentioned the wonky ass Ball Shooters in Oil Ocean? I'd randomly go flying out of them and be lucky to land on solid ground, lol
     
  20. Covarr

    Covarr

    Sentient Cash Register Member
    4,233
    3
    18
    Trapped in my own thoughts.
    Two stageplays, a screenplay, and an album
    DalekSam is 100% correct. 1 is the best.