I've been trying to edit my hammer spring code to work with two attacks, a ground and jump one: Code (ASM): Obj41_Up: ; XREF: Obj41_Index move.w #$1B,d1 move.w #8,d2 move.w #$10,d3 move.w 8(a0),d4 jsr SolidObject tst.b $25(a0) ; is Sonic on top of the spring? bne.s Obj41_BounceUp ; if yes, branch Obj41_NoJHammer: cmpi.b #$22,$1C(a1) ;"is Amy jump hammering?" beq.s Obj41_Hammer ; if yes, branch tst.b ($FFFFFFA4).w ; is hammer attack being performed? beq.s Obj41_NoHammerAttack ; if not, branch Obj41_Hammer: moveq #0,d0 ; clear d0 move.w $8(a0),d0 ; load springs's X-pos to d0 sub.w ($FFFFD008).w,d0 ; substract Amy's X-pos from it bpl.s Obj41_XPositive ; if answer is positive, branch neg.w d0 ; otherwise negate d0 Obj41_XPositive: cmpi.w #35,d0 ; is Amy within 35 pixels of the spring (X-axis)? bge.s Obj41_NoHammerAttack ; if not, branch moveq #0,d0 ; clear d0 move.w $C(a0),d0 ; load springs's Y-pos to d0 sub.w ($FFFFD00C).w,d0 ; substract Amy's Y-pos from it bpl.s Obj41_YPositive ; if answer is positive, branch neg.w d0 ; otherwise negate d0 Obj41_YPositive: cmpi.w #35,d0 ; is Amy within 35 pixels of the spring (Y-axis)? bge.s Obj41_NoHammerAttack ; if not, branch bra.s Obj41_BounceUp ; otherwise make spring bouncing Obj41_NoHammerAttack: rts ; return ; =========================================================================== Obj41_BounceUp: ; XREF: Obj41_Up addq.b #2,$24(a0) addq.w #8,$C(a1) move.w $30(a0),$12(a1) ; move Sonic upwards It activates however the bounce the jump hammer branch activates is oddly small. Any idea what is dragging down the bounce for the mid air branch? *Is there any advisable way to fix the walk jump bug in Sonic 1 with a non roll jump animation?
I don't know what could cause the slowdown, but when I added some calls in my Jumpdash code to check the level boundary it slowed down as well. As for #2 - You just need to change the animation number that's being written.
It's not slowing down it's just a weakened bounce (about to the height of the character). EDIT: Tried the walk jump fix, it works. Thanx. Pretty sure I had tried this method before and it didn't work so thought it maybe had something to do with the roll routine. Oh well.
So, I want to do a Sonic 2 hack and add new zone art in. Should I bother trying to use SonED/SonED 2 or wait for that newer level program to come out? Mainly asking this since it's more opinion related.
Are there any tutorials on how to use xm4smps? I think I have a basic idea of how to use it, but I'm unable to do anything, mainly because I don't know how to get voice banks. Where do I get those from? I googled for about an hour looking for some, or some way to get them. No luck! =/
I couldn't find many either, so I made the SMPS Archives for that. Hope admins don't see as advertising, but as a resource. http://smps.digibase.ca/
Where exactly are the voice banks on that site? I signed up but still can't seem to find them. EDIT: So, SOTI sent me some. There should still really be a tutorial for this stuff though. It's not new user friendly at all.
So I am having trouble with PlaneEd. I am using the japanese credits for a info screen. However, things don't seem to be going well. This: Palette File: pallet/sonic.bin Mapping File: mapeni/japcreds.bin Art File: artnem/japcreds.bin Mapping Compression: Enigma Art Compression: Nemesis Palette Length: 0x20 Palette Offset: 0x20 x-Size: 34 y-Size: 28 Tile Offset: 0x200 Makes this: Which makes this: The y size doesn't seem to be going any lower than 3 tiles and whatever I type in those three become not what I want, which seems to be the title screen logo tiles. Can anyone help?
http://smps.digibase.ca/index.php?board=36.0 Don't see how you can miss that. Is VRAM being cleared properly? If it's not it can cause things to mess like that, that's all I can think of right now.
>>Implying implications Excellent, thank you! Now if only I could get Mid2XM working on here. If there's something obviously laying around, I will miss it. I will find a way, that's what I do! :specialed: Thanks man.
SonED2, including the art importing feature, is a charm to use, if you know how (which apparently many people don't). If you're set on that you want to put your zone into a ROM hack, then I don't see any reason not to use SonED2 for it. If/when a/the new editor comes out, I assume you could still switch over to it at a later point if you prefer it over SonED2. The one somewhat tedious task in importing a zone is assigning collision blocks to your art blocks; however that's a non-trivial task and I'm not sure how well it could be automated by a program (unless you provide another image with the masks), and therefore I'm not sure whether future editor would support that. The SonED2 documentation specifies what you have to do for art importing, but there are a few tricks that ensure that the process goes well. So if you decide to go with SonED2 for art importing, I can write up a quick guide with some notes; iojnekns' guide is a good start, but it still has some flaws. Just for reference, here's a project file that works for the Japanese credits screen (I arbitrarily chose the SBZ palette to have the kanji stand out in a different color than the background): Code (Text): Palette File: pallet/sbz_act1.bin Mapping File: mapeni/japcreds.bin Art File: artnem/japcreds.bin Mapping Compression: Enigma Art Compression: Nemesis Palette Length: 0x20 Palette Offset: 0x00 x-Size: 40 y-Size: 28 Tile Offset: 0 First thing: Assuming you use the original Sonic.bin palette which is 32 = 0x20 bytes of size, I'm surprised the program doesn't crash for you, as you specify a palette offset of 0x20, meaning that the program reads from 0x20 onwards past the end of the file. Palette Offset + Palette Length should never exceed the size of the palette file (note that 0x is simply a prefix for hex-values like $ is in M68k asm). Second: The size of a Genesis screen is 40x28 tiles; while you can specify a different size for the screen, you'll have to adapt the corresponding code as well (first SVN version, second old version equivalent): Code (ASM): copyTilemap $FF0000,$C000,$27,$1B Code (ASM): lea ($FF0000).l,a1 move.l #$40000003,d0 moveq #$27,d1 moveq #$1B,d2 bsr.w ShowVDPGraphics $FF0000 is where the Screen mappings have been decompressed to earlier (as is indicated by the code below). The move.w #0,d0 is a value that is added to every tile in your mappings, if e.g. you wanted the mappings to use palette line 1 (counting from 0), but didn't map it in PlaneEd with that palette line, you'd put $2000 there instead of 0. You can also set all tiles to High Priority, flip them or add another tile offset with that. Though in your case keeping it at 0 as it is should be fine. Code (ASM): lea ($FF0000).l,a1 lea (Eni_JapNames).l,a0 ; load mappings for Japanese credits move.w #0,d0 bsr.w EniDec $C000 is the address in VRAM the plane mappings a written to (in the old version this is encoded in $40000003, read VDP Doc for more info), conventionally $C000 is the address for the foreground plane in Sonic games. Now coming to the important part, $27 x $1B is in decimal 39x27, specifying that the mappings you got are supposed to be of size 40x28. So if you want to use 34 for the x-size, you'd have to replace $27 by $21 = 34 - 1. Third: You can imagine the Tile Offset like the position in VRAM the art is decompressed to. In the SVN version you can see with the locVRAM macro that the address is 0, so your tile offset should be the same. Code (ASM): locVRAM 0 lea (Nem_JapNames).l,a0 ; load Japanese credits bsr.w NemDec In the old disasm locVRAM 0 corresponds to move.l #$40000000,($C00004).l, where the 0 is encoded in $40000000. You can again read the VDP doc to see how exactly, or just use the SVN version/port the macro over from the SVN version if you want to alter the values. One thing you can do to ensure that your mappings are referring the correct art is taking a savestate when the screen is displayed, then using the savestate as art file and setting art compression to None, and the Tile Offset to 0x12478 (This is where the VRAM dump starts in a savestate).
Going back to the S3K Debug List. I've Kind of get the jist of adding it. However, it doesn't seem to work. Also, is there a list for the object name? Like how is the asm? Obj_HCZLargeFan" Code (ASM): dc.l $6C31A dc.l $362608+$1000000 dc.w $43FF I'm trying to add MGZ's boss to the debug list.
Ok got a sexy info screen now. Now I want it to appear longer than what it does. So far I have looked into the extender for the title screen: move.w #$499,($FFFFF614).w; run title screen for $400 frames Something similar I think would work, I just don't know what it should be. F614 isn't labeled on the wiki. Is it just scratch?
It really is what you think it is, the number of frames to display the Title Screen. A higher number will make it being displayed longer and smaller of course shorter. A cool thing about this RAM adress is, that it works everywhere. So you don't need to substract it yourself, you just need to check if it's empty.
How would I set it up though? Should I use DelayProgram? For example: Sega_WaitEnd: move.b #2,($FFFFF62A).w bsr.w DelayProgram tst.w ($FFFFF614).w beq.s Sega_GotoTitle Ok, by looking at the information for DelayProgram, it says all I have to do is insert the number of frames I want into F62A. So I tried adding this after Title_ClrPallet. move.b #200,($FFFFF62A).w bsr.w DelayProgram tst.w ($FFFFF614).w beq.s Title_LoadText Didn't work. What should I do differently? -------------------------------------------------------------------------------------- Tried this and it didn't work either. Title_ClrPallet: move.l d0,(a1)+ dbf d1,Title_ClrPallet ; fill pallet with 0 (black) moveq #3,d0 ; load Sonic's pallet bsr.w PalLoad1 ;move.b #$8A,($FFFFD080).w ; load "SONIC TEAM PRESENTS" object jsr ObjectsLoad jsr BuildSprites bsr.w Pal_FadeTo Fizz: move.b #200,($FFFFF62A).w bsr.w DelayProgram tst.w ($FFFFF614).w beq.s Fizz2 bra.w Fizz Fizz2: move #$2700,sr ... At least this one doesn't seem to show any glitches.
DelayProgram is a pretty bad misnomer, and the description for that routine is plain wrong. In the SVN version it has been renamed to WaitForVBla, meaning that the routine simply waits until a VBlank interrupt occurs. The purpose of it is to synchronize the game logic to the screen output, and make sure it runs at the correct framerate (barring lag). During VBlank $FFF62A gets set to 0, and therefore the program will exit the waiting loop in WaitForVBla. What $FFF62A actually contains is an index multiplied with 2 in the table VBla_Index/off_B6E. The table contains pointers to what code to execute during the VBlank interrupt. The actual framecounter is $FFF614, and you can see that it gets decreased once every frame during VBlank interrupt at VBla_14/loc_C36. Both VBlank indices 2 and $14 execute that code, though 2 in addition checks Keypresses and some other stuff, while $14 solely waits. So the first snippet of code you got should work, if you just write the amount of frames you want to wait into $FFF614 beforehand.
move.b #200,($FFFFF614).w Fizz: sub.b #1,($FFFFF614).w cmpi.b #0,($FFFFF614).w beq.s Fizz2 bra.w Fizz Even helping it along doesn't work. I am confused. Should I use DelayProgram after all?
