Should I Scrap this?

...how do you need to be more technically minded to understand:

• I want to use two bytes of RAM
• Here're two bytes of unused RAM (ds.b 2    ; unused)
• I'll use that

Instead of:

• I want to use two bytes of RAM
• Hmm. I searched this number and it doesn't seem to be used anywhere
• Oh. But the chunks now change. I guess this number is used

That's the most basic understanding of it I can think of.

BTW, if you want to see the actual address of an S2 Git RAM address, use the 'trace' macro on the ds.b/w/l. The address will be printed in the build window.

 

I have to side with Clownacy on the clarity of the renamed adresses, (Player_mode).w is far more self explanatory then ($FFFFXXXX).w

Tried to fix the link, googles  been doing so unnessecery shifting again (ugh)

 

Going to interject here for a moment again:

Which do you think encourages experimentation more, the top one or the bottom one? :U

Experimentation allows for someone to work with different ways of doing something, whether it be as simple as changing Sonic's speed or as advanced as coding an objects manager or sound driver, until they find a way which best suits their hack/homebrew/fangame's purposes and/or needs. Hell, I've learned a majority of what I know through experimentation, usually turning to my superiors only when I'm truly stumped on something, or in some cases, if I have forgotten what a command does.

And besides, I don't think anyone would fuck with the chunk table, or much of any RAM addresses for that matter, until they know at least the basics of what they're doing.

Also, as for the whole renamed address thing, the Xenowhirl disasm does that as well.

 

For reference, I have no issues with renaming addresses to equates, but the address should still be somewhere in the disassembly, as in the 2007 version.

 

 
ds.b 2 ; unusedGuh, I hate that in the SVN, that's why I prefer Xeno.

Anyway, I'm not particularly happy that this has turned into another "this disassembly is better" topic. Getting a bit tired of the amount of times I've seen it. We've all got our preferences, try them all, stick with which one you prefer.

 

How it is better is what I've been questioning.


As for your other point, there aren't many different ways to trial-and-error a RAM address without prior knowledge.

 

The problem for me with that disassembly isn't the use of equates, it's the way the equates are worded. For me, barring a select few, I don't find the equate names to be very memorable. The amount of times I've had to check how something is written to be able to code something, I've lost count. I have the majority of the S2 RAM layout memorised by value and have done for many years now. Although I've tried memorising the equates, they just don't seem to stick.


My only other complaint is how the disassembly is categorised with the split files. Finding some of the files in the past has been a chore itself. I've had this discussion before, but if a disassembly is to be completely user friendly then it needs to be sorted in such a way an idiot could find their way around it. As an example, if I was going to split all object code from a disassembly and all their assets, I would keep them together. Therefore, I would have an object folder, a folder inside for the object number, and inside that would be the object code, art, maps and anything else directly related to that object. That way if I wanted to add an object or edit one, everything I need is in one place. The same principle could also be used to group main system routines together, and in the long run could help make it easier for Sega CD porting as everything will already be bitesize, so to speak.


I am actually working on a Sonic 2 disassembly that will incorporate these ideas and I'll see how people react to it. The problem is, everybody has their own ideas on how a disassembly should be laid out, and without taking on the ideas of multiple people the disassembly will never live up to its "community" tag.

 

Whereas I prefer, for everything, to be in one ASM file. Sonic 1's SVN disassembly, Sonic (obj01) is split into several ASM files. Which takes me ages to find where certain things are.

 

That's the point I was making. If the object code was intact rather than split into pieces, it'd be easier to navigate. Full as files are good to an extent, but as I found in the past, if you add a lot of code or need to move things around it becomes very confusing and tedious. Would you rather insert a Sonic size object manually with copy and paste, or would you rather include an external as file you can easily relocate. Personally, I know what I'd pick.

 

There'd be certain things I am willing to split (like I did in S2R), just SVN and above went overboard. But when I split them myself, I know exactly where they are already.

 

Pacguy.

I have not been able to try your ROM, as the link appears to have expired. Though if I had to give you any form of advice, then I would suggest; working from scratch, a brand new, a fresh, a blank. Given this, you can slowly build up to what you had before, but this time taking care with what you put in, how you put it in, and avoiding mistakes you made the first time around.

Restarting a project is not uncommon, I've restarted a few of my larger projects from ground up several times, with each iteration becoming better than the last. I do believe Cinossu is also known to do the same with his extended edition. As you can see, it's not uncommon and you may find a benefit from that. Having said that of course, I would like to point out not to get carried away with constant restarts every five minutes. I'd rather you didn't take as long as Cinossu does d=

That's terrible advice.

You're effectively saying that if there's a problem with the project, the problem must be the disassembly only if it's the "Git" version. But you've done this without assessing what the problem actually is... I'm no fan of the Git disassemblies by any means, but that's an unfair act of judgement. It isn't even elaborate either, it's vague, misinterpret-able, and naive.

As for preference of disassembly version and why, I have no comment. You're all getting on my nerves.

 

Thanks for the advice, and the bonus clarification on how disassemblies work. I'll keep these things in mind as I reboot my hack. Seeing as there isn't much point to this thread now (beyond bitching about which disassembly is better) I'm going the go ahead and lock it.