Port K&T into Sonic 1 Hg Disassembly

How to port knuckles and tails into sonic 1?

You can give a hivebrain code but someone'll need to convert it to GitHub/Hg/Svn.

I just wanna add them to my hack "Sonic 1: Stardust's Damn Edition"/ "Untitled Sonic 1 Hack".

 

How about fuck no and do it yourself? It's not that hard to do...well it is now since you're an idiot and using the HG disasm.

 

Why would you even want to use the Hg disassembly for Sonic 1? As far as I'm aware it's still a mess. It needs a complete rebuild without all the mess that turned people away from using it.

 

Do it yourself.

This seems like a very harsh answer, but it's one ultimately meant to help you. Asking for everyone else to do work like this does not look favorably on you, and you will learn nothing in comparison to the invaluable lessons of learning to do it yourself. This place isn't (or at least, shouldn't be) a place where the work and skills needed in hacking are just spoonfed to you, it is supposed to be a place to demonstrate what you know and learn how to go further from there. Put in effort here to do the work yourself now, and you will thank yourself later on.

 

Hg Disassembly is more labeled and easy to read. The assembly is more splitted and categorized.

And give the hivebrain guide. I'll try to convert it to Hg.

 

Really, do it by yourself. It shouldn't be that hard if you know what you're doing.

And trust me, easier not always is better.

 

It is also a piece of shit that gets angry when you don't do exactly what it wants. Trust me, I've been around a block or two. I made my own Tails object in HG, it took me well over 3 hours because of arbitrary shit, or the assembler giving me messages that were irrelevant to what I was working on.

I kindly went into the 2005 version and did the exact same thing, took me 30 minutes. Had a nearly perfect version of Tails flying around Sonic 1. I say near perfect, as I hadn't quite got the two player behavior down, but meh, you get over it.

All in all, the HG might be better labeled, but all that separation is idiotic when I have to open up several different files to find the answer I could've found in two minutes in a disassembly that didn't separate everything. And it's not to say separation isn't important, but if it is awkward, then it isn't worth it. Less labeled over bullshit any day of the week. But, I suppose you are a glutton for punishment. So go ahead, waste more time trying to "convert" shit to a format that is idiotic over actually coding and learning how to do things right.

 

He'd probably need to convert it because his hack is already using the HG Disassembly, and it would be annoying to restart the project.

 

Basically, this.

 

Hooray!  Someone who finally talks sense!  This is why I still use and love Xenowhirls' disassembly.  But the higher ranking/smarter techies tell me off

 

Hg rulez, Hivebrain droolz

 

Hooray!  Someone who finally talks sense!  This is why I still use and love Xenowhirls' disassembly.  But the higher ranking/smarter techies tell me off


You won't find me telling you off. The SVN disasm was total bullshit, so much so that I made my own disassembly based on the Xenowhirl one which I still have for personal use. Trying to memorise exactly how the equates are written is a much bigger pain in the arse than learning the RAM values directly.

 

Hooray!  Someone who finally talks sense!  This is why I still use and love Xenowhirls' disassembly.  But the higher ranking/smarter techies tell me off

But the Sonic 2 disassembly doesn't split everything into multiple files like Sonic 1's.

 

Try to split Sonic 2 into _inc and _incObj folders.

Do it in S3k, and how to build S3&k hacks using Hg/Git Disassembly?

 

Hooray!  Someone who finally talks sense!  This is why I still use and love Xenowhirls' disassembly.  But the higher ranking/smarter techies tell me off

But the Sonic 2 disassembly doesn't split everything into multiple files like Sonic 1's.



Sonic 2 SVN/Hg/Git is the most sane of the batch. I'm still with everyone else in the crowd that the older disasms work much better, though, so you've got another person that won't tell you off for using them. I'm the sort that much prefers not using AS for a list of technical reasons, and much prefer instead using ASM68K and either hand-writing machine code or using SJASM for Z80. Would like to see the S2 disasm converted back to non-AS, but I doubt that will ever happen on the public front.

Anyway, regardless of what you use, Stardust Gear, I think everyone's done quite well at hammering the point of doing it yourself. Hacking's not easy, nor is it meant to be. Figure out how to port what you want on your own rather than asking others to do all the hard work so that you can just drop it in. If you want to improve that reputation that you seem to be complaining about in your signature and status, show some initiative and make things work on your own without begging for work to be done for you. Learn what you're working with and don't shortcut. It'll do wonders for your work.

 

If everyone thought that way, we wouldn't even have disassemblies, or SonED, or even a palette editor.
As for ASM68K, call me when it can properly assemble moveq #$FF,d0, and can assemble 68000 and Z80 code together with references between them.

 

Call me when AS doesn't assemble non-existent instructions and arguments and actually compiles properly. Also, ASM68K is purpose-built for 68k. Focus on one thing and do that as right as you can. AS just buckshots and makes a mess out of things. If I want to compile Z80, I use SJASM, which works perfectly well for everything I've thrown at it, which is quite a lot. Also doesn't accept non-existent inputs. What's wrong with using two separate purpose-built assemblers that do their jobs very well? ASM68K has a few quirks, don't get me wrong, but I'd trust its output a hell of a lot more than I would AS's.

And disassemblies, SonED, palette editors, and other aids simplify some tasks, but that doesn't take away the base needs of understanding the code. It's easier than it was in the older days, but it's very far from "easy".

 

Re: the "it shouldn't be easy" point: I think it all comes down to the good old "give a man a fish and he can eat one day, teach a man how to fish and he can eat for the rest of his life". There's nothing wrong if means to make hacking easier exist, but it becomes wrong if you want a team of slaves to do everything for you. Programs and guides should be written with this in mind. "Do this here and don't ask why" isn't the good approach; "see what happens if you do something near that label" can be a nudge in the right direction, which won't hurt anyone.


But yes, I agree it shouldn't be too easy, which is why the first versions of xm2smps were very user-unfriendly on purpose (I later gave up and resorted to Visual Basic, still refusing to add too many features which could induce lazyness on the final user's part). Remember how many dozens of bad palette hacks of Sonic 2 appeared when SonED1 was introduced. Today's fad are song ports with broken drums, but the point stands. With great power comes great responsability. You want it the easy way? Bear with the noobs posting nonsensical hacks done in 5 minutes.

 

Honestly, I do not understand why this turned into this kind of shitstorm. I mean yeah, asking for others to essentially make work for you is not the way to be. (That's why I think I will not ask any help unless it is completely nessesary).

But to turn it into SonicRetro Github disassembler/SVN disassembler vs Hivebrain disassembler seems to be quite irrelavent to the most part. Yeah the disassembler in Sonic Retro's Github has some weird design choices, but you can figure out where stuff is where stuff is. Like I had some difficulty to find Boundary_Bottom in Github disassembler until I realized it is nothing like the Hivebrain ones and I started to think in terms of C++'s header files.

The thing about "Should hacking be easy" I agree with nineko here. It should be somewhat easy in terms of having tutorials that you learn from but not too easy or why would you hack anyway, why not GameMaker then.

ps. @nineko, Visual Basic, really. Not even Java or heck, even C++ and WinAPI would have been fine but VB is so cluttered and as interpreted language it is so much slower. Even Java is faster in that regard because it has JIT compilation that meshes machine code and Java's byte code.

 

I've never encountered these "non-existent instructions and arguments" you're referring to.

With AS, if there is a bug, there's a chance you could contact the developer and get it fixed, or fix it yourself. With ASM68K that's not possible.