Finally got uncompressed chunks working, collision and all. Adapting Sonic 1's less-than-efficient Find_Tile/FindNearestTile ended in failure, so I just used a modified Sonic 2 version. It seemed to get the job done. Give this a go. Code (ASM): Find_Tile: move.w d2,d0 ; y_pos add.w d0,d0 andi.w #$F00,d0 ; rounded 2*y_pos move.w d3,d1 ; x_pos lsr.w #3,d1 move.w d1,d4 lsr.w #4,d1 ; x_pos/128 = x_of_chunk andi.w #$7F,d1 add.w d1,d0 ; d0 is relevant chunk ID now moveq #0,d1 lea (Level_Layout).w,a1 move.b (a1,d0.w),d1 ; move 128*128 chunk ID to d1 add.w d1,d1 move.w word_1E5D0(pc,d1.w),d1 move.w d2,d0 ; y_pos andi.w #$70,d0 add.w d0,d1 andi.w #$E,d4 ; x_pos/8 add.w d4,d1 add.l (Chunk_Table).l,d1 movea.l d1,a1 ; address of block ID rts I do have to say, MainMemory, that's a very interesting trick, that 'moveq #-1 + clr.w' combo. At least I now know what Fragag's guide was doing there by blanking it to "moveq #0". Sorry about that, just noticed how I misread that. As of loading the uncompressed chunks, being the only hack applied to this disassembly, there don't seem to be any bugs with HTZ. I can't tell if this is because the problems stem not from the chunks, but from merging the blocks and tiles, or from the uncompressed chunks being incorporated incorrectly. Here's what I've done so far: Spoiler In loadZoneBlockMaps, replace Code (ASM): move.l (a2)+,d0 andi.l #$FFFFFF,d0 ; pointer to chunk mappings movea.l d0,a0 lea (Chunk_Table).l,a1 bsr.w JmpTo_KosDec With Code (ASM): move.l (a2)+,(Chunk_Table).l ; store the ROM address for the chunk mappings In Find_Tile, replace Code (ASM): moveq #-1,d1 clr.w d1 ; d1 is now $FFFF0000 = Chunk_Table With Code (ASM): moveq #0,d1 Under Code (ASM): add.w d4,d1 Add Code (ASM): add.l (Chunk_Table).l,d1 In GetBlockAddr, replace Code (ASM): moveq #-1,d3 clr.w d3 ; d3 = $FFFF0000 With Code (ASM): moveq #0,d3 Under Code (ASM): add.w d5,d3 ; add horizontal offset of current 16x16 Add Code (ASM): add.l (Chunk_Table).l,d3 In sub_E244, replace Code (ASM): moveq #-1,d3 clr.w d3 ; d3 = $FFFF0000 With Code (ASM): moveq #0,d3 Under Code (ASM): add.w d5,d3 ; add horizontal offset of current 16x16 Add Code (ASM): add.l (Chunk_Table).l,d3 On a side note, I'd imagine you could change some of the decompression buffer pointers to just use Block_Table and Level_Layout instead of Chunk_Table, in the instances where they, like Chunk_Table would have been, are unused, and as long as what's being decompressed can actually fit inside the two so you don't overwrite anything important. Of note, some of HTZ's art (some of its clouds) is decompressed to the end of Chunk_Table during gameplay, so space may be an issue there. Moving straight from ROM to VRAM is not an option, as the art appears to be dynamically modified in RAM. Merged EHZ and HTZ's tiles and blocks, still haven't encountered any bugs beside Rexon's art not loading.
I'm aware of that. Can I not simply use the $C00 bytes of block table for the Title Card letters and whatever else is needed? The bug is in vanilla Sonic 2, but is unnoticeable due to the game only using chunks that do work. You can see the bug if you place most of the EHZ-specific chiunks in the level. Also, "Find_Tile" doesn't seem to be named in Sonic 2.
...It look like we're on different pages here. I've literally swapped out HTZ's layout with EHZ's, and everything looks right, well, except for the obvious parts such as the corkscrews (and a part of the chunks that connect to each end of them) and the background. You can see all of this even through SonLVL, so it's no bug, just overwritten tiles. The only bugged out "normal area", if you will, is the hilly area of the ground used only in EHZ's boss arena, whose unique hill tiles are overwritten with HTZ background mountain tiles. You shouldn't need to use any of the three anyhow. Oh, wait. So, doing the above on a fresh disassembly (RAM chunks) gave me some... interesting results. If what you're talking about is several chunks outright not existing, composed of only nonsensically placed tiles and misplaced collision, then I accidentally fixed it. Somewhere along making the game use uncompressed chunks, this chunk bug goes away. I *might* have an idea of what the problem is, but if you really are encountering the bug with uncompressed chunk ROM loading, then I'm wrong: Maybe that cloud art I mentioned earlier, whilst being loaded to the end of the chunk table, actually overwrites some chunks...? But I really can't tell, it'd be impossible for that to happen if you've already achieved ROM chunk loading, anyhow.
Okay, for a while now I've been meaning to do this, and I finally got around to it the other day: I've "ported" Hidden Palace Zone from the Sonic 2 Wai proto to my Sonic 1 disassembly. I've added custom chunks inspired by the Android/iOS S2 release as well. I haven't gotten around to the cycling pallets/animated art/deformation/water yet, just the basics (hence LZ's ripple effects, I'm using that in the meantime) Now, for the most part, things are fine - I've managed to get the collision working intact. Other than a few pallet issues, the custom chunks are working fine (though I haven't finished adding collision to them yet) - mostly. After adding more 16x blocks so I could get Sonic to switch from high to low plane properly, the problem I'm having becomes much more apparent: This one chunk is completely fucked and I'm not sure why: And while the loop's collision works, it looks like this: Before adding the separate plane blocks I got similar behaviour on another chunk, though it didn't fuck up the rest of the zone that badly. I'm also getting that bug where Sonic's tiles appear garbled after death/reloading. I'm pretty sure the problem is simply that I have either too many 16x blocks or too many 8x tiles (or both) in HPZ, and they're getting overwritten by other data. What I'm wondering is this: What's the "upper limit" for 8x/16x tiles per zone in Sonic 1 (I.e. how many I can have before shit starts fucking up like this)? Also, while I'm here, how does deformation work in the HG disassembly compared to the 2005 one? I tried using Selbi's parallax tool to add deformation for HPZ, but the screen just automatically scrolls up and gets stuck there when I try it.
The buffer area for 16x16 blocks in Sonic 1 is enough to hold $300 blocks, as SonLVL will tell you. The maximum number of 8x8 tiles, on the other hand, depends on where your other art is loaded to in the level.
Ahhh, that explains it. I had something like... $320 blocks in the level. Thanks for the help! For 8x8 tiles, is there a way to calculate how much space in VRAM they're going to take up?
Each tile takes $20 bytes, so if tileCount * $20 is larger than any of the PLCs for the level you're in trouble. There could also be something other than PLCs overwriting your art but I don't work with Sonic 1 so I don't know.
I'm coming back to an old project that I had used with Hivebrain's 2005 assembly in SNASM68k. It no longer works on my 64-bit OS, but the wiki said I could convert it to ASM68K. Following the guide, I changed the line in build.bat, and then added the macro in sonic1.asm and then fixed the SkipSecurity line, and changed up the include lines. Now, when I use build.bat, include.exe stops working and command prompt shows me all the errors in these include lines, saying "op- code not recognized" Is there anything I could have missed?
You didn't follow the guide to the end. include.exe isn't necessary with ASM68K, so just follow the remaining instructions and you shouldn't have any more issues.
Well, that was a stupid mistake on my part, and I'm embarrassed, thank you. Now that I have all those changes within the programs, I still can't get it to worked. After I applied all the fixes in the guide, it still doesn't build; the batch file is looking for the ASM68k application. I tried transferring the ASM68k.exe program from the other build (this one: http://info.sonicretro.org/File:Sonic_1_(Split_and_Text_by_Hivebrain)_(ASM68K).zip) into the folder. Still doesn't build, and I'm getting errors with all those include statements. (The statements the guide says to change Code (Text): ; include=<filename>.asm into Code (Text): include "<filename>.asm" I tried doing the opposite. I unzipped the entire ASM68K folder and transferred the game info (my layouts, palletes, sonic1.asm, etc.) but I'm still getting the same errors. Was there something even more obvious that I should have been aware of?
The correct form to use with ASM68K is Code (ASM): include "<filename>.asm" Make sure the included files are actually there. (Normally, they should be, since they are essentially the same between the SNASM68K and the ASM68K versions on the wiki.) If it still doesn't work, can you post an example of an error? (You can add pause at the end of build.bat to leave the console window open after building.)
It just sounds like you're converting the SNASM68K-formatted includes to the ASM68K format incorrectly. Just open the sonic1.asm found in the ASM68K disassembly and compare how its includes are arranged to those in your disassembly and adjust yours to match. Though I can't understand how you'd have messed up while following the guide's method, where it was as easy as a pair of find-and-replace's. The format should simply be the 'include' instruction followed by the path to the target file surrounded with quotation marks. On a slightly different topic, the guide does expect you to provide the ASM68K.exe yourself. Also, your "doing the opposite" didn't work because the problem lies within sonic1.asm whose includes are seemingly broken. You replaced the working sonic1.asm with your broken one, hence why even that one didn't build. EDIT: Ninja'd, curses!
Yup, I had everything reading include "<filename>.asm" I tried once again to start the conversion. Without changing anything other than the .bat file and sonic1.asm, I get the error saying: " 'asm68k is not recognized as an internal or external commans, operable program or batch file." I took the ASM68K program from the other disassembly and plopped it into my folder. The error it gives me then is "Bad size OP-Code". The puzzling part about this is that the problem line here is: Code (Text): move a6,usp This confuses me a lot because, I changed that line as the guide said: [68k]move.l a6,usp[/68k] There is no line that reads "move a6,usp" anywhere in the code, because I changed it to move.l
In build.bat, on the like that calls ASM68K, is it referring to sonic1.asm or to s1comb.asm? It should be sonic1.asm; s1comb.asm isn't necessary anymore, you should delete it.
This is DOS/Windows' rather verbose and roundabout way of saying "asm68k was not found". Wherever you placed the exe, it was not in a place that the batch script is looking for it. Plus, what FraGag said.
Yeah, I figured that, which is why the next step I took was this: It was like this: Code (Text): asm68k /o op+ /o os+ /o ow+ /o oz+ /o oaq+ /o osq+ /o omq+ /p /o ae- s1comb.asm, s1built.bin I changed it to: Code (Text): asm68k /o op+ /o os+ /o ow+ /o oz+ /o oaq+ /o osq+ /o omq+ /p /o ae- sonic1.asm, s1built.bin And now I get more issues. Op-code not recognised: include '<filename>.asm' The lines in my actual sonic1.asm do have double quotes. Thank you guys for putting up with me even this far.
Is there at least one space or tab before include? If not, then include is being treated as a label and the string becomes an unrecognized opcode.
Thank you guys so much for putting up with this. Indeed, it was a small mistake of not including any spacing. Just as FraGag suggested, I added spaces, and voilà. I definitely have to review the ASM guides again. Thanks a lot.
Aaaaalright, I'm back with more questions related to S2Final/S2Beta-to-S1 porting shenanigans. So I've managed to port over a few of HPZ's objects and graphics (I'm still working on things, but I've got the glowing orb and waterfall objects ported, and have set up the bridge and floating platform objects to use HPZ-specific art). I've also taken a look at both S2Final and S2Beta's HPZ deformation code, and ported it over as well. Having said that, I'm running into a few visual problems... The further I move, the more HPZ's background starts to "overwrite" 16x16 blocks instead of just scrolling (I'm not sure how to describe this any better). The bigger problem is with the part of the background that's offscreen: (ignore the palette, I hadn't ported HPZ's cycling palette at this point) It gets completely dishevelled like this. I've double-checked several times, and the ScrollBlock routines that the "main" routine calls are their S1 equivalents. I've even tried porting over the proto's versions of the ScrollBlock routines and using those (after correcting the RAM addresses of course), but they act even stranger (I assume I'm missing something in the main deform routine that's causing this). First question - What could be causing it to behave this way? The other issue (which I'm hoping isn't too vague/general of a question to ask, my apologies if it is) is with the waterfall object. Once again, I've ported the object code over and converted all the addresses to their S1 equivalents, so - as far as I know - it's not reading unrelated data. The graphics load fine, but I can't get them to appear in-game, except in only one spot (and even then, they aren't showing up correctly): I know the original object code checks for the water level, but I've altered that check already (it uses the lower screen boundary). Having said that, I notice in the S2Final disassembly, it checks a variable called "Camera_x_pos_coarse" - Is this possibly related?
