yall gotta stop doing what I'm doing / I might as well stop cuz you guys finish first almost all the time lmao I like how you even did the metal sonic icon. So you also managed to get all of Metal Sonic's sprites to conform to Sonic's palette, yes? Or are you doing that by hand :x BTW managed to get him in a ball lined up nice, since Metal has the top-right reflection in all his curled up poses. EDIT: Also, I noticed you had an extra pixel of real estate with the sprite sheet. How'd you do that? Is there a way to edit the bin files to change the bounds of the player sprites?
I only swapped in Sonic's 6 shades of blue for Metal, Soo far I've only changed the sprites (they're 1 pixel off to the left. gonna wait for a mappings editor in the meantime)
ftfy. Also *MY DUDE.* The game as it was MEANT to be played. Now if only insta-shield could be activated w/o sacrificing drop dash lmao. @LoneDevil yeah I had to replace all of Metal's colors with those that were in Sonic's palette, but I managed to do it to his entire sprite sheet. I had to offset as well, but cut off his toe instead of his spine lol. Yeah we'll need to wait to see how to re-map the sprites, which I know for a fact has something to do with the .bin files. Maybe i can fuck around with the hex editor and see if there's built in coordinates or something. Also, COOL THING ABOUT RETRO ENGINE: If you use Devmode to exit out of a stage and immediately load back into it, any changed you made to sprites will be applied on reload. This doesn't work for simply restarting a stage since the sprites are already in memory, but if you save your .GIF files and exit / enter a stage, you'll see your changes applied. Neat! Very convenient we have a working filesystem. EDIT: figuring out tile mapping.
Yes, since the value for super peel out isn't the same as dropdash or instashield there probably a way to enable all 3, just havent found it yet. you would think they would be close together but i guess not.
I'm not talking about altering the EXE file, I'm talking about altering the program's code in memory. The problem with that is it requires all the files to be extracted, and you have to manually manage the files if you want to change which mods you have on. A mod loader would allow mods to only include the files that have been modifed, and you would be able to choose any combination of mods from a list before you start the game. In addition, there's potential for cheat codes (if a function that runs every frame can be located and hooked), and loading custom ASM/C/C++ code from DLL files (if such a thing would even be useful, considering most things are probably scripted rather than hardcoded).
Hey MainMemory, Big fan, just wanted to say that your work with your cheat table for the Sonic & Knuckles Collection is the whole reason im hitting mania hard to find every useful value.
Well, steam_api.dll didn't want to play nice, but d3d9.dll is surprisingly cooperative. Unfortunately, it's 1AM. With any luck I can throw something together tomorrow. Or later today. Whatever.
Gotcha MM, sorry didn't know what you were going for, but what you say makes sense of course. Hopefully you find a way to get your methods working. Also, progress on sprite mapping. Pardon my crude writing. In the Sonic.bin file, there's definitions for the animations and how those sprites are mapped onto the frame. Exactly how the sprites are moved coordinate-wise I don't know (I suspect it's the first four bytes, in fact those are probably exactly it), howeeeever I've found out how the file takes from the .GIFs in the first place. This is the definition for his "bored" animation. The definition starts with a string defining which animation this is. It's likely the string itself doesn't matter, as when I replaced Sonic's .bin with Metal Sonic's in the .exe, Metal's standing pose was the "idle" pose, and his "bored" pose was what his .bin file calls "taunt." This is significant because Idle and Bored are the 1st and 2nd defined animations in a player's .bin file, respectively. As for Metal Sonic, Idle and Taunt were animations 1 and 2 in that order. This leads me to believe animations are read by index, and the string is more a leftover / assistance for the RetroSDK to make it legible. Following the string is a series of bytes, the length of which I can't determine (for Sonic it was 10 bytes after the string, for Metal it was 7). The best way to know the beginning of the data block we're interested in, at least for now, is that the first byte of the series is 12 bytes before "F[?] FF" (i.e. F0 FF or F2 FF etc). Ignoring the first 4 bytes, though, since we don't YET know what they do, the actual mapping starts 8 bytes before. After the 4 unknown bytes, the sprite's X and Y locations on the sprite sheet are outlined. Order is little endian. The first row shows 01 00 01 00, meaning the first sprite begins at pixel 1,1. This is his Idle sprite, so it's located at the beginning of the file. Next, the sprite dimensions are outlined. Sonic's idle pose is 28x40 px, so in hex it's written as 1C 00 28 00 (ironically). Since Sonic crouches as he taps his foot, the successive frames' Y size is consistently 27 00, with the X size changing slightly a pixel or two. Then a whole lot of nonsense I don't want to touch right now defines, likely, everything else about the sprite frame. Everything about the rest of the hexcode seems to be the same for the animation, save for the beginning byte, F0, which changes to F1 frame 3 and F2 frame 6 onward--these frame, by the way, are the ones that loop a few times as Sonic taps his foot. It's likely this is a "state signifier" of sorts, telling the game what part of the animation he's in. Why his first 2 frames are F0 but the next 3 are F1 is beyond me right now *shrug* EDIT Also I just noticed that after "F0 FF," the 3rd byte, "EC" changes to "ED" afterwards. Strange. At the end of the datablock is a 08 which I believe to be an end-signifier, or telling the game to loop the animation (probably not). Either way, this defines the end, so I feel it's likely that, if the .bin file can be expanded, you can add more frames of animation. That's definitely neat. This is all I got right now. Will see if I can put some of Lone Devil's old Metal Sonic sprites in Sonic's sprite sheet, propperly mapped out so nothing gets cut off. EDIT: forgot to mention which part of the animation this was, doi. Fixed. Also some things were still left unclear. Again fixed.
The numbers after the size definitions are, as far as I can tell, 4 bytes specifying a negative X/Y offset to define the center of the sprite. The top-left corner of the sprite is offset by the given amount from the actual 0,0 position of the sprite. This is somewhat similar to how the sprite mappings are defined relative to the origin point in the Genesis games. After that you have what I presume are two sets of x1,y1/x2,y2 relative coordinate pairs defining the sprite frames collision hit box with the 0,0 position as the origin. This is actually different from the Genesis Sonic games which, if I recall, only specified a width and height radius value that extended in both directions on their respective axes. What I'm unsure of is why there are two sets of these collision box definitions and why on Sonic's sprite the second one is a pixel shorter on both sides. Maybe it's just a different hitbox when colliding with level geometry and when colliding with other objects, but that's purely speculation.
man, they just loved adding zeros to pad files out didnt they? the save file could probaby be half the size and still have room left over. btw, i still have no idea where the dropdash toggle is in memory after spending like more hours on it. not sure if you looked at those sprites or not but if theres anything usefull or mught point me to what to look for, it would really help.
Your speculation turned out correct. First two offsets are the negative and positive X,Y of object collision, the next pair for stage collision.
Looking at that "string" for a moment, 20 31 00 0B 00 02 00 06 04 00. " 1",0 (with a null terminating 0), followed by 0B 00 (which I assume is the number of elements/sprites in this list). The rest could be related to speed and/or looping, but I can't be certain, any chance of a GIF image of this animation in motion? Kinda running blind...
making gifs on my computer is suprisingly annoying so check here https://youtu.be/53mjlRDTFf4?t=25s EDIT: Marc just told me this guy StoneBanana cracked the sprite anim format pretty much entirely, which, wow, good job. Quoting here for convenience:
Double posting because this is another matter entirely. So I decided to just up and remove the "objects" folder to see what would happen :specialed:/> I figured those files had to do something... And they do! While I haven't pinpointed yet what specific files affect what, it seems the "Objects" folder controls the menu graphics, Blue Sphere, player physics (!!!!!!!), and for some reason puyo speed. Unsure what else it controls but I'll look into it later. Removing the files sets everything to null, it seems, or some form of it. Menu graphics straight up disappear if they aren't sprites, Sonic/Tails/Knuckles can face a direction but they can no longer actually move--in fact, their only mode of movement is the spindash, as the power of the spindash seems to be controlled elsewhere--and trying to load Blue Sphere just crashes the game. Obviously what we're more interested in is the player physics. Don't get your hopes up though, because it's not like whatever's in this folder actually controls player behavior as in character powers and the like. Rather, it seems to control the property differences between Sonic, Tails, and Knuckles, setting things such as their jump height, acceleration, max speed, etc. If you put the characters in any cutscene setting (that doesn't have them jump), they'll behave as you'd expect. However, once they're out of the script, they're no longer able to move forward as their acceleration's set to 0. This half explains why it affects puyo puyo, assuming it's 0 "resistance" or something idk. Unless there's other things within the Data folder I'm missing, this leads me to believe a lot of the core behavior in the game is hard coded. Back to the ASM days either way I guess though does look like some things can be edited without a need for cracking into the EXE. I'll pinpoint what specific files do this soon. There's just a lot of 1KB .bin files and I honestly don't feel like shifting through them right now lol
I just want to note that it isn't entirely cracked, as there's still a few things that need to be figured out (like the purpose of some stuff in the header), as well as a different, smaller format used for objects like badniks, rings, and stuff. There are also a few minor mistakes that I made which need to be corrected. Tpot has been helping to figure out a few things with the format, and I intend on documenting the shorter format when I can. An updated document should come later today and will hopefully be more helpful. For now, the notes that were posted apply almost exclusively to characters. That's all.
Another thing I've not seen mentioned - the naming of the sound effects for the different bouncy chemicals in Chemical Plant seem to imply they were different colours at one point, with the cyan chemical's sound named ChemYellow and the green chemical's sound named ChemRed. Presumably they were changed either becuase the old colours are traditionally associated with danger, or because they blended in with the large areas of red in Act 2's background. Also, the sound effects for Press Garden's shuriken launchers are named ArrowLaunch and ArrowHit - along with the ARZ arrow launcher graphics found in the Act 2's Objects-Temp sprite file, this seems to suggest they were just regular arrow launchers for a period of development. Finally, Flying Battery's Objects-Classic sprite sheet is a little different to some of the others - unlike other stages that have these, the classic version seems to have been partially combined with Wing Fortress and Wacky Workbench's graphics already. Some minor colour changes have been made to the elements originating from other stages, but other than that it's the unchanged Mega Drive art. Things of note: the Clucker's turret was originally changed to grey rather than the orange seen in the final stage - personally prefer the final colour choice as it makes it look more similar to how it looked in Wing Fortress. The Wacky Workbench electrical spheres were blue rather than orange - presumably this was changed to give them better visibility against the stormy background. Finally, it seems the circular turrets from Wing Fortress were considered for the stage early on as they're present here, recoloured to grey to match Flying Battery's palette.
Really amazing progress folks. Metal Sonic was cool to see being implemented, as well as modding sound effects. I guess that means music could also be modified? One potentially good idea might be to remove Super music altogether, as the stage themes are generally what are worth listening to instead of the Super loop. Not that it's a bad song at all, but once you unlock Super mode you do get to hear it very often instead of the stage theme.