Custom tracks I'm all for that, but the thought of adding characters that came after Sonic R takes away some of the magic for me. If someone was to rebuild the game in a new engine, my only request would be to keep post Adventure characters out of the game. Sure you can add Ray, Mighty, Chaotix, Fang, Bean and Bark, but leave it at that... + - And maybe Motobug (for Jim) .
Well, this topic exploded. From what I can tell the problem with the models is that if they get too large, they run into the space in RAM set aside for the next models, meaning it crashes when it gets garbage data half way though the thing. Say this is your memory right here: Code (Text): [MODEL1SPACE][MODEL2SPACE] Model 1 space has to fit into the space set aside for it. If it was bigger, you'd get something like this: Code (Text): [Areallybigmodel]DEL2SPACE] And then the space for Model 2 gets overwritten when it gets loaded. Code (Text): [Areallybigmo[MODEL2 DATA] When the game tries to read the really big model, it crashes because a chunk of it is missing and the game has no idea what to do. It's easy enough. You just change every reference to Amy's behavior routines to redirect to Sonic's. These are easy enough to find with something like Cheat Engine. Only problem is due to the problem above there may be an issue with animations not loading properly. Well what's the fun in that? But seriously, it's not an awful idea. It'd certainly be easier, but the thing is that if I were to make a fangame based on the assets of Sonic R, I wouldn't be hacking Sonic R. I would be editing a fangame based on Sonic R. I know it's a minor detail, but there's a reason people still hack the Genesis games despite they know it well enough to replicate it and improve it on another platform. They like the excitement of taking something they've known for years and making it better. Sure, they could just make a fangame, but then it wouldn't be the original. Also by the time we'd figure out how to re-implement the complexity of Sonic R we'd probably have overcame half these hurdles just from knowing how the game works and how to work around it, thus making putting in all the effort to rewrite the entire game from scratch entirely pointless. But that's just my 2 cents.
I'm in the same boat. I would go for the Sonic Fighters characters at most, + - and Motobug also isn't a bad idea at all considering its method of transportation . New cars for Amy would also be neato. In any case, considering that this game has a legit PC port, I'm sure that it can be hacked wide open with diligence. I hope custom tracks with their own AI paths will be possible in the future!
I think it would be great to get the current roster balanced out first. Half of them aren't all that fun to play as and pretty much lose by default. How's about fine tuning the handling of Amy's car, or making Eggman/Eggrobo's missiles actually do something? Anyone else think Eggrobo was supposed to have unlimited hover as well?
Models. I know you want them. And now you can have them. DOWNLOAD I'd link you to The Models Resource, but as of right now only Sonic, Tails and Knuckles are on there and the rest are in the mod queue behind probably every Pokémon ever. I'll link you to my personal page where I've hosted them for the time being instead. Wait a couple days/weeks and they'll probably be on TMR if you don't trust my site for some reason. (And yes, I know Metal Knuckle's head in that picture above isn't connected to the rest of his body. I'm just too lazy to rerender it. :P) EDIT: They're on The Models Resource now. Disregard the above. Also, a fun fact for you: The gun on Eggman-Robo (or whatever is name is) has a mistextured bit near the trigger area, having the texture of Tails' eye instead. This error is not present in the Saturn version, but is is there in the PC and GCN versions. + - Also I claim no responsibility for the inevitable resurgence of Tails Doll creepypasta. EDIT: Fixed the links.
Yowsa, Metal Sonic sure looks derpy from straight-on. Great job at pulling these models! I've always had a soft-spot for Sonic's saturn-era model. It's a shame it couldn't be used for an honest to goodness 3D Sonic game on the Saturn. Maybe with these models, someone can do something in that vein.
Been a year since the last post? Dang. I should probably prove that I haven't been dead. Because trust me, I've been busy. I would've submitted something to the Hacking Contest, but as it turns out Sonic R does not really liked to be hacked. Literally everything is hard-coded. I've been working on a solution to that, but I'll show that off in another post later. For now, though, I'm going to show you a stupidly simple fix to a huge problem in the game. Specifically, the problem is that slopes do nothing to you unless you're on a very steep slope. This means that, for instance, the big curvy bit in Radiant Emerald has proper slope physics, but not the canyon in Resort Island. Sonic or whoever just plows straight though banked turns and the such without any care. (As Jontron puts it, "They programmed magnets into the walls!") This, obviously, is wrong. The fix for this is simple. When the game is calculating velocity changes, there's a section that deals with slope physics. This section is skipped if the slope the player is on is less than 0FFFFF138h. (This is, rough estimate, a 15 degree angle.) We can't get rid of this skip because otherwise Sonic loses his ability to spindash due to not having flat ground and, on top of that, he slowly slides off the starting line and down the hill at the start of Radical City. (It's actually kinda amusing to watch.) What we need to do is make it so that if the player isn't pressing forwards, slope physics don't apply. This solves the "magnets in the wall" problem while also avoiding the "sliding down the start line" issue. I'm also going to make it so slope physics never apply when the player is holding down, which fixes some wonky rolling/spindash issues. (Spindashing still might be broken, though. Can't remember off hand.) Now to the meat. To fix this, go to 0x00485E34 in the EXE. Change Code (Text): cmp word ptr [ebx+72h], 0 ; Jumping? jz CharDiff_RollStart ; Skip if mov eax, [ebx+0B4h] ; Skip if not on big hill sar eax, 10h cmp eax, 0FFFFF138h jle CharDiff_RollStart mov eax, [ebx+40h] ; In water? sar eax, 10h test eax, eax jnz short CharDiff_RollStart test byte ptr [ebp+Input+1], 10001b ; Accelerating with fwd or button? jz short loc_485E8C mov eax, [ebx+84h] sar eax, 10h test eax, eax jg short loc_485E8C ; Unknown mov dh, byte ptr [ebp+Input] test dh, 8 ; Pressing left jz short loc_485E69 test dh, 80h ; Pressing right jnz short loc_485E8C (bytes '66837B7200 0F84 87000000 8B83B4000000 C1F810 3D38F1FFFF 0F8E 73000000 8B4340C1F81085C07569 F645ED11 743D 8B83 84000000 C1F810 85C0 7F30 8A75EC F6C608 7405 F6C680 7523' @ offset 76220 in the EXE) to Code (Text): cmp word ptr [ebx+72h], 0 ; Jumping? jz CharDiff_SlopeEnd ; Skip if mov eax, [ebx+0B4h] ; Skip if not on big hill sar eax, 10h cmp eax, 0FFFFF138h jle CharDiff_Slope_SkipButtonCheck test byte ptr [ebp+Input+1], 20h ; Presing down? je CharDiff_SlopeEnd test byte ptr [ebp+Input+1], 11h ; Pressing up/fwd? jne CharDiff_SlopeEnd CharDiff_Slope_SkipButtonCheck: test byte ptr [ebp+Input+1], 11h ; Accelerating with fwd or button? jz short loc_485E8C mov eax, [ebx+84h] sar eax, 10h test eax, eax jg short loc_485E8C ; Unknown mov dh, byte ptr [ebp+Input] test dh, 8 ; Pressing left jz short loc_485E69 test dh, 80h ; Pressing right jnz short loc_485E8C (bytes '66837B7200 0F84 0700000 8B83B4000000 C1F810 3D38F1FFFF 7D0E F645ED20 7471 F645ED11 756B 9090 F645ED11 743D 8B83 84000000 C1F810 85C0 7F30 8A75EC F6C608 7405 F6C680 7523' @ offset 76220 in the EXE) You might notice we lose the 'in water' check here, but considering it's physically impossible to have an underwater slope, it's kinda redundant. The only issue with this is that you can't really coast like this. Once you let go of the forwards button physics stops doing it's thing. An alternate solution is to never skip slope physics if the player's speed is above some value. I didn't implement that because I literally just thought of it 5 seconds ago, but it should be easy enough to do: just place a jump right before the slope angle check that skips past it if the player's forward speed ([ebx+44], I think) is greater than some value. By the way, this certainly is no magic bullet to fixing the game (you still run into the walls there in Resort Island), but it adds that little something that was missing.
That actually sounds really dang fascinating. TBH I'd love to play a build of Sonic R with this fix when it gets to a point where you can do it.
Yeah, I'd love to see more hacking of Sonic R. It's a pretty naff game but it's kind of charming nonetheless.
Guess what I've got~! Turns out, I had the spec figured out this entire time. I just forgot to read it when I was hacking together my converter. //forums.sonicretro.org/public/style_emoticons/default/specialed.png Of course, don't think this means custom levels now. We still have to figure out collision and AI and the metadata in the geometry file and all that fun stuff. I'll probably dump the tracks on the Models Resource soon, but if you want the converter today, it's here on my hideously neglected Github. Usage is simple enough, just run it through Python 3 with any .BIN track file and it should spit out an OBJ with the model. You'll have to define the textures manually (the texture list for each level in the EXE, not the file). but besides that it should be 100% functional.
Now that those can be exported to OBJ, how long do you think it will take for somebody to import them into Generations for a sort of Sonic R HD version?
Forget Generations, I want these in SADX! I don't suppose it would be possible to translate the collision data into a 3D model, would it?
These would make wicked SADX stages, for sure. They even look like good thematic matches for Emerald Coast, Twinkle Park, Lost World, Sky Deck and Twinkle Circuit.
I think the hardest part of porting Sonic R stages will be the floor, because it's just a flat bitmap image. Someone would have to trace out the water areas, convert the floor shapes into triangles, and then most likely you'd add a floor and walls underneath the water areas, to simulate the underwater walking behavior.
By the way, looking at these models, there's apparently a reason Sonic R had such an awful draw distance. Here's Bob-omb Battlefield from Super Mario 64. It has 972 triangles.Reasonable number for the complexity of the level. Here's Resort Island from Sonic R. It has 22,445 triangles. That's over 20 times the amount Super Mario 64 has, and that's on the same console generation. (I'll stop spamming the thread with giant images now. :v:src="//forums.sonicretro.org/public/style_emoticons/default/v.png[/IMG]) The reason? Compared to Super Mario 64, Sonic R can't repeat textures within a polygon. This means that the poly count has to be huge to have a good texture resolution. But if you notice, say, the pathways, the amount of polygons starts to get a bit overkill. Also, to answer MainMemory's question about the collision, I don't know, but probably. I haven't really looked at the format too much yet. (Been too busy messing with character attributes and actions and stuff instead.) From my haphazard attempts, it does seem to resemble a 3D model, as each bit of collision is one after another much like the model parts instead of in an array or something silly like that. It's a bit harder to reverse engineer the collision data because the only way to test it is to walk around in circles and figure out what's different, which gets real annoying real fast.
That's a very interesting. I wonder why they couldn't repeat textures per polygon? That seems insane! Nice work getting out those maps, by the way. I'd love to see more technical posts like this, they're very interesting reads. That reminds me, I made a mod of the SanicBall engine a while back that used real animated models instead of balls. I betcha those Sonic R maps would fit right in. Gonna have to give that a shot later.
I have no idea how you guys even got the game running let alone modding. Cool stuff though, can't wait for Balanced Sonic R.
