Yes. The Mega Drive and Master System are not very smart and can't just spit out the whole level at once. It needs to build it up piece by piece through a number of successive steps from the binary level to 32 x 32, 128x128 or 256x256 blocks of art. Depends on what you are using and exactly what you are doing. You could be making the common mistake of just trying to run the small level data file on it's own without actually re-inserting it back into the rom. No. It is hard and intensive. In order to vork with the Mega Drive you must zink like the Mega Drive. You must get inside the Mega Drive's head.
<!--quoteo(post=260340:date=Dec 27 2008, 01:22 PM:name=shobiz)--><div class='quotetop'>QUOTE (shobiz @ Dec 27 2008, 01:22 PM) </a> I also put the new HUD location in PLC to $D800[/quote] Looks like you forgot to set the high priority bit in the mappings you added. [/quote] Thanks for the info! I think I understand. I'll keep on trying.
As do I, I mean, you've got the palletes, art, and level at your disposal. It also helps when you can see what your doing and with a grid to draw your tiles on.
Go to Level_ClrRam, it should look like this: Code (ASM): Level_ClrRam: clearRAM Sprite_Table_Input,$400 clearRAM Object_RAM,$2400 ; clear object RAM clearRAM $FFFFF628,$58 clearRAM Misc_Variables,$100 clearRAM $FFFFFE60,$50 clearRAM $FFFFE700,$100 cmpi.w #$D01,(Current_ZoneAndAct).w ; CPZ 2 beq.s Level_InitWater cmpi.b #$F,(Current_Zone).w ; ARZ beq.s Level_InitWater cmpi.b #8,(Current_Zone).w ; HPZ bne.s + change it to this: Code (ASM): Level_ClrRam: clearRAM Sprite_Table_Input,$400 clearRAM Object_RAM,$2400 ; clear object RAM clearRAM $FFFFF628,$58 clearRAM Misc_Variables,$100 clearRAM $FFFFFE60,$50 clearRAM $FFFFE700,$100 cmpi.w #$D01,(Current_ZoneAndAct).w ; CPZ 2 beq.s Level_InitWater ;cmpi.b #$F,(Current_Zone).w ; ARZ ;beq.s Level_InitWater cmpi.b #8,(Current_Zone).w ; HPZ bne.s + Basically all you have to do there is remove the check for ARZ. That code checks for a level, and if it is the given level, it branches to Level_InitWater.
I have a strange ocurrence in my hack that I am unsure as to why its happening. Basically, The HTZ Boss can be defeated with a sigle hit, bolwing up like an ordinary badnik and the level can't be finished. The other oddity is the ARZ Boss takes an unlimted amount of hits, it never dies. Look at its hit counter in RAM using Kmod, its hit amount fluctuates between 6 and 7. Niether of the bosses code has been modified in any way. I have no clue why this is happening. Any ideas or help would be appreciated! Thanks. EDIT: I think I found my issue, I forgot I changed a few things in Touchresponse.
Okay, I've been having some collision problems with "round" floors for the longest time, and it's beginning to grate on me. A SonED2 shot of the Plane 0 collision in a spot in my Metropolis 1 layout: ...which works 90% of the time, but here's the occasional result: At first I thought the problem was entirely speed-based, but it still happens even when moving slower... you just don't see the running into the ceiling because Sonic runs out of momentum immediately and falls vertically to the ground. It's not the path swapper causing it, as moving that past the apex of the loop had no effect. Something similar happened in the Hacking Contest build of the hack: attempting to roll down the side of a GHZ-style tube led to Sonic running vertically through the floor when the tube began to level out. I've heard several times something along the lines "oh, it's the game engine, you're not getting around that one," but I don't see many other hacks having this problem... although it might just be the lack of Sonic 2 layout hacks out there. So, er... anybody had a similar situation that they worked their way out of?
I suffered at the hands of a similar sounding glitch for a long time. Me and snkenjoi referred to it as 'loop jamming' and initially I thought it was a side effect of excessive speed, although as you say, it doesnt always occur when going at high speed. The problem in our case, turned out to be incorrect solids being used (you don't have the angles displayed in the screenshot so I cant be sure). Basically, I found that although the height maps for a quarter loop are laid out in sequence in the solid selector starting from 49. There is a missing one, which if filled in incorrectly causes the bug. The slight discrepency in the angles doesnt really have an effect 90% of the time but causes you to 'jam' in a loop occasionally, as though you are being derailed from the track through scenery which is supposed to have collision. The layout I have used which has been flawless so far has been as follows. I apologise for the crudity of this drawing, but hopefully it gets the point across. The 6F solid is out of sequence with the other height maps (incidentally its angle is E8, the same as that which 4C uses above it. Prior to using that, I had been using a height map 'of best fit' which was apparently, causing this weird jamming effect. Of course its possible that I have wildly, wildly missed the mark here... Without seeing the problem you've described in more detail I can't be absolutely positive. The other issue you describe seems to be a gamewide glitch. Often I find that if sonic is running (not rolling) along the roof or up/down walls and pinned to the surface by speed and not gravity, he completely ignores collision and will continue running straight through walls and whatever else may be in his way unless he is guided a different way by opposing angles. I find an invisible barrier object usually does the trick in those cases. Hope that helps.
@ iojnekns: Thanks for the advice. The quarterpipe in Metropolis curves corner-to-corner across the entire chunk as opposed to the 3/4 of one your model uses, but the problem was similar. If you look directly to the right of where the top and second "10"s are, there's two extra pixels sticking out of the loop that were caused by an incorrect solid choice. Funny, I don't remember changing any existing solids on that chunk, all I did was replicate the collision for plane 1; perhaps a similar problem went unnoticed in the original game due to the lack of two planes in that level. In any case, that fixed the problem and fixed the problem I had with the tubes. (...I think? It's possible I'm just getting "lucky" and not encountering the issue now.)
Why is it in the Sonic 2 2007 disassembly when I move the Nem Compressed art to somewhere else, or add too much code (before it), certain levels or all levels will not load. They just pause at the title card when you try to play a level. Is there a way to fix this that I am unaware of? Thanks
I remember a tool that was made by Saxman I think, that did basic edits like unlocking characters and how many Emeralds you have. It's only a save editor, you can get it here though but there's pretty much nothing you can do.
Forgot to mention, I already have that Sonic R Save Editor. I was looking for some other hack tools... Thanks
Quick question: I have all the files for the level in question- but I need to know how to associate them with a level slot in Sonic 1. Does anyone know how to make a new level slot in Sonic 1?
Short answer: search for $FFFFFE10 and add entries in the tables that use it. Long answer: the zone number is used in some places to jump to separate routines or load different data. The value at $FFFFFE10 contains the zone number, which is used to jump to the correct subroutine or load the correct data. If you're clueless when it comes to ASM, I might be able to make a guide on the wiki to help you (and anyone else struggling with this).
I'm not completely inept with ASM, but it's not my strong suit. I would greatly appreciate a guide- mainly because I can't find what to change that uses $FFFFFE10.
