I have a quick question. If I wanted to 3D model a scene to give it a 3D feel but a 2D perspective (I suppose 2.5D). What angle should I have the camera at to retain the 3D feel of the models but to give it a 2D style? If I try placing the camera at a 90 degree angle to the model it all looks flat which somewhat eliminates the point.
What's the best way to hack a DS game? Specifically, I want to hack Sonic Chronicles, but Bioware uses some wackyass proprietary file system so pretty much every other guide on the internet about hacking .nds files is useless to me. Specifically, if anyone can help me out, I want to do two things 1.) Dump all the character dialogue portraits (example) so I can save a little time instead of painstakingly editing screenshots whenever I want to get one of these pictures. 2.) Fix the game so POW moves never miss. I want the game to run through all the prompts for POW moves and behave as if I'm hitting all of them. I don't really think that last part is possible, but this place is apparently the preeminent Sonic hacking site on the web, so I figure if anybody could help, they'd be here. If anybody can help me out with any of that, even by pointing me in the right direction towards some other site, I'd be very appreciative.
Question about Sonic Generations. In bb3 what exactly does #SonicSp.ar.00 control? My two guesses are either Super Sonic or Sonic while in the White Space (I've noticed his physics don't seem to be the same there as in normal 2D sections). Is one of these guesses right or is it something else?
I am working with the Sonic 1 and I am trying to fix things in the game but I can't get my rom to build. I have tried shortening the names of the folders, replacing files and editing the build.bat file but everything I do only leads to a 1KB file that is unusable. When I set the file to pause, this occured. C:\USERS\DONNA\DESKTOP\HACK\SONED2-1\S1H\SONIC1.ASM(972) : Error : Symbol v_jpadhold1' not defined Assembly complete. 1 error(s) from 47446 lines in 2.97 seconds Lightening's Rom Padder Reported Size: 0 Reported Checksum: 0 Size applied: 7F Checksum Applied: 0 Press any key to continue . . . I am using Hivebrain's Sonic 1 Disassembly ASM68K version.
I believe your problem is that you used a guide targeting the Hg disassembly, which has RAM constants that do not exist in the 2005 disassembly. You can either undo what you've changed and use 2005 disassembly compatible guides, or start over with the Hg disassembly and use guides compatible with that.
Thank you very much! I just ended up redoing the entire project over while saving before I do something wrong and I used a few other threads for help!
Sonic Chronicles uses Bioware's herf-archives format to store data. I don't know as for your second question, but unpacking the archives should help with ripping graphics at least. Check out this and the below posts for the format description and archive unpacker: http://forums.sonicretro.org/index.php?showtopic=21291&view=findpost&p=478214
Is there a way to fix the vertical looping glitch in the Mega Drive games? You know, where you look down and jump, and the camera gets funky, allowing one to roam through stuff? I havent seen a fix for that anywhere before. Mainly noticeable in Sonic 3, I never tried in Sonic's 1 and 2 though.
Before I come up with a fix, I want to check we're talking about the same thing. You mean this bug, right?
That be the one. Fixing that would fix a lot of glitches, primarily in Sonic 3K... Over half of the glitches I've seen involve using that one. Start at the 90 degree angle that makes everything appear flat, and tilt it so it is slightly facing downwards, slightly showing the top of the ground. You can even angle it left or right if you want. The real thing that would make the 2D perspective at the end of the day, is how it controls. The character needs to move as if on a 2D plane. You can really do whatever looks appealing to you with the camera as long as you retain the 2D style control.
I've been working on a co-op mode in Sonic 1 like the one in Sonic 2. I almost got everything done: I made it read the second joypad, I made the partner follow Sonic, it has its specific art, etc. However, there's a little problem I'm having now that of course is making me feel frustrated. By the way, that thing is making the partner detect the solid objects and making this partner stand/collide on them, but seems it does not work. I've been trying some methods, and some more, like: - Porting the solids code from Sonic 2 - Adapting the code from Sonic 2 to Sonic 1 Since I'm not very used with solid objects, I'd need a small help from someone who knows this. By adapting the code from Sonic 2 to Sonic 1 I mean that I tried to replace the following line in every label that SolidObject, PlatformObject, SlopeObject, etc had it: lea ($FFFFD000).w,a1 to lea ($FFFFD000).w,a1 bsr.s @Label lea ($FFFFD040).w,a1 @Label Nearly exactly how Sonic 2's works. But still nothing. Some information or help would be appreciated. Thanks!
Okay, this is how I did it. I'll show you the S3K way here, but I will put the Sonic 2 fixes and explanation in the "Sonic 2 bug fix" topic. Sonic 3K fix - SVN disassembly Go to "MoveCameraY:" and change this: Code (ASM): MoveCameraY: moveq #0,d1 move.w $14(a0),d0 sub.w (a1),d0 cmpi.w #-$100,(Camera_min_Y_pos).w bne.s loc_1C132 and.w (Screen_Y_wrap_value).w,d0 to this: Code (ASM): MoveCameraY: moveq #0,d1 move.w $14(a0),d0 sub.w (a1),d0 tst.w (Camera_Min_Y_pos).w ; Does this level y-wrap? bpl.s loc_1C132 ; If not, branch and skip looping cmpi.w #$60,(Distance_from_screen_top).w ; Is screen in its default position? beq.s + ; If so, branch, and loop ; It's not at its default position; Sonic must be looking up or down tst.b ($FFFFB039).w ; Is Sonic still looking up or down? bne.s + ; If so, branch, and keep looping, Sonic ain't moving anywhere! ; So, Sonic was looking up or down, but now he isn't move.w #$60,(Distance_from_screen_top).w ; move the screen to its default position quickly + and.w (Screen_Y_wrap_value).w,d0 ; Forever loop Done.
For S2 at least, there is a better way to fix that bug: in ScrollVerti, find this: Code (Text): ScrollVerti: moveq #0,d1 move.w y_pos(a0),d0 sub.w (a1),d0 ; subtract camera Y pos cmpi.w #-$100,(Camera_Min_Y_pos).w ; does the level wrap vertically? bne.s + ; if not, branch andi.w #$7FF,d0 + and change it to this: Code (Text): ScrollVerti: moveq #0,d1 move.w y_pos(a0),d0 sub.w (a1),d0 ; subtract camera Y pos cmpi.w #-$100,(Camera_Min_Y_pos).w ; does the level wrap vertically? bne.s + ; if not, branch andi.w #$7FF,d0 move.w #$FC00,d1 add.w d1,d0 eor.w d1,d0 + What this does is to convert the distance from the top of the screen from non-wrapping to wrapping; how it does that, I will let you guys figure out :v: (and yes, I know why; if someone figures out, I will confirm it) For stock S3&K, there are 3 cases to consider: Screen_Y_wrap_value = -1: the level doesn't loop vertically, so nothing to do; $0000 should replace $FC00; Screen_Y_wrap_value = $7FF: unchanged; Screen_Y_wrap_value = $FFF: you have to use $F800 instead of $FC00. To handle this, using a spare RAM value to store the constant to use whenever Screen_Y_wrap_value is changed would be best.
It might be from an optimisation perspective, but using up any of that precious, precious little free RAM gives me the shivers! Nevertheless, many thanks to you and RHS for finding neat solutions to this. Once I get S3C moving again I'll definitely look at this. Which I will. Totally. Sometime. I'm guessing MoveCameraY is pretty much the equivalent of ScrollVerti, but I see similar code looking at the screen wrap in a whole bunch of places. I'm guessing the same principle as flamewing's solution can probably be adapted to attracted rings going on their own adventure? While I'm here, I may as well mention some pet peeves in case any of you geniuses have found, or care to look for, a solution. These are things I've either never looked into, or took one look at the code and decided that there are better things in life. Landing on objects and jumping off them is rubbish, in S3K at least. Knuckles often can't jump off objects underwater, Tails tends to hang around in his flying animation when he should have already landed, and he tends to be pushed through the floor by falling monitors instead of being crushed while flying. I have "fixed" the first and third of those with hacky special cases I'd rather not share due to how poor they are, but I can't help but feel there's some core issue with all that code that might solve these elegantly and other issues besides. This old falling through the floor/getting stuck in walls/stopping when hitting a slope in a hurry thing. It feels like S3K suffers from this worse, though that may just be because you're more likely to retain speed than in the previous games. I could stick a load more GTGT bricks into the level layouts, which seemed to be the original designers' fix of choice, but I can't imagine that would fix those frustrating cases where a ramp just stops you dead, and I have about a billion object layouts per level and as such, I hate changing them. Is there a more elegant way to deal with that nonsense without slowing the whole game down to a crawl with extra collision checks? But let's say you do get stuck in a wall: it'd be nice if that didn't then turn into a skip-most-of-the-level exploit via zipping. There has to be some way out, even if that's death, but one that doesn't give you an actual advantage would be rather peachy. With that fixed, along with the scroll bug, you might even see some of the levels in a speedrun again...
That means you haven't done the second one, right? About tails flying, I know a little bit about. Do you mean this? You mean like on DEZ when you're on that moving platform and Tails just continuously flies behind you? Just moving left or right a little bit helps. It's because he can't get close to you quick enough as you keep moving. Although, at "loc_13C50:", you'll see: Code (ASM): addq.b #4,d2 Changing it to: Code (ASM): addq.b #8,d2 helps increases Tails's x_pos checking drop distance. He will now land on the object like suppose to. EDIT: Doing some testing other places like this: his flying seems unaffected. He still won't drop from there, so no worries there. But when he does get closer to you, instead of flying indefinitely, he will now drop. So I hope this has helped?
It's not so much AI flying I'm thinking of here as actual player flying. Get Tails in AIZ, take off, and try to land on one of the rock objects. Half the time he'll slide around in his flying animation for a second before landing properly - he's "landed" enough for the heli sound to stop but not to animate right.
One thing to also look into is anytime Sonic is carried by Tails and lands on something, or grabs something. I posted a YouTube user on the S3C page who posted a shitload of these style bugs. There's a plethora of these... and you can control Sonic after the end of Act if Tails carries you to the ground without you jumping... I would guess that many of the issues in the game have a great deal to do with them adding the double jumps for Tails and Knuckles... which might have something to do with the fact that player flying does not exist in Sonic 2. Also if we will explore issues with Sonic 3K, One thing that I've always hated is that Knuckles' gliding and sliding speeds don't change whilst underwater. There are a LOT of things overlooked in Sonic 3.
Would it be possible for me to edit the demos in Sonic 1? I had just removed the speed caps in the game and I want to fix them. I am using Hivebrain's 2005 Disassembly.
This is by no means a full breakdown of how to do it (I'll leave that for someone with more experience tweaking demos to answer), but this info might help at some point.
