don't click here

Sonic 2 Bugfix Disasm

Discussion in 'Engineering & Reverse Engineering' started by redquebec, Jul 20, 2016.

  1. redquebec

    redquebec

    Member
    39
    0
    6
    I read many requests here about having some disassembly of SOnic 2 imcluding lots of bugfixs described here in the guides or the forums. I'd be interested into creating it. For this, I'd like to know if anyone see a problem if I create a Github Branch of the latest disasm, and start implementing the bugfixes one-by-one.

    Is there any possibility for me to start such a project in Github, but most importantly do you think it is a good idea?

    Thanks
     
  2. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    I can imagine this is gonna spawn another Megamix-grade circlejerk war.

    Sod it, I might as well get a head start. No, I don't think it's a good idea. A ROM, yes - a disasm, what the heck's the point? 'Save time and effort'? Any hacker worth their salt either doesn't care about the time spent, or has already made their own copy of a disasm with all the bugfixes added. Either way, at least they get a chance to absorb the info the bugfix guides have to offer. And guides are already a massive time-and-effort-saver, so that 'reason' means even less. People already get picky about "copy/paste guides" that give you no information, so why should this be an exception? There's also the problem of, unless you're fairly dedicated to syncing the disasm with the current Git one, it's going suffer the same problem as ReadySonic, and become outdated; future guides won't be compatible, and you'll just add to the mess of unsupported disassemblies.
     
  3. redquebec

    redquebec

    Member
    39
    0
    6
    ... ok then ... :(/>

    The idea is to stay in sync with the disassembly indeed by branching from it and porting changes from master into it. The way of working would have been to add a new property to check (something alone the line of "BugFixing =0"), and to add comment everywhere to explain the bug and what was changed. The idea would be to not only include the bugfixes, but document them in one place. Yes, merging Master into the branch could create conflicts sometimes, but it could be done.

    That was the intent, nothing else. I didn't mean to insult anybody or create any controversy... I just wanted to help some people a bit, in a different way. I do apologize for having fail to recognize that such a project could be a touchy subject for some :(/>
     
  4. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,735
    334
    63
    SonLVL
    The GitHub disassembly also already has several bugfixes built in to it, but they explicitly don't have a single flag to turn all of them on so that people have to search for them and see what it is they're changing.
     
  5. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    As much as I'm all for making bugfixes and stuff, I'm inclined to side with Clownacy on this one. Mainly because it's just going to be an unnecessary process to clone the GIT disassembly, and most of these "bugs" are easily fixed. And again, ReadySonic is a great example of why it's not the most efficient idea.

    I WOULD be for it if the main github disassembly had an option or two to remove things like the air speed cap, but... It takes like, 8 seconds to do it yourself anyway.
     
  6. ICEknight

    ICEknight

    Researcher Researcher
    Your idea sounds like it could be useful to anybody who'd want to start experimenting on ROM modifications from an error-free game, so that they wouldn't have to worry about their code triggering any of the bugs that the Sonic Team failed to fix.

    I'd say it could be a nice optional thing to have, but I don't know the technical stuff on how it could end up being too intrusive, slow things down, etc.


    You know, perhaps some people want to modify Sonic 2 and optimize their time spent on it...
     
  7. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    ...hence why they'd already have a fixed disassembly. If it's someone's first time hacking, and they just want to skip to 'the good bit', or they didn't think ahead to make a fixed disasm before, that's on them.
     
  8. RetroKoH

    RetroKoH

    Member
    1,662
    22
    18
    Project Sonic 8x16
    I agree with Clownacy... after all, it was working through the bugfixes, and ultimately even finding things on my own... that taught me how to hack and made me a better programmer.

    This is kinda to the effect of stripping away the fundamentals and throwing people into the deep end.
     
  9. ICEknight

    ICEknight

    Researcher Researcher
    It's currently on them, but it doesn't have to. That's the whole point.
     
  10. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    In the latter case, yes, but the former shouldn't be doing that in the first place, and this would enable that. If they really wanted to skip ahead, and just start making levels, then I don't think the original Sonic engine's for them. You need to know how to code just to stop the camera from scrolling up and killing you in custom levels, for crying out loud.
     
  11. redquebec

    redquebec

    Member
    39
    0
    6
    I thought it would be a nice idea to do a REV03, not a base to help newcomers... That's the only thing I'd wanted to achieve. And keep it up-to-date with the disasm, which is by no mean a lazy task.
     
  12. Caverns 4

    Caverns 4

    Member
    346
    0
    16
    Sonic: Retold
    Not to mention the basic hex knowledge and stuff that it takes to really jump into ASM. When I first went into assembly, all I'd done prior was scripting in Ruby, and Assembly is a completely different animal.

    When I first started, I had to follow the guides and sink or swim. Not that I'm that good, but I at least understand it on some level. I feel like a disassembly that fixes every bug without giving the user the opportunity to learn would be more of a setback than anything to newbie hackers.

    I mean, I, as do most people probably, already have a prefixed disassembly anyway.
     
  13. redquebec

    redquebec

    Member
    39
    0
    6
    I'd like to thank you Caverns4 for being the first to give a polite and anger-free explanation of this point. :) I can now clearly see your point, and I do agree. But there might have been a misunderstanding: this is not what I'd like to do, or intended to do. It was more as a tool to create a hypothetical REV03, no more. And use Git commits as a way to explain and document each bug and it's reasoning behind the fixing.

    Don't get me wrong: I see that the idea of a REV03 is not the one discussed here and for what I know after exchanging some PM with some of the members of the thread, it is not considered a bad idea. What some don't like is more the use of such a public branches could be done, and I do see the point.

    So, in that case, here is an idea:

    What about a private GitHub repo where I could work on it, and let some key user check out if I do it right? It would not be available to the generla public, just for documentation and have some source tracking in the cloud. Would that be a viable solution to your concerns?
     
  14. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    I never got an answer for my question: what would the point be? Any hacker could implement the fixes themselves, so the only benefit would be a time-saver for those that just don't feel like it. Would it have its own fixes and bug documentation? I think those would be better off not hidden in a specific disasm (coughSaxmanAndReadySoniccough). If it really is just a convenience, then I suppose a private repo could work. IIRC, the homing attack code was given out on a case-by-case basis, too.
     
  15. redquebec

    redquebec

    Member
    39
    0
    6
    It is indeed just as a convenience in this case. Would that seems a good idea to you in that terms?
     
  16. Clownacy

    Clownacy

    Tech Member
    1,053
    581
    93
    I suppose so.
     
  17. MarkeyJester

    MarkeyJester

    Original, No substitute Resident Jester
    2,192
    404
    63
    Japan
    I've only brushed through a few of the posts, so forgive me if I bring up what's already brought up. I just like expressing my opinion on these things, it makes me feel clever :}D

    I have gone to start projects before, to then realised I have to do things before I can actually "begin", for example, Sonic 1 and the lack of Spindash, for a serious project I can't "not" have it in, it's one of those necessities that people complain about. In the end, I got fedup, and made a disassembly with the move already built in for next time. I don't need to prove to any of you bastards that I know how to put a spindash in, or fix a few bugs, that's not the main demonstration here. And so, it's my opinion that a prebuild source would benefit us (I know we're talking bug fixes rather than move additions, but it's related... HEAR ME OUT DAMN IT).

    Of course, I wouldn't want to disrupt anyone's learning experience, that Spindash guide is more value-able than many may think, it teaches you a brief bit about objects, the mappings format, the PLC format, the animation format, various parts of the source code for exploration and exposure that really digs you deep into the engine to understand the endless posibilities, and yes!!! EVEN SOUND EDITING!!! My god, do you realise how brilliant that tutorial is? It is a gem, a pure shining gem. Having a prebuilt source would likely eradicate this wonderful guide leaving many clueless (or likely, too scared or nervous to edit anything incase they break it), this applies to the many bug-fixing guides out there, they don't just help you fix something, they invite you into the source, hang your coat up, plop a log onto the fire, and get you comfortable so you feel as if you can do it.

    So, this leads us to private builds only held by a handful who have proven that they don't really "need" it to show off or anything, they simply and honestly require it to save time. Here's where it gets tricky, for one, deciding who should and should not be entitled to it becomes a huge dispute, many would argue that maybe you shouldn't have to be a "code guy" to access it (if you just wanna edit level art or whatever, for example). In addition to this, we cannot agree on a disassembly structure, so a prebuilt source to help one person may become a headache for another. I for one, have a few prebuilt sources prevately for me only (because I know how I want it).

    On the other hand of it all, we already have prebuilt sources released, and interestingly, they rarely get much attention at all, even with that, the quality of products around haven't changed much (negatively nor positively), so I guess you could argue "what's the problem then?".

    My verdict on this though; just don't bother. Leave everything as it is for now, last years hacking contest is evidence enough that people are both trying, and that hacking the old games is still a hip thing these days. Yeah sure, we have a few crummy ones to fish through, but what lies under is definately worth it for...
     
  18. redquebec

    redquebec

    Member
    39
    0
    6
    I see. It will be private only for source control convenience for my own use then. Never public, and I wont touch at all to anything already present.
     
  19. MrMaestro

    MrMaestro

    Not your average member of a forum
    20
    0
    0
    Singapore
    Solving a Rubik's cube
    I agree, another Psuedo-ReadySonic would ruin the fun of exploring ASM for the newcomers and even though ReadySonic was prime around it's release, it became outdated pretty quickly so if this becomes a thing it will experience the same as ReadySonic did.
     
  20. RetroKoH

    RetroKoH

    Member
    1,662
    22
    18
    Project Sonic 8x16
    I would certainly be more than happy to contribute from time to time if you wanna exchange Skype sn's over PM.