You'll have to make a new routine for the badnik. Using Eggman's code isn't going to work. Does Coltype stand for collision type? That shouldn't be changed. Try this for testing purposes. Use an unused RAM address for the badnik hits (a byte long will do). And another unsed ram address for the badnik timer (byte long again). Call these (badnikhit).w and (badniktimer).w When the badnik is created, set the (badnikhit).w to 4. And (badniktimer).w to 0. When you go to hit a badnik, it will jump to a routine somewhere to kill the badnik. At that routine, try adding this first: Code (ASM): Killbadnikroutine: tst.b (badniktimer).w ; Is it 0? beq.s + ; Yes? skip then rts + tst.b (badnikhit).w ; Is it 0? beq.s + ; Yes? Kill badnik subq.b #1,(badnikhit).w ; Subtract 1 from hit move.b #$20,(badniktimer).w ; Start timer rts + ; etc So when it goes to kill the badnik, unless the (badnikhit).w is 0, it will not kill the badnik. It will subtract 1 from it for the next hit. It will then start the timer, to make the badnik invulnerable for a short period. Then, in the badnik's main code, try this: Code (ASM): tst.b (badniktimer).w ; Is it 0? beq.s + ; Yes? skip then subq.b #1,(badniktimer).w ; Subtract 1 from from timer + ; etc Unless timer is 0, it will keep counting it down. So now, when it does eventually reach 0, the badnik can be hit again. After 4 hits, the badnik should then die. This is all from the top of my head. You might want to tweak it. If this works, you will then want to get rid of using RAM addresses and use the badniks own SSTs, like instead of (badnikhit).w, use obj_off30(a0). The only problem is, all badniks will take the new killbadnik routine into account, and might use that particular offset for something different. EDIT: Quoted previous post because of page-break. I have a habit of breaking pages recently.
On the Sonic Retro wiki, is there an option to search for only completed hacks? I really don't feel like checking every single hack and see if it's completed or not if there's an option to do that with a function or something. Erazor and Megahack Ultra got me back in a Sonic hack mood, so I want to play everything that's not a demo.
You might have gotten away with searching for whatever format the template uses (‘|status=completed', or whatever) were it not for the fact that the reality is more complex than a simple choice between ‘completed’ and ‘demo'. Plenty of hacks have seen stable releases but are not ‘completed’ in the sense that their development has ceased, so they'd be marked as ‘in progress'. By opposite reasoning, so might hacks that haven't had a stable release yet. I suppose a good start towards making your request more feasible would be an additional field in the template for the release type: alpha, beta, stable, final, etc. Of course, someone with better knowledge of teh wikimantics can maybe correct me on any of the above. But that's my presumption from what I've seen.
"final" seems like what I'm looking for. I'll try searching with it. If it doesn't work, I'll just manually check everything. Who knows, maybe I'll find some kind of gem. Thanks.
We had a topic on this in the Site Affairs forum a little while back, and it had gotten started on. Unfortunately, as all things seem to do... it never really got finished or followed through upon. If you guys have any suggestions as to what you'd like it to look like, exactly... I do some wiki work here and there. I can fix it up a bit when I have time.
I haven't been able to come across the SS garbage bug, and it doesn't show up with the new configuration. Thank you for the help!
Sorry if this is a bit of a n00by question, but I'm thinking of starting a little Sonic 1 hacking project. I was wondering if there was an easier to use program for editing Sonic's graphics. I've tried opening Sonic.bin up in my graphics editor, but Sonic's tiles are all over the place (as opposed to them being neatly arranged like I'm used to in graphics editing)! A quick Google search later, I found a program, but it only works for compiled ROMs. I need one that works for a split disassembly.
I think you're in luck. I'm scouting members to test my WIP, Sonic Triad. It currently has a fully functional palette an tile editor, fully functional with compression support and multiple tools and features. UNFORTUNATLY no Mappings support yet. I am able to use it no problem with art editing in my hack. I plan on adding more later. I can give you an early copy of Triad to test out. Again, it's a very early build, but it works with, and it is specifically meant for, disassemblies.
For some reason, when I try to add code (as in, in addition to existing code) to any of the monitors in Sonic 1, it will not build. The rom also fails to build if I add code to the Goggles Monitor and any of the 'Invalid' Monitors (but not the "S" monitor). Does anyone know why this is happening?
What it told me after I did this was: Reported Size: 100303C Reported Checksum:0 Size Applied: FFFFFFFF Checksum Applied: 0 Press any key to continue . . .
You need to tell us why it didn't build. Whenever it doesn't build, it will tell you the errors. If it doesn't say anything, then it should create a new file called "errors.txt" or something like that. Until then, we can't help.
This is what my error.txt said: SN 68k version 2.53 C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INC\PALETTE POINTERS.ASM(31) : Warning : Size of pal_levels ($B) does not match ZoneCount ($7). C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\SONIC.ASM(3053) : Warning : Size of colpointers ($6) does not match ZoneCount ($7). C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INCOBJ\3A GOT THROUGH CARD.ASM(175) : Warning : Size of levelorder ($6) does not match ZoneCount ($7). C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\SONIC.ASM(6851) : Warning : Size of musiclist2 ($6) does not match ZoneCount ($7). C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INC\PATTERN LOAD CUES.ASM(23) : Warning : Size of plc_levels ($6) does not match ZoneCount ($7). C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INC\PATTERN LOAD CUES.ASM(36) : Warning : Size of plc_animals ($6) does not match ZoneCount ($7). C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\SONIC.ASM(9121) : Warning : Forward reference to redefinable symbol C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\SONIC.ASM(2313) : Warning : Forward reference to redefinable symbol C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\SONIC.ASM(2399) : Warning : Forward reference to redefinable symbol C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INCOBJ\89 ENDING SEQUENCE STH.ASM(37) : Error : Branch (32784 bytes) is out of range C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INCOBJ\59 SLZ ELEVATORS.ASM(10) : Warning : Forward reference to redefinable symbol C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INCOBJ\5A SLZ CIRCLING PLATFORM.ASM(10) : Warning : Forward reference to redefinable symbol C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INCOBJ\5B STAIRCASE.ASM(10) : Warning : Forward reference to redefinable symbol C:\USERS\JAEONE\SAVED GAMES\HACKING\SONIC\MY HACKS\SONIC 1 CONTRAST - COPY\_INCOBJ\5E SEESAW.ASM(10) : Warning : Forward reference to redefinable symbol Assembly completed. 1 error(s) from 52346 lines in 8.27 seconds I put the "Error" in bold.
All of those warnings seem worrying too...but that's a branch error meaning a piece of code is just too far away for the branch (bsr.w etc) to reach. For help with that, Selbi had this guide (the out of range stuff is at the start): http://sonicresearch.org/forums/index.php?showtopic=857
Awesome, glad to hear it. Now I have a question...leads on from an older one. To make Sonic move/act normally in a Special Stage, would I have to basically rewrite the Special Stage Sonic (Object 09)'s code to be near identical to the standard Object 01 Sonic's codes in related places? Or would there be something more than that? To put it simpler, is it even POSSIBLE to have normal movement/actions and such in special stages? I found simply changing the line of code to load the object to load the normal Sonic instead presents a problem...camera's not focused on him. Not only that but he doesn't have code for interaction with the special stage objects so things probably go wrong there too offscreen.
I've got lotsa questions needing anwering, but I'll start with one. I've applied THIS So, my problem is when I rapidly press start through and skip to the first zone quickly enough... I can't see my rings, and on rare occasions cannot see my HUD either. Is this an effect of enabling skipping through the SEGA sound? Or is it not? Any one else encounter this?
After following that guide, when the SEGA sound is requested, the 68k will be locked within that loop constantly sending PCM bytes to the YM2612's DAC port, when the start button is pressed, it will break out of the loop, and skip the remaining areas of only the sound driver's software (Caused by the "addq.w #4,sp"), this will only skip back to the calling of the sound driver. This means it will have no effect on the gameplay area of the software, even if the SEGA sound is requested mid-game. That is provided of course, that you haven't changed anything else you weren't suppose to change. Edit: If it puts your mind at ease, I've never came across the bug myself.
K! That narrows it down, I think I now know what is causing the problem then... just a matter of fixing it. Much thanks!
