SoniCPort SoniCPort, as the title of this thread would imply, a C port of Sonic 1. About the Project I started this project about a month ago, mainly because I wanted to do a C port of Sonic 1. That's about it. In order to do this, I would have to read all the game's code, and translate it by hand to C, then make sure everything's working properly and the same as the original. It's still pretty early in development, so there may be some incredibly obscure inaccuracies I've missed, so if you do find any, be sure to report them. Preferably as an issue on the GitHub repository, which can be found below. There's also no audio yet, and the backend is generally incomplete. GitHub repository: https://github.com/cuckydev/SoniCPort Credits Sonic Team - Original game Sonic Retro - Sonic 1 Disassembly MarkeyJester - SSRG splash screen Clownacy - Additional porting (decompression routines) Screenshots
I'm not sure why this could be. Maybe your gpu or drivers don't support whatever SDL_LockTexture is doing.
Awesome. Found one thing that i don't think happens in sonic 1 - if you jump and land on this ramp with speed going downward, sonic will lose his momentum:
This is actually the same behaviour as the original. Yeah, Sonic 1 has a lot more issues with how slopes are handled depending on if they're facing left or right than even just Sonic 2.
This is pretty awesome, but I am curious about the scope of the project. It sounds like your goal is to make a straight port to C with no extra frills, but the fact that this is widescreen makes me curious how you intend to handle that feature or if you're considering any other enhancements such as bug-fixes. Will there be an option to run in 320x224? Will boss arenas be modified to accommodate? I'm also curious what your position on others forking the code is. Since it's open to the public on Github, I'd imagine you're pretty okay with it (obviously as long as the project and its participants are properly credited), but I just wanted to clarify.
There already is. The attached "SoniCPort_320.zip" file contains a 320x224 executable. On top of that, the source on GitHub is set to 320x224 by default (src/Constants.h). I'm perfectly fine with it. Hell, heyjoeway's already done it, and I imagine I don't have to say what for.
This is awesome. I wish I had something to contribute. I'm curious how you're thinking of porting the sound code over. I imagine it's a choice between emulate the chips, play recordings, or go all S&KC and port the songs to MIDI. Or maybe you've thought of something I haven't.
This is exactly what I've been hoping someone would do for years! Any plans for porting other Sonic games after this is done?
I get the same issue. Pure white screen upon loading. Running a 1080 Ti with the latest GeForce Game Ready Driver (461.72).
So I looked into it, and I think I found the cause: If v-sync is (automatically) enabled, then the port will render one or more times per frame. So, for example, if you were using a 120Hz monitor, it would render twice to maintain 60FPS. The problem was that if v-sync wasn't enabled (which is the case when the monitor's refresh rate isn't a multiple of 60), then the port would draw zero times per frame. Anyhow, I fixed that and a few portability-related issues, so here's an updated build: Normal build Widescreen build Also did you people just forget that I did this same thing with Sonic 2 a few years ago or what
This is great! The first signpost in GHZ1 is missing, but I guess this is a proof-of-concept if there's no way to complete the level and proceed. Also, I feel a little bit of input lag, but I can't tell if it's my monitor or maybe the input polling in SDL is a little weird.
This flew under my radar. Awesome work! I've noticed this when messing around with single frame advance in Kega. Ironic that a game so heavily focused on speed and reaction time has this issue. I'm curious, what would need to change to allow for input to register on the very next frame instead of waiting?
I'm not entirely sure. The issue is one very deep-rooted in the engine itself. It's not that input itself is delayed, it's the frame being rendered that's delayed. Basically, because the VDP is running separately from the game itself, stuff like the new frame's sprites and tile updates are done after VBlank has already occured, since doing it at any other point could cause it to still be updating while the VDP is rendering, causing big big issues.
Maybe it's because I'm not familiar enough with CMake but find_package(SDL2) isn't working for me. Trying to find a solution that works without much luck so far.
