Sonic and Sega Retro Message Board: jman2050 - Viewing Profile - Sonic and Sega Retro Message Board

A little more than four years ago (has it really been that long?) Stealth released the first public version of the SK disassembly to the public, which continued to be used as the standard to this day. Eventually a few people, andlabs and perhaps others I had forgotten, initiated a project to create a complete split disassembly from this original release. Eventually I was brought on to help on the project and, well, basically took it upon myself to lead the endeavor for lack of a better explanation, and after 1.5-2 years of on-again off-again efforts far beyond what I had originally anticipated, the fruits of our labor has finally reached release.

V1.0 of the Sonic and Knuckles Split Disassembly

Detailed credits are given in the included README, which also includes other vital information regarding the usage of this disassembly so PLEASE MAKE SURE AND READ IT BEFORE DOING ANYTHING ELSE. In short, this disassembly would not be possible without the efforts of Stealth, andlabs, Robjoe, Linncaki, MarkeyJester, Cinossu, shobiz, and Malevolence, and possibly others I may have forgotten by this point. Project files for use with the new SonED2 are also included, so editing Sonic 3 and Knuckles levels should be a (relative) breeze, provided you know how to code a little bit.

Please give any issues/comments in this topic and keep in mind that it's very possible we may have made mistakes somewhere. Aside from that, enjoy using this package for research/development purposes.

So after a long time silently perusing this forum for the duration of my stay here, one thing has been made painfully apparent: most of you couldn't code your way out of a paper bag if your life depended on it. This *should* be an obvious conclusion for anyone who is paying attention, but apparently any sort of minor ASM modification (or even hex edit) means that one has the knowledge necessary to do anything more with their hacks than copy off people that know what they're talking about, and are treated as a person with such knowledge by the community. As a result, your hacks suck. No two ways about it.

Of course, if your goal is simply to use the tools available and channel your efforts into another skill, such as art, music, or level design, and you do a good job in this regard, then I don't really have anything to say to you. To everyone else who wants to make the next big Sonic hack with all sorts of ASM work and crap, listen up.

Here's the basic attitude of your average ASM hacker: "I want to make a Sonic hack with all sorts of cool stuff, but I'm unsure about how to do it. Let me look at some of the guides available... *looks up guides* ah, this music hacking guide is good, and this forum post on how to add spindash to Sonic 1 is understandable enough. I'll just follow the directions and copy the code given and put it in my hack. Actually, I kind of want to add Knuckles to the game as well. *looks at guides some more* Wow, I couldn't find a single complete guide on how to add Knuckles. Well, I guess that idea is out the window..." Repeat for each random idea the hacker has thought of. After a while you may have a hack with a bunch of different ASM ideas implemented, maybe some buggy because you didn't follow the directions fully. Alas, you may think you have learned ASM and are on your way to making a good, well-modified ASM hack!

THIS. IS. NOT. PROGRAMMING.

I'm going to be completely frank. There's a good reason why not every random person is a programmer, and why programming in general is generally a highly-paid position in the professional field. This reason is simple. Programming is hard work. Very hard work. Not on a physical level of course, but the skill set and attitude required to be a successful programmer is not something most people have naturally, and isn't developed easily. People go to college for 4 years for this crap in some cases. What does this mean for you? This means that if you had no prior programming experience or skill, going into a Sonic forum and learning how to modify disassemblies using preexisting guides isn't going to do much of anything to give you those skills.

Here are some words that I would use to describe programming: boring, tedious, annoying, frustrating, time-consuming, confidence-draining. You get the idea. Programming is very much a field where the ends justify the means: the resulting program may end up being extremely useful and/or entertaining, but the process of creating it may make you want to kill yourself at times. Obviously, that's hyperbole, but it's not a job for the impatient, the easily distracted, or those who hate boredom.

But here's the thing: I'm all three of the above. But alas, I'm a programmer anyway! What's the secret?

Herein lies the point of the topic: Programming is not a talent that you are born with. Like most any other skill, it is developed by repetition and practice. Why do I bring this out? Because the first step in developing a skill is evaluating yourself and your abilities and understanding what inherent personality traits and how much lack of knowledge inhibits you. People who do not do this or refuse to do this fall into one of two categories. 1) People who understand the mindlessly simple things but upon trying to develop the skill to a greater degree, balk at the necessary requirements and simply declare in their mind that they're too stupid or lazy to possibly understand. 2) People who incorrectly assume that they already know what they need to know and don't bother improving further because they think it isn't necessary. Do you want to make an awesome ASM hack? The first step would be to open a 68000 ASM reference file and memorize the opcodes, while maybe reading a few other reference works to understand what each opcode is supposed to do, right? WRONG. Contrary to what you may think, programming isn't a skill tied to the language or platform. You don't "learn" C++, "learn" 68k ASM, "learn" Visual Basic. You "learn" programming, the concepts needed for it, and apply what you learn to the language necessary. From there, as I like to say, once you've learned one language, you've learned them all. What's left to learn is basically related to a language/platform's limitations and its syntax.

If you *truly* want to do programming work on a Sonic hack or rom hack in general, you should take the time to actually learn the skill. If you don't care, then you're probably ignoring this anyway. (I'll probably know who fits into what category by whoever replies to this topic having only read the title and not much more). Obviously, this may require different methods and more effort depending on the person. I'm not going to teach you how to program, as I honestly would be pretty bad at that anyway. There are many online resources that teach the basics of programming using a specific language, although many of them do a pretty bad job of it. The language doesn't matter much, the point is to learn the concepts. Do your own research. Talk to programmers you may know in real life. Different programmers have different methodologies, so you'd do well to experiment using the language(s) of your choice and find out what you are most proficient at. Only after you do this will the real potential in rom hacking be open to you. Also, as a final note, realize that programming isn't supposed to be *fun*. If you find perverse pleasure in tedious work and endless repetition, then you may enjoy it, but in general it's not an easy skill to learn or perform, even if you're proficient at it. I don't consider myself particularly proficient, but I have enough experience and practice that I generally know what exactly what I want to do, and can do it with reasonable success. I imagine others like Upthorn and Stealth feel the same way, though I can't know for sure.

Anyway, I didn't make this topic to rant, and I doubt it'll do anything to really improve the quality of work on this and other forums as a whole, but if even I can convince a few promising talents to take the time to truly *develop* this skill, I will be completely satisfied.

Squeeeeeeeee!

Quote

pictures here: http://nintendods.gamingmedia.de/gallery,l..._adventure.html

Don't have a source for the press release yet, if someone can find it I'd appreciate it.

This one might take a while, so sit tight.

Looking at the REV01 version of Sonic 1, I can see why it's Rev01. They pretty much completely overhauled the entire BG deformation part of the engine. The drawing system has been changed (and from what I've seen, more similar to the way Sonic 2 does things) and the deformation data for every level has been changed to fit this new code. Also, in every level besides SBZ2, it was used to enhance the deformation effects. To see the difference in your own Sonic 1 rom, you'll have to do the following:

1. Download every text file below. They contain all the ASM you need to perform this conversion. note that if you edited code in any of the code you're about to replace, you're probably not gonna get those edits back without substantial recoding, so be wary.

http://www.cgi101.co...50/lzwobble.txt
http://www.cgi101.co...2050/bgdraw.txt
http://www.cgi101.co...50/bgscroll.txt
http://www.cgi101.co...50/bgdeform.txt
http://www.cgi101.co...blockscroll.txt

2. First, we'll do the easiest change. Go to label Obj0A_WobbleData in hivebrain's 2005 disassembly and replace the entire block with what's in lzwobble.txt. The programmer's extended this array so it would also be usable by the deformation data even though it was designed to be used by the water bubbles.

3. Next, we'll do the BGScroll data. Go to BGScroll_GHZ in the disassembly. Replace everything from there until the end of BGScroll_End with whatever is in bgscroll.txt. The starting deformation data for every stage needed to be changed. To be precise, it prevents bugs that occur in the scrolling in SBZ and SYZ, and prevents a bug that causes GHZ's bg not to appear at all.

4. Next, we'll do the deformation data itself. Go to Deform_GHZ, and replace everything from there until the end of Deform_SBZ, straight down (right before ScrollHoriz) with the contents of bgdeform.txt

5. The new Bg drawing system required a different method of scrolling the BGs themselves. Go to ScrollBlock1 and replace everything from there until the end of ScrollBlock4 with the contents of blockscroll.txt. Don't worry that there are six BGScroll functions now, that's taken cared of.

6. Finally, the biggest part: the BG drawing code. Go to sub_6886 and replace everything from there until the end of LoadTilesFromStart2 (that's a VERY long way, up until MainLoadBlockLoad) with the contents of bgdraw.txt. This should also result in a duplicate label loc_6ED0 in the resize_GHZ3boss routine. Just replace both instances of that label in that area with whatever you like, and you should be good to go.

7. Assuming you haven't changed the backgrounds of your levels, compile it and give it a go!

I'd just like to credit Hivebrain for attempting this first, and Tweaker for his assistance when I had some issues to resolve. Tell me if I forgot anything, and put any questions or comments here.

Go to LZ1 via level select, choose one of the power-up boxes near the beginning, then double jump. It's not complete by any means, but it's a start

http://www.cgi101.co...050/s1built.bin

Code later possibly.