I did forget to mention it's Sonic 2. I am fairly familiar with ASM though, at least, enough to follow these guides and pick out the discrepancies without issue. I did sort of want to avoid the S3K Object Manager, because every object would then need a slot on the respawn table and that seems kind of wasteful on RAM, but I suppose I should go with it.
Personally, I avoid the S3K object manager like the plague. Until we get a proper, exhaustive guide, that thing will break a whole slew of objects: CNZ elevators, HTZ event objects, my SVN log is full of them. Yes, I know the fix is simple, but until there's a proper list of them (and maybe a object layout converter to top it off), it's a massive pain to deal with each one as you find it.
Good enough point for me to side against it. That, and apparently, the existing guide does not cover 2P mode.
LevelConverter can be used to accomplish that, or if that's too cumbersome, writing a simple command-line object layout converter would be extremely simple.
That's not what I meant, sorry. I mean, something that can distinguish which objects need their 'ignore Y-pos' flag setting.
That wouldn't be very difficult when writing a tool specifically for converting object layouts between formats, rather than attempting to convert levels between games. It would just need a list of which types of objects should have that flag set. Which reminds me I should probably add a setting for that to SonLVL's object definitions.
This is why you should do these things yourself, and only use guides as a reference. The results will be way better when you understand the code and do everything required to make what you need compatible. Of course, this requires a ton more prepwork but I am sure you will be more happy with the results in the end.
Also, heck no, SMPS2ASM is not just made for S&K. If you read the usage print, the thread, or the code in the .asm file, you'd see it's meant for S1/S2/S3/S&K/S3D and even flamewing's custom driver.
This seems to be a common occurrence with me, but I'm again having issues with a guide being outdated. I was following the guide to port the S3K rings manager to Sonic 2 and there were quite a few errors involving referenced code being removed or renamed. I managed to find and (I think) fix all but the following, which I have no idea what they are now: Code (Text): > > >s2.asm(29564): error: symbol undefined > > > loc_11FC8 > > > beq.w loc_11FC8 > > >s2.asm(29565): error: symbol undefined > > > loc_1201E > > > bra.w loc_1201E
What I used to do to find out what the relevant labels are is search for them in the old disassembly that the guide was made for. Then try and find the same place in the new version by comparing the two until you find a match. Also I'm pretty sure the GitHub disassembles have all the old labels as comments near the new ones. Just search for those labels.
Oh, I was using Flamewing's driver. I know how the assembly works, it's just I can't seem to figure out why it's conflicting with the lockon data in S3. I didn't know it wouldn't work as-is, that's a total lapse of judgment on my part.
I did search an earlier version but I might not have searched the right one. Also, I did look for the labels in the current version and couldn't find them.
That depends on what guide you look at. Many of them (I used Red Hot Sonic's S3K priority manager guide earlier, for example) do have labels are completely lost, replaced with +'s or -'s. Most of the guides on the wiki are currently out of date, though there are a couple I'm hoping I'll find the time to get around to updating.
I need a simple way to understand data and address registers, so I'm gonna throw out a simplification and maybe someone can let me know if it's enough to get me by or if it misses a really important detail? Ok, here goes. Address registers are for storing information about things (like current position, current status. Current animation, even) and data registers are for processing information about things. Do I have that about right? Or should I go back to the drawing board? I'm having a little trouble because it seems that the limitations of the address registers seems arbitrary, and I fear sure an explanation of why they are the way they are would go over my head, so I want to work out my understanding of them going forwards.
The difference mostly between address registers and data registers, is that data registers allows for way more different instructions, whilst data registers allow for less, but they have the advantage of being able to read from arbitrary location inside the address space. Say, you have an art file at location 0x8AA00. You can stash that number inside an address register, then use (aN) to read from there. Until later models of the CPU, you could not do this at all with data registers. The another difference of address register is, that you can NOT do byte manipulation in them, and any word operations to it will be automatically sign-extended. So something like 0xFF00 (which is actually also -0x100) becomes 0xFFFFFF00. However many times, you can actually use address registers to sort of manipulate just any values like data registers, if you keep these limitations and quirks in mind. Data registers are designed to hold sort of quick variables, like local variables in high level languages. Data registers are more designed to hold pointers. Now we could go into some really technical stuff, but I am sure you will get some idea of how this works based on that, and can experiment yourself based on this.
If you know C/C++, a good analogy is: data register: any of char/short/int or their unsigned variants ("numeric types"). You can do general arithmetic (add, subtract, negate, multiply, divide), logical operations (and, or, xor, btst, bset, bclr, not), copy their value to another numeric type or, with a cast, convert them to a pointer. You cannot dereference or index them. address register: a pointer to a char/short/int or a pointer to their unsigned variants. You can do basic arithmetic (add, subtract), copy their value to another pointer or, with a cast, convert them to a numeric type. You can dereference and index them. For what is worth, the analogy is kind of exact: the 68k had many operations based around C language, being intended to make the job easier for compiler writers. In the end, it didn't help much: compilers have a hard time figuring out the best instruction for any given case. In hardware terms, address registers use special-purpose adders separate from the main ALU. They can be source terms in many operations in the main ALU, but not targets. This allows the 68k to compute an address (say, the program counter of the next instruction) even as it performs an operation (say, adding two registers).
Hello again! I was just wondering if someone could make a new download link for GF64's Classic SEGA Screen? I wanted to use it in my hack but I couldn't download it; the link is broken (I think).
