Discussion in 'Discussion & Q&A' started by Malevolence, Jul 7, 2009.
I think this question has been answered. Click here.
Thanks for linking me to that thread, but I can't find what I'm looking for. What I asked was which FM channels should I prefer using to minimize the music being overridden by sound effects. (e.g. if I should favor FM3 over FM4 because it gets overridden less)
Choose either FM1 or FM2. The sound effect plays with three FMS (FM3-4-5) or PSGS. But what instrument?
Yeah, I already prioritize FM1 and FM2, but I was not aware of the fact that whether I should use channels FM3 to FM5 also depended on which instrument I'm using. Since I've yet to decide what instruments I want to use, I'll just find out through experimentation.
MarkeyJester made a video showcasing how SFX are broken down:
Most SFX use FM5, and occasionally FM4.
Hello, there, I am having some problems whn trying to import some background assets to the Sonic 1 ROM using SonED and SonLVL( i use both Sonic_1_(Split_and_Text_by_Hivebrain)_(ASM68K) and Sonic 1 GitHub versions of dissasemblies) , using the steps shown in the following video:
In sum, it asks to delete the background tiles (8x8 tiles) blocks (16x16) and chunks(256x256).After that I import the new ones into the ROM
But when I build the ROM the sprites are all out of place:
The only stage it worked perfectly was in Spring Yard Zone, all the others have the background misconfigured. Is there some way to work around this, or another method to replace these sprites?
Is there a way I can properly build the github disassembly on linux the tools that come bundled with it are built for windows
@Eiskaffee, building on Linux is actually pretty easy, given most of the tools are just old and simple command-line tools, thus they can be launched in Wine with no issues.
Just make sure you have Wine installed on your system, then just a simple ...
wine start build.bat
... in your disassembly directory would suffice.
wine start build.bat
Yes, it has been answered, but in another topic.
Do not quote me on this as it's been a while since I worked with anything background related, but I believe (just assuming here) you need to alter the DeformLayers.asm file to fix how the background is actually set up in these respective levels. SonLVL doesn't alter this code when you modify the background. Again, it's been a while so I might be wrong about both SonLVL and this. Just spitballing ideas here since nobody has answered your question yet. How to fix these background issues, is beyond me.
So when you load everything in SonLVL, it looks normal? It looks to me like the blocks are pointing to the wrong tiles, but the new tiles are definitely in there, so it could be SonLVL and the ROM are loading different versions of "map16/LZ.bin". Alternatively, maybe there are more blocks than the game is meant to work with. Try pressing the "Remove unused blocks" button in SonLVL. If you still can't figure out the issue, I'd try resetting LZ's assets to the default and building the ROM during every step of the process so you know more specifically what part breaks it.
DeformLayers.asm handles scrolling and parallax effects. I doubt that's related to the issue.
Having a bit of issues editing graphics in Sonic 3, here. I'm not sure if it's an issue in Flex2 or Sonic 3's disassembly. Take for instance the checkpoint
The file I'm editing in question is General/Sprites/Starpost/Starpost.bin
That's weird. Last time I edited the checkpoint's art, I didn't have any problems.
EDIT: I don't know what I was thinking posting this. Put my post in the Trash thread, please.
It looks like it's using the wrong palette.
No it's using the correct palette. Line 0 is what Sonic and the checkpoint are on, both in this hack and in the original. The modified palette is a 4 shade greyscale, with the rest being magenta. The issue is that the graphics aren't being edited, because if you were to revert to the original palette, it'd look like it would in base S3K.
Figured out the problem myself, turns out the disassembly has 2 files with the starpost art. I was editing General/Sprites/Starpost/Starpost.bin as any reasonable person would expect it to be, but in actuality, it was located in General/Sprites/Enemy Misc/EnemyPtsStarpost.bin, which is practically the exact same file. just with the points that pop out of enemies.
Doesn't help my feelings for this disassembly at all.
Looks like it's an unused file in S3.
This issue isn't exclusive to the checkpoint either. The rings for instance are packed with the HUD.
That's... not the disassembly's fault? The developers packed the art that way.
Separate names with a comma.