Alright, my problem with Sonic Lost World's Zelda Zone .dds files is solved. On another forum, I was advised to use Texconv2 or Switch toolbox. Texconv2 didn't work, but Switch toolbox opened them without problem ^^
Does anyone here still know how to add characters to the options screen in the Sonic 2 disassembly? I try adding entries to off_92D2 and off_92DE and changing either three entries in loc_92BA from 3 to 4 but it just garbles up the select screen. Am i doing something wrong here? EDIT: Nevermind. Have gotten past that roadblock and got the third character working. A weird bug occurs however where their sprite's partway into floor. Any idea what's causing that?
Are there any guides to how a disassembly should work? I'm thinking (merely toying with the idea) that I should finally put my Sonic the Fighters disassembly onto Github. I don't have any idea how to split the disassembly up other than a few examples found in the i960 Processor Assembler User's Guide.
Just set it up like it's source code. Organize the data and code how you think it should be organized, and set up include directives/linking. It should be noted that Sonic Retro doesn't really seem to have a standard for how disassemblies should be organized. Just take a look at the Sonic 1, 2, and 3K disassemblies, they are organized differently from each other.
I've discussed this a little bit on discord, but I am wondering what there is against releasing a disassembly that isn't intended to be reassembled? The means to reassemble Sonic the Fighters are nearly lost to time, it would be like creating a Sonic 1 assembly file with no surviving assemblers on the internet. Theoretically I compiled the targeted assembler in cygwin, but that limits people just to Windows, and I don't even use Windows anymore. The dependencies required to build the assembler are also ancient, possibly breaking modern linux distros, which is why cygwin was a good environment to experiment in. I've spent a lot of time documenting everything I can regarding Sonic the Fighters, it's data, and it's memory addresses, and I'd love for the public to see and possibly research it as well. So I may release it in my own style with notes for a theoretical assembly build, or I may write my own program to build it from my own style of notes... actually I kinda like that...
I've got a minor issue regarding PLCs. I've not had this exact issue before and IDK what's causing it. So, I added 4 tiles for in-level Chaos Emeralds to my hack. PLC's for Main2: look like so Code (Text): ; --------------------------------------------------------------------------- ; Pattern load cues - standard block 2 ; --------------------------------------------------------------------------- PLC_Main2: dc.w ((PLC_Main2end-PLC_Main2-2)/6)-1 plcm Nem_Lamp, ArtNem_Lamppost_locVRAM ; lamppost plcm Nem_Ring, ArtNem_Ring_locVRAM ; rings plcm Nem_Monitors, ArtNem_Monitors_locVRAM ; monitors plcm Nem_ChaosEm, $AE80 ; chaos emerald plcm Nem_Lives, $FA80 ; lives counter PLC_Main2end: If I remove Nem_ChaosEm, everything works great. If I put it in, then SBZ and LZ (all acts for both zones, not just the water levels) will soft-lock after the title card appears (@Level_TtlCardLoop), because apparently (v_plc_buffer) never clears. At first I thought I should just move some art out of Main2. I tried moving the emerald. Still happened. Tried moving the Lives out. Still happened. So then I thought the Emerald art's short size was an issue and I duplicated the 4 tiles to double the size. Stillt the same result. Only removing the art fixed this. Mind you, this doesn't happen with the other 4 zones whatsoever. Only LZ and SBZ. I've no clue what could be doing this...
There's a bug in how PLCs are processed. It just lazily shifts the data over 4 bytes at a time (even though an entry is 6 bytes), thus only shifting $58 bytes instead of $5A. Even worse, it doesn't clear out the very last entry slot in the buffer, so if something gets loaded there, it constantly gets copied over and over as the PLC buffer is processed, thus landing you in an infinite loop where it waits for PLCs to be fully processed. @vladikcomper did post a fix for it here, but I'm not sure that it's available to everyone, so I'll just mirror the fix here: Code (Text): loc_16DC: lea (v_plc_buffer).w,a0 lea 6(a0),a1 moveq #$E,d0 ; do $F cues loc_16E2: move.l (a1)+,(a0)+ move.w (a1)+,(a0)+ dbf d0,loc_16E2 moveq #0,d0 move.l d0,(a0)+ ; clear the last cue to avoid overcopying it move.w d0,(a0)+ ; rts
Cheers! One thing to note is that some may assume that this fix will be needed even if you dont add PLCs to the level's cue itself as the level's cue doesn't hit $10 entries, as was in my case. Adding to Main2 on top of what the level itself is doing can also caused the problem, but after applying this fix, it works perfectly. Thanks again!
The main and level PLCs are all queued at once, so it doesn't really matter which lists are queued, just how many entries are queued at once.
Does anyone know how to add a new character to Special Stage format in Sonic 2? The Knuckles tutorial on the wiki has nothing about it and I need to figure out how to redirect a new set of sprites for a third playable character (the HUD is also bugged so that would need to be fixed too).
Is there a way I can convert MIDI to VGM (YM2612)? I tried M2V and I couldn't load in MIDI files for some odd reason. Can you help me?
Did you use the latest version? Look here to make sure of that. ValleyBell and others completely overhauled my initial release. If that still fails, upload a problematic MIDI somewhere so we can take a look.
Thanks, the PSG tool worked. But I couldn't load my midi into the YM2612 tool because there was no way I could load in MIDIs, how do I do that?
Right so a question about Sonic 2's VRAM here. What is that mess of static sprites on F800 and is it possible to move it to another location? Right now I intend to add a character whose tile set slips a little into Tails/Cream's slot, but I'd love if I could move Cream downward a bit so I could maybe keep co-op with them.
Alongside tile and tilemap data, VRAM also holds horizontal scroll data and sprite data. In this case, Sonic 2 has the sprite data located at 0xF800 and the horizontal scroll data at 0xFC00. Yes, it is possible to change the location by changing where the data is stored in VRAM (see the vertical interrupt routine) and also changing the base address for the data with a VDP register.
Okay, so does the sprite data always just stay within those ten or so tiles or does it expand some times? (Which might explain why the life icon data is shifted a bit further up the line below.)
The sprite table will be $280 bytes (so that will be $14 tiles worth), V-blank will always transfer $280 bytes regardless of how many sprites are in the table. As a side note, I can see many of your character's tile appear to be blank, perhaps it'd be best investing in using more sprite pieces to cut down on empty tiles.
Ah so it's a line and a bit then (hence the space before the life icon). And the character in question isn't in use there, they take up way more tiles, and some of Cream's animations do as well.
quick question, nothing major. I cannot find RingGroup.cs in SonLVL's S2 files... though the main ini lists that as being where the Ring's data is located. I don't really NEED it, but I was just curious
You should probably ask questions about SonLVL in the SonLVL thread. Those lines are left over from the early days, where SonLVL required a full class definition for rings. I deleted the file when I switched to a built-in class, but forgot to delete those lines in the ini file.
