Sonic 2 for PC, 3DS, & Wii

Discussion in 'Staff Projects' started by Clownacy, Nov 24, 2017.

  1. Clownacy

    Clownacy Negative Clownancy Staff

    Joined:
    Aug 15, 2014
    Messages:
    883
    Contest page copypaste:
    Overview
    You might consider the TaxStealth mobile version of Sonic 2 to be a port, but I'd beg to differ: that version was made by recreating Sonic 2 on top of the Retro Engine - while it may look and feel like the original, under the hood that is simply not the case. In that regard, it's about as much of a port as Sonic 2 HD is.

    With that out of the way, this is a port that was done by manually translating the original game's 68000 assembly code to C, and adapting it for PC and New 3DS. A similar thing was done by Sega back in the 90s to produce their PC ports of Sonic CD and Sonic 3 & Knuckles.

    Note that this is an extremely early proof-of-concept: there are barely any objects, there's no Tails, and Sonic cannot die. The only level currently available is Aquatic Ruin Zone Act 1. Debug Mode is enabled by default, so at least you won't get stuck anywhere.

    That said, to showcase the possibilities of this port, I've added some enhancements:
    • The game is in widescreen (in fact, the whole screen's been extended, from 320x224 to 400x240) - this is not possible on the Mega Drive for reasons that should be obvious.
    • Aquatic Ruin Zone's underwater section has an added ripple effect (actually ported from Sonic 3's Angel Island Zone) - while a ripple effect was in Sonic 1, it was removed from Sonic 2, likely for performance reasons.
    • The music has been replaced with the original demo tracks by Masato Nakamura - the original game didn't use these, primarily because of the massive amount of cartridge space they would take.

    Please note that this port is meant to be as accurate to the original game as possible (barring the above contest-only enhancements), so you may encounter a number of vanilla bugs, such as Sonic having trouble jumping out of shallow water and Debug Mode causing him to behave like he's underwater even when he isn't. These are intentional.

    Controls
    Keyboard:
    • WASD - Movement
    • O - A
    • P - B (Debug Mode)
    • [ - C

    PC gamepad:
    • D-pad / Left Stick - Movement
    • A / Cross - A
    • X / Square - A
    • Y / Triangle - B (Debug Mode)
    • B / Circle - C

    New 3DS:
    • D-pad / Circle Pad - Movement
    • B - A
    • Y - A
    • X - B (Debug Mode)
    • A - C

    Platform Support
    The PC port is Windows-only. It's 32-bit, and relies on SDL2, so it should be fairly compatible.

    The New 3DS port will not run on the original 3DS (XL), or the original 2DS. Also, because it's a homebrew CIA file, it will need to be installed with FBI, which requires your New 3DS have Custom Firmware. For the audio to work, you'll need to dump your DSP.

    Screenshots:
    [​IMG]
    [​IMG]
    [​IMG]

    Old video from back when this had EHZ:

    I've been working on and off on a PC port of Sonic 2 for about two years, which I initially worked on in order to teach myself C and SDL2.

    Back in August, after tiring myself out with Cave Story modding, I finally picked up the project after a year-long hiatus, and put to use what I'd learnt in that time. This included the addition of level drawing, a shortlived rebase on OpenGL, and a port of the Sonic object. This turned the port from a silly little demo program called EGGMANQUEST into something actually resembling a port of Sonic 2.

    What, you think I'm joking?
    [​IMG]

    It started to look like the project was finally coming together, and with the Hacking Contest on the horizon, I thought I'd brush up what I had so far, and let it finally make its debut.

    While cleaning up the demo, I was reminded of my time porting my own game to the 3DS. Figuring it would demonstrate my port's portability (harr harr), and help set it apart from Sonic 2 HD, I began working on a 3DS version, ditching the (albeit crappy) OpenGL backend for a software renderer. Unfortunately, the renderer wasn't as efficient as it could be, limiting it to New 3DSs only.

    ...So why does it say 'Wii' in the thread's title?
    [​IMG]

    Basically, to prove a point, I dropped it on the Wii in an hour or two.

    Unfortunately, this was a few days after the contest deadline, so it couldn't be submitted. It was a really quick-and-dirty port, anyway: it doesn't have sound, and it's in 4:3 (why the hell does the Wii have a 4:3 framebuffer?), so I guess that's not a huge loss.

    I suppose I should say how you use the thing. Extract the contents of the 'Wii' folder to the base of your Wii's SD card, and that should be all for installation. Of course, you have to run it from the Homebrew Channel.

    Controls are...

    Wiimote:
    • D-pad - Movement
    • 1 - A
    • 2 - B (Debug Mode)
    • Minus - C
    • Home - Quit

    Wii Classic Controller/Wii U Pro Controller/Wii U Gamepad:
    • D-pad - Movement
    • B - A
    • Y - A
    • X - B (Debug Mode)
    • A - C
    • Home - Quit

    Download here.
    Up to date versions here.

    Also, as a bonus, I dug up two old builds of EGGMANQUEST I had lying around on Dropbox, in case anyone's curious:
    2015 version
    2016 version
     
    Last edited: Jul 13, 2019
  2. Pacca

    Pacca Why succeed when you can profit off of failure? Member

    Joined:
    Jul 5, 2014
    Messages:
    1,149
    Location:
    Triton (Moon)
    I honestly can't believe that I've never heard of the demo tracks before; I looked the rest of them up and was wowed; If you don't know what they are either, here's a video with all of them. Thank you for introducing me to them :D

    That said, the original tempos often don't line up with the final S2 music, which makes them sound "off", for lack of a better word. Would you be willing to speed them up?
     
  3. Calvin

    Calvin DreamCast Enthusiast with a GameCube Member

    Joined:
    Mar 1, 2014
    Messages:
    245
    Location:
    $C800
    Might I kindly ask that you lift this requirement from the file internally?
    [​IMG]

    Even if it comes at the price of low FPS, the simplicity of the engine has me doubting that the o3DS can't actually handle it.
    And, if it doesn't, I'd like to put down some time to debug whatever crashing might occur with it.
    More so, I'm interested in the details about how it will "not run."
     
  4. Clownacy

    Clownacy Negative Clownancy Staff

    Joined:
    Aug 15, 2014
    Messages:
    883
    Not really, no. For one, the music is a temporary feature for the contest - it won't be in the final build. Also, I don't see why I should force altered audio on everyone else, when you could just edit the files in Audacity yourself.

    The game runs at like a third of its full speed! I don't like releasing something that's that unplayable.

    Also, I already explained why it doesn't run on Old 3DSs:
    Each line of each tile in both the foreground and background requires reading through the level layout, chunk table, and block table. (400 / 8) * (240 / 8) * 8 = 12000. That's a lot of calculations, and that's just for one plane, and that's not even counting the partially off-screen tiles. Then you have the other cycle-hog: the part where it converts the screen from an indexed bitmap to a 24-bit bitmap. The 3DS's lack of fragment shader support means I have to convert all the pixels in software. There's only so much 200MHz can do.

    I know a dirty-drawing system much like the original Mega Drive game should be possible, and I did once experiment with offloading the colouring stage to the OS's CPU core, but I had a deadline to meet, and figured I'd rather get audio working instead.
     
    Last edited: Dec 6, 2017
    Calvin and Pacca like this.
  5. Xeal

    Xeal The Nuke Retired Staff

    Joined:
    Mar 10, 2016
    Messages:
    227
    Why in the world would you demand someone make something broken just so *you* have an opportunity to play it? Sod off with that kind of mentality and learn to live with what you're given. It's a bloody test demo that has fuck all in it and can easily be run on a PC when it can't be run on a system it wasn't designed for.
     
    Clownacy likes this.
  6. redhotsonic

    redhotsonic Also known as RHS Retired Staff

    Joined:
    Aug 10, 2007
    Messages:
    2,968
    Location:
    England
    Woah, calm down, Xeal. He hardly "demanded" it. He also said he wouldn't mind playing it on the original so he could debug if needed. If anything, he's offering to help.
     
    Blazer, Ralakimia, Calvin and 6 others like this.
  7. Natsumi

    Natsumi Phoenix egg Member

    Joined:
    Oct 7, 2011
    Messages:
    699
    Location:
    Long and dangerous river
    Yeah, it seems more like a simple question, and some of their thoughts put in, to which Clownacy explained calmly why it wont be a thing. As you should very well know, Xeal, there is a difference between someone begging for something, and someone just asking out of curiosity.

    And Speaking of curiosity, would it make any sense to implement a VDP plane-like system, for faster access of tile data directly for each onscreen tile, and the tiles offscreen would get then loaded correctly (maybe even full chunks?) Would seem to make much more sense and be faster. That being said, I also do not understand the engine or 3DS.
     
    Calvin, ProjectFM and AkumaYin like this.
  8. Clownacy

    Clownacy Negative Clownancy Staff

    Joined:
    Aug 15, 2014
    Messages:
    883
    Look, if I'm gonna be honest, I didn't like the post's tone either. 'Might I kindly ask', 'the simplicity of the engine has me doubting that the o3DS can't actually handle it', 'I'd like to put down some time to debug whatever crashing might occur with it', 'I'm interested in the details about how it will "not run."', all comes off as a little patronising and 'I know better' to me.

    I mean, I wrote the thing, I know why it doesn't run well on an Old 3DS, so I deemed it unplayable and locked it off. There aren't any crashes, and the current engine really is too much for the Old 3DS to handle, so why am I being told the opposite?

    To me, the post just feels less like 'How come this doesn't work?', and more like 'I won't believe you until I see it myself'.

    Oh thanks :U

    I really want to avoid emulating as much of the Mega Drive as possible. Granted, when I eventually add the title screen, I'll need to find a way to support plane maps, so true VDP plane emulation might happen anyway.

    The most obvious problem I can think of is what if the screen is larger than the plane? By emulating planes as accurately as possible, I'd have to support arbitrary plane sizes, which would limit the potential to increase the size of the game window.

    If you just mean caching each tile to a plane-like buffer, that's what I plan to do when I add dirty-drawing.
     
    Last edited: Dec 6, 2017
    ProjectFM, AkumaYin and Xeal like this.
  9. Natsumi

    Natsumi Phoenix egg Member

    Joined:
    Oct 7, 2011
    Messages:
    699
    Location:
    Long and dangerous river
    Yeah I was not suggesting you try to emulate (any) part of the VDP, that's just silly idea. I was suggesting a buffer basically, whether it be actual art buffer or just tile buffer, whatever works best. I find that despite even using very large buffers, there are almost no drawbacks on modern systems anyway. RAM usage wont usually go very high.
     
  10. Calvin

    Calvin DreamCast Enthusiast with a GameCube Member

    Joined:
    Mar 1, 2014
    Messages:
    245
    Location:
    $C800
    My apologies for the post's tone being other than intended, but thank you for the explanation.
    (It was a bit of "I won't believe it until I see it," but more under the idea that "I believe it can with some effort." I was looking more to see what the severity was, and if it would be worth trying to optimize, whether it be from one person or another's effort to do so.)

    It would be nice to see the underclocked speed version available somewhere, perhaps less "out in the open," but if you're uncomfortable with even that, I can understand why.

    Regardless, this is a cool thing to see. I was thinking about a similar idea, being a Sonic 1 port for PC, but I heard that Markey was already doing something of the sort, so I moved on.
    Even in it's early state, and from what I see thus far, I feel that Sonic 2 especially will benefit from the higher resolution, and I'll probably have more to say (on the Discord, or editing this post) after trying out the Wii version. If you ever plan to finish this port, then best of luck.
     
    Last edited: Dec 6, 2017
  11. Clownacy

    Clownacy Negative Clownancy Staff

    Joined:
    Aug 15, 2014
    Messages:
    883
    Code:
    - threading (fuck no)
    - proctex (lolwut)
    - linked list dirty rendering (wat)
    - Wii audio
    - SonLVL integration (external collision arrays)
    - More enemies
    - AND OR blitting (nope...)
    - Old 3DS Frameskip (pfft)
    - New plan: move the colouriser to the second core, optimise the hell out of the blitter, and Bob's your uncle
    - Blit different colours to different framebuffers, and render them with vertex colours? (nope)
    - Extra new plan: switch to tile-based drawing, and merge the colouring stage with the blitting stage, to reduce palette line calculations
    - Alright, let's be more clear: the current renderer is tile-scanline-based. It's simple, but slow as ass.
      My idea is to make the renderer emulate the VDP much more closely: by emulating planes, I can render
      entire tiles instead of scanlines. This allows me to cache palette line calculations for all 64 pixels.
      Also, by directly emulating planes, I can simply port the original game's level drawer, so that's cool.
      Anyway, as I said above, I could potentially merge the colouring stage with the blitting stage if I do
      so, though I'm not sure if that would be good for performance. I'm also not sure how I'd make priorities work.
    
    Attempt 9000000:
    So we start off with the two planes. We parse them, and put the high-priority ones into a list for later [NOPE].
    The low background doesn't need an alpha test: just set the first colour in every palette line to the
    background colour, and memcpy the pixels. The other layers need an alpha test.
    
    We'll be using a 'flooded buffer' for the indexed bitmap: room will be given so that entire tile-lines can be
    written, even if they go outside the bounds of the screen. This will allow us to do the AND OR trick with
    longwords, since tiles are 8 pixels/bytes wide. [old ARM doesn't like unaligned writes, so no]
    
    Then it will be the colourising stage that clips the flooded buffer, and rotates the framebuffer.
    
    Also, add a mode for the foreground, so it doesn't do the per-scanline scrolling stuff. [turns out I can't]
    This is a snippet of my to-do list for this port. For the last year I've been trying to figure out how to make this fast enough to run on the Old 3DS. As you can probably see, it didn't go well.

    The 3DS is useless. For starters, its GPU doesn't support fragment shaders, so the one part of the drawing process I could use hardware-acceleration for - applying the palette - I now can't. So I'm stuck doing everything in software... except the CPU is slow as mud: a 268MHz ARMv6 with only one actually-usable core. Great. And to add insult to injury, the 3DS's framebuffer? It's sideways. So on top of blitting and colouring in software, I also have to rotate the framebuffer, which takes a good 20% off my cycle budget.

    For the past year I've been plodding away, trying every possible optimisation I could think of, but it wouldn't help. No simple optimisation would help that the software-renderer alone was using 300% of CPU time. Was it a lost cause? Surely it had to be possible: I mean, Sonic 1/2 3D run on Old 3DSs, and they're emulators. Not to mention they have to draw two screens per frame.

    So I started planning a complete rewrite of the renderer, this time emulating the VDP much more closely. As ironic as it sounds, emulating the VDP's planes is faster than skipping them entirely, so building a renderer around those could be just the breakthrough the port needed.

    But something like this would take ages to write, and I've been burned before, spending days working on a fancy new drawing method, hoping to at least save some performance, only to have it thrown back in my face by making everything slower. I didn't want to try this until I had time to burn, and was sure it would work.

    So months passed, until finally August rolled around. I had some spare time, and my notes were all fresh in my memory, so I got to work. While the original software-renderer was developed on PC, and merely ported to the 3DS later, this one was running on there from its earliest test builds.

    Results were promising: a single plane took only a fraction of the CPU. Things got more complicated when I added sprites and the second plane, but I was still scraping by at about 90% of the CPU's threshold.

    Then I plugged it into the port. The game ran at half-speed.

    No, it wasn't the game itself using up the rest of the CPU (the engine only takes 1%), it was the compiler. Somehow, between the test program and the actual game, the compiler was giving up on whatever optimisations gave the test an edge. So the colour/rotate stage for instance went from 32% CPU time to 40%. When the test was already running at 90%, that's bad.

    After that, I was pretty much ready to give up on the 3DS. I've been stuck trying to get this working for a year, for crying out loud. But after some more optimisations - some good, others hackish abominations that should be accompanied by animal sacrifice - things started to look up: I found a faster way to draw sprites by using an incrementing pointer, I experimented with compiler flags, and even found a crazy way to optimise plane blits while also obeying priority with a 16KB LUT.

    All in all, if my checks are accurate, the newest build scrapes by at around 85%!

    So why go through this much effort to support some handheld from 2011? Well... why not? This is a port of a game from 1992 - it should be able to run on the 3DS. So I figure it makes a good benchmark: if it can't run on a 3DS, I'm doing something wrong.

    And I think it paid off: if I wasn't targetting the 3DS, the port would still be using its awful original software renderer. Heck, it would probably still be using its old OpenGL backend, calling multiple functions and sending numerous floats to the GPU just to draw 8 pixels of a scanline, when the software renderer can do the same thing by just copying two long ints.

    And if the 3DS isn't your thing? These optimisations benefit the other builds too: back when I released the SHC 2017 demo, I was using my desktop PC. Way more of a powerhouse than the flimsy laptop I use nowadays. And that demo? It doesn't run too great on this laptop. Now, with these optimisations (and way better use of SDL2's API...), the port uses only 15% of the CPU.

    With this nonsense finally behind me, I can move onto actually porting stuff again. But before that, I figured I'd clean a few things up, and make another release:

    As far as the game itself goes, nothing's really changed. It's still an empty ARZ Act 1. Still, a few bugs and inaccuracies have been fixed, and I've added pausing, so there's that.

    The Windows build, as well as being faster, now lets you resize the window. You can also enter fullscreen by pressing F1.

    As for the Wii build, I figured out how to get a vaguely 16:9 framebuffer (432x240), so that port's finally joined the widescreen club. Still no audio though.

    If you're interested, here are the download links:
    Windows
    3DS
    Wii

    On the 3DS, you can install straight from FBI using this QR code (select the 'Remote Install' option at the bottom):

    [​IMG]

    Installation instructions and controls are the same as before, sans the 1 & 2 buttons on the Wii being swapped.
     
    Last edited: Oct 31, 2018
  12. OrdosAlpha

    OrdosAlpha RIGHT! Naebody move! Administrator

    Joined:
    Aug 5, 2007
    Messages:
    1,780
    Location:
    Glasgow, Scotland
    YES! An update to the best thing in last years's content! Only gripe, the midi sounding ogg. Other than that, it feels like I'm actually playing Aquatic Ruin from Sonic 2.
     
    kenny0989 and EMK-20218 like this.
  13. Spanner

    Spanner The Tool Administrator

    Joined:
    Aug 9, 2007
    Messages:
    2,386
    Well it is the original demo tape from Masato Nakamura that was used here...
     
  14. TogeFIzz

    TogeFIzz Newcomer Trialist

    Joined:
    Jun 29, 2019
    Messages:
    4
    Problem on Wii: When I booted the app on the Homebrew Channel, all I got was what looks like a garbled crash handler. Despite this, I'm excited for where this could go!

    Edit: After this, I tried it on my laptop (Which is, shall we say, pathetic) and I got quite the opposite result! It worked like a charm. No noticeable lag of any kind. Great job!
     
    Last edited: Sep 1, 2019