I don't suppose anyone here knows a thing or two about hacking Super Mario Kart? I've tried asking at a couple of other places but they weren't of any help. I've located and decompressed several music files but I don't know what the format of the music is. Thus, I don't know how to replace it. Should've known a fresh start in the morning was all I needed. But now I'm stuck using Modplug Tracker. I hate Modplug tracker.
Me getting the wrong idea of the stick again. I see what you mean, this also happens in my hack. Well, as I am familiar with Sonic 2, once I've figured it out in my hack, I will see if it will work for S3K, then share it with you. Until then, maybe anyone else? EDIT: Fixed it in Sonic 2 Recreation. Looked in S3K, seems to work and not affect anything else. Go to "loc_1565E:" (part of the "Tails landing on the floor" routine). Here, you will see: Code (ASM): move.b #0,$39(a0) move.b #0,$2F(a0) In between these two commands, insert this: Code (ASM): tst.b $2F(a0) ; Is Tails flying or anything? beq.s + ; No? Branch then and do not clear anim move.b #0,$20(a0) ; Clear anim + So, you have something like this: Code (ASM): loc_1565E: ; Tails_TouchFloor+16j bclr #1,$2A(a0) bclr #5,$2A(a0) bclr #4,$2A(a0) move.b #0,$40(a0) move.w #0,(Chain_bonus_counter).w move.b #0,$27(a0) move.b #0,$2D(a0) move.b #0,$30(a0) move.b #0,$39(a0) tst.b $2F(a0) ; Is Tails flying or anything? beq.s + ; No? Branch then and do not clear anim move.b #0,$20(a0) ; Clear anim + move.b #0,$2F(a0) rts Done. It's literally impossible to do that bug now: - This also works for Tails alone:
Glad to be an assistance. As for your slope problems, no idea. This happens in all Sonic games. I remember flamewing mentioning this the other day and said he hasn't got a clue on how to fix it (unless I mis-read it, I have a habit of doing that!). Unfortunately, the only known "fix" is to make the 128x128 solid completely. He may occasionally still get stuck, but at least Sonic will shoot out of the wall instead of in it. Although, if anyone ever does come to a fix, then that would be awesome!
I had asked this question before, never heard an answer. Wanna reask it. Does anyone know how to implement THIS in the fade to/from WHITE routines? I tried it and ended up inverting the colors and messing everything up.
This is something that's always been on my mind ever since tech members have mentioned the rom limit. Example: How come the likes of the Neo Geo can have 330 megabits straight up no bank switching but the Megadrive can only do 80megabits (10MB)? When I look at the tech specs of them both they're not that much different from each other, though does any of that really matter that limits the size of the cartridge rom. CD's for the MegaCD have a greater capacity so why doesn't this have the same limit as a megadrive cartridge?
It is a matter of how the addressable space is set up, and how many bits are connected. "Addressable space" means everything the CPU can see -- ROM, RAM, z80 RAM, memory mapped I/O ports, etc. The 68k can theoretically have 32 bits of addressable space (total of 4 GiB addressable space); on the Genesis, however, only 24 bits connected -- a 16 MiB addressable space -- with the upper 6 MiB being mapped into several things, such as RAM ($FFXXXX), I/O ports, z80 RAM, or simply being "access prohibited".
There is an issue with Sonic 1, that I just noticed. I noticed it after implementing Mercury's Ring Loss Flash change. Let's say you have 10 rings, ok? You lose these 10 rings, they fly. Quickly pick one or two up, and as the other's are flashing, you get hit again, and lose your last rings... BUT, the rings that were about to disappear, are no longer flashing. Instead, they now share the same lifespan as the newly created lost rings. Would someone have a fix for this?
So I got in a stupid, stupid argument. I did bring this up with #SSRG but I feel that I won't have any proof. Basically the guy says that SonMapEd is a forbidden tool because it is "one click and you are done" and that any hack that uses it will be instantly locked on Retro. I think he is confusing it with programs like S1 Hacking Studio. (which despite my 2009 post there, I never got around to downloading/using it and learned/did everything the old fashioned way) How this happened is that I told him Retro and SSRG would most likely not like hacks with advance character sprites in them, and it kinda ballooned from there.
I use SonMapEd for the large majority of my work in about every project I've done here, so I should be screwed royal under that ethic. Does anyone know how to display and edit the title emblem for Sonic 3K (I think the files are called S3 Sonic D in the disassembly)? I think they are too big to work in MapEd and I have no idea how to configure it to load in PlaneED.
If you are talking about just editing the tiles themselves, I was able to load them up and mess with them in Triad just fine... If you are talking about the mappings as well, then I don't think I can help, as I haven't implemented that yet... and quite frankly haven't learned how to yet. If it's just tiles you wanna mess with, I can send you the current version of Triad (an excuse to find someone to privately test my newest build and cheap plug my project) If not, then I'll shut up and go away...
No it's the mappings as well sadly, I want to completely edit Sonic on the title screen. I can load the tiles on MapEd fine, it would just be easier if I could get the mapping loaded as well.
oh... wish I could help. My apologies. Anyway, while I'm here, I wanted to throw this out there. Has anyone managed to hack the iOS version of Sonic CD? If not, then I'd like to say that I'm the very first. I haven;t done much yet, as I just started last night... and the only thing I've managed was to extract the videos, and find many of the offsets for hacking the save file, which is conveniently enough, a simple binary file. So no... no engine hacks, or layout changes... YET sorry. I plan on posting my findings later today if there is any interest.
The question is is SonMapEd okay on Retro and not get the person banned on sight (IE the stupid question everyone sane knows the answer to) What did you expect me to do? This is technically a question about reverse engineering Sonic games, and miniscule and worthless to make a new thread for such a stupid ordeal.
I think whoever told you this was full of shit. If it's not on the forum rules, and not explicitly stated by an admin, or anyone running the hacking Contest, its a farce. When in doubt, just as a Tech Member, or better yet, ask SOTI or Ayla... or any of the others associated with the annual contest.
I think he got SonMapEd mixed up with something else though. :v: Well I guess I shouldn't be a Tech Member nor part of Retro all together then since I use that program. :v:
Hey there, quick question: How can I make it so Sonic doesn't need to be off-screen for the results to appear in the Sonic 1 Hivebrain disassembly? I assume it has something to do with this bit: Code (Text): Obj0D_SonicRun: ; XREF: Obj0D_Index tst.w ($FFFFFE08).w ; is debug mode on? bne.w locret_ECEE ; if yes, branch btst #1,($FFFFD022).w bne.s loc_EC70 move.b #1,($FFFFF7CC).w ; lock controls move.w #$800,($FFFFF602).w ; make Sonic run to the right loc_EC70: tst.b ($FFFFD000).w beq.s loc_EC86 move.w ($FFFFD008).w,d0 move.w ($FFFFF72A).w,d1 addi.w #$128,d1 cmp.w d1,d0 bcs.s locret_ECEE loc_EC86: addq.b #2,$24(a0) But I'm not entirely sure where to start as I'm not sure what tells it to wait until Sonic's off-screen...
The code's pretty much checking when he touches the ground, then it lockes his controls and has him run to the right. Eventually it compares his x position with the x position of the screen plus #$128 (off the screen a little). Pretty much take out this I guess: move.w ($FFFFD008).w,d0 move.w ($FFFFF72A).w,d1 addi.w #$128,d1 cmp.w d1,d0 bcs.s locret_ECEE
