Thanks for clarification! Is there a chance someone could tell actual sizes and offsets of the character collision masks? At least the 3 main ones (Sonic/Knux main mask, Tails main mask, crouch/spindash/roll/jump) and what masks are used for Knuckles glide/slide and characters' horizontal spinning (like in the beginning of Hydrocity 1 horizontal tunnel) I'm trying to recreate original collision system in my fangame and that would be very helpful!
The issue is how large the games are and how much they are hardcoded and placed in code. However I can help you research this and test in action for accuracy. I have some knowledge of this and have ported some code from the original game which also contains some of the mask sizes, and as well can probably track down all the changes. I can also try to make a code to display the bounds of a hitbox ingame, albeit it wont be easy task. Overall I can see if I can help somewhat
I am guessing you're trying to make an object in the middle of the object table check for collisions with other objects. If so then you're running into the exact same problem I had when I added a cutscene character object that needed to do collision the same way as the player. What happens is that each object that is collidable with writes its RAM address to Collision_list when it is processed. The Sonic and Tails objects, at the very start of the object table, read this list. There is another object which lies in the slot directly after Tails (called Reserved_object_3 in the disasm I'm using). This object clears the Collision_list. So: An object in the middle of the object table won't see collidable objects if they are after it, because Reserved_object_3 cleared that entry and the object didn't get around to writing it again yet. My solution was to make a Second_collision_list, and have objects write into this new one while reading from the original one. Reserved_object_3 then does nothing, and after processing all objects, Second_collision_list is copied into Collision_list and then cleared. This means every object gets to see the entire collision list for the previous frame just like how Sonic and Tails do. I also have a flag that turns this behavior on and off, and disable it where necessary, mainly because the $80 bytes I chose for my Second_collision_list overlaps the Target_water_palette. Of course, if you know you are only going to have one such extra colliding object loaded at once it might be easier to create a new reserved object and move Reserved_object_3 up by one, though I'm not sure if that would involve shuffling any other reserved objects around or changing other things. Also, I wouldn't advise using the check you have at the end of your post. It will work if that object doesn't replace its pointer - a lot of objects will do so upon loading or on other occasions instead of (or as well as) using a routine counter. Just had a thought, what you might want to look at, instead of making the new object check for collision with all other objects: try making the other objects check for collision with the new object. Again this will only work if you know you are only going to have one such object and you keep it in the same place in memory, but then you can check just like how objects check for Sonic and Tails. That lets you specify the behavior you want for each particular object, so you don't have to check "is it a monitor", you just add the monitor-specific code to the monitor object.
That was the problem he was having indeed. The suggested fix I gave was to use a non-dynamic object after the dynamic objects (specifically, the one for 2P Tails' shield), as only one laser is ever on-screen. Nevertheless, it is good to have the explanation to the issue in here, instead of lost in IRC...
So I've a question maybe someone can help me with... Why is it WE are able to have a simple batch file to build our ROMs quickly and play our hacks, but the PokeCommunity requires cygwin to run a shell (which I know fuck all about) and jumping through all these hoops to figure out... and yet when I ask them for any direction on how they got it to work... I get nothing from them??? Do you guys know anything about getting their disasm's running? I've got a FireRed disasm that I'm dying to sink my teeth into... and kinda cant....
Sonic hacking has always been Windows-centric, requiring Linux and Mac users to use Wine for many things. I can only assume that the person that made the FireRed disassembly you're trying to use is a Linux or Mac OS X user.
Alright guys I've got a question. I'm trying to make patch a HEX address using MainMemory's SA2 modloader. This is just a sample of my code. Code (Text): const uint8_t bytes[] = { 0x66, 0x90, 0x66, 0x90, 0x66, 0x90 }; PatchInfo patches[] = { patchdecl(0x43D6EB, bytes), }; extern "C" __declspec(dllexport) const ModInfo SA2ModInfo = { ModLoaderVer, nullptr, arrayptrandlength(patches) }; And here is probably the relevant code needed from the SA2 Mod Loader header: Code (Text): #define arrayptrandlength(data) data, LengthOfArray(data) #define arraylengthandptr(data) LengthOfArray(data), data #define arrayptrandsize(data) data, SizeOfArray(data) #define arraysizeandptr(data) SizeOfArray(data), data struct PatchInfo { void *address; void *data; int datasize; }; #define patchdecl(address,data) { (void*)address, arrayptrandsize(data) } Now I'm not very experienced in messing with HEX in C++, but here's the issue I'm running into. Visual Studio gives me this: "#define patchdecl(address,data) { (void*)address, arrayptrandsize(data) } Error: a value of type "const uint8_t *" cannot be used to initialize an entity of type "void *"" Obviously I understand that Visual Studio is saying that I'm trying to use the wrong type for the data field of PatchInfo, but I can't seem to figure this out. Any help would be appreciated.
What exactly is this error I've come across? > > >_anim/Sonic.asm(44): error: too many arguments > > > SonAni_Wait: dc.b $17, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 3, 2, 2, 2, 3, 4, $FE, 2 I didn't modify this animation; it's exactly the same as in a stock animation file. Urgh, AS can be SO obnoxious sometimes.
Well, you should probably split it into two dc.b statements, AS can't handle more than 20 values per statement. + - I should have SonAni obey this limit...
That did the trick, thanks. (Yes, please do that. It would be obnoxious having to come back and edit the file every single time I save.)
I'm getting so freaking tired of this goddamn AS assembler... When I started working on the Sonic 2 disassembly it would always have two passes. That was fine by me. But as time moved on, the number of passes increased and increased. Yesterday I've reached six passes. Six times going over the disassembly, six times as long assembly time. This is utter bullshit. I want to test some quick code but gotta sit through this ordeal over and over again. Waiting once isn't a problem, but these seconds sum up quickly. Sonic 1 (using asm68k) would always assemble in about one second for me. If I even knew what caused these ridiculous amount of passes coming up I'd try to fix my source to reduce the amount, but I don't. Does anybody here do? I've been told to try "-q" in the launch options, but this only sped up the process by like 0.2 seconds.
I told you on IRC, make sure every branch and address has an explicit size attached, making the assembler guess what size they should be can lead to it guessing wrong, which creates more passes.
Crap, I was hoping there'd be a simpler way, which is why I asked here too. Changed all the non-specified ones to some value. But hey, at least that reduced the number of passes to 3. I just don't like using specified sizes, as those are more prone to out-of-range errors. Oh well...
Good night everybody. Im here becasue Im having a little problem in Sonic 1 with animations. You'll see, Im making a whole new animation set, and there are 14 sprites for walking instead of regular 6. My problem is that when the character goes through a slope, the game loads wrong sprites: instead of loading the 14 45º walking sprites, it loads some 45º sprites but then some regular ones, and it doesn't even load 14 in total. The same goes with 90º ones, it loads some 90º and some 45º, and my guess is that when I compile the 135º, it will do the same with 135º and 90º. I am positive that what causes this trouble is the almost twice animation frames, so I checked on SonicSlopeRepel and SonicSlopeResist, also SonicMove, SonicAnglePos, but I can't find something that manages the rotated animations. My guess is that it should load frame #6+6 or something like that for 45º, #$6+C for 90º and #$6+12 for 135º onto $1C or obAnim in GH disassembly, then I could change them onto #$6+D, etcetera etcetera. The animations go well if I make them show when the character is standing, I just can't make them load properly when needed, and honestly, I don't want to delete all the extra frames because they're nice. I will truly apreciate some help around here, please. Thank everyone for reading.
Ah, the good old question about walking frames and slopes, it pops out from time to time, mostly when people want to use the 8 frames from Sonic 3 instead of the 6 from Sonic 1. Two related posts (curiously, both by MarkeyJester): http://sonicresearch.org/forums/index.php?showtopic=1335&view=findpost&p=29015, http://forums.sonicretro.org/index.php?showtopic=10880&view=findpost&p=555590. Please note that you WON'T find a straight answer to your question in those posts, but they'll lead you to understand how to solve your problem by yourself.
