Basic Questions & Answers thread

Thank you both! Helped me a ton.

 

So, somehow I ended up in this thread which ended up with flamewing linking this page and I readed it, even I don't understand most of the things written there. But Shadow mode catched my attention and readed a couple of times with extra care. I think I finally undertand how it works, so correct me if I'm wrong:

Let's say I want to implement Shadows in a Sonic game. I am running on Eggman's ship on a closed corridor and I wanna see Sonic's shadow projecting on the wall. All I would have to do is enable shadow mode on VDP's register and get a shadow sprite set colored with Color 16, and I would have the walls (set on plane B) with Sonic's shadow, am I right?

 

The shadow sprite needs to use palette line 4 and color 14; color 15 is highlight, and color 16 is out of bounds :specialed:

Moreover, all planes and sprites would need to be set to high priority or they would be shadowed by default, which you don't want. And you want to make sure that the shadow displays behind other sprites or it will mask them (in the Sonic engine, they should ideally use priority 7 for S1/S2 or $380 for S3&K).

 

Actually with color 16 I mean 15, I don't usually start counting from 0, hahaha. I made a mistake anyway. So basically this is what Mortal Kombat 3 does, and I thought it was black magic.

Now I'm confused about priorities, as the only option I know to change priority is that bit on mappings (setted on flags, second 2 number cluster maybe? I don't remember anymore) and that one appeared to set the highest priority.

 

Hey, me again! This time I'm trying to implement the Sonic 3 sound driver, and get this error:

I've been at it for an hour trying to figure out what I could've done to mess it up but I have no idea. Here's the s2.asm file and here's the s2 constants.asm file.

 

Those errors seem to make it pretty clear: those labels don't exist, you deleted them. That, or you placed an 'end' somewhere in your code.

 

So I'm working with the Sonic 3 and Knuckles disassembly and I'm curious about how I would port Sonic 3's mid-boss music to S3K. I already have it in a bin file, but it's bigger than the old one and fills the sound bank. How would I go about making room for it?

 

Size isn't your only problem: that file expects to be in an exact location; too. It's to do with how the file contains absolute Z80 pointers. You'd need a tool that can fix the pointers. Though it might be overkill, I'm sure SMPS2ASM can do the job.

 

I'll try that and post back the results.

Edit: Okay, I tried and the only issue when compiling is the bincludes in the Z80 Sound Driver ASM conflict with the bincludes in the S3 Lockon Data ASM. What should I do?

 

Maybe try commenting out or deleting the bincludes in the S3 Lockon Data ASM that conflict with the bincludes in the Z80 driver ASM.

 

Tried that, it errors that Size_of_Snd_driver2_guess is too small, but tells me to set it to a lower value. Doing that changed nothing unfortunately.

There has to be something I'm doing wrong, here's the error:

Code (Text):

1. soundBank DacBank1 has $DD1 bytes free at end.
2. soundBank DacBank2 has $895 bytes free at end.
3. soundBank DacBank3 has $1BE7 bytes free at end.
4. soundBank DacBank4 has $2EC9 bytes free at end.
5. soundBank SndBank has $257 bytes free at end.
6. soundBank Mus_Bank1_Start has $407 bytes free at end.
7. soundBank Mus_Bank2_Start has $9F1 bytes free at end.
8. soundBank Mus_Bank3_Start has $25F3 bytes free at end.
9. soundBank Mus_Bank4_Start has $1D35 bytes free at end.
10.  
11. s3p2bin.exe: generating sonic3k.bin from sonic3k.p
12. ERROR: Compressed sound driver might not fit.
13. Please increase your value of Size_of_Snd_driver2_guess to at least $45C and try again.

 

Why don't you import Flamewing's S&K Driver to S3K along with downloading the smps pack and then change the contents of s&k's mini-boss music with that of s3's mini-boss music

 

How hard would it be to remove the $300 Block limit?
Tilewise and chunkwise, I'm fine, but I need to squeeze out a few more 16x16 blocks. I have determined that, in order to do this, I should use uncompressed block data in my hack and load them from the ROM, but are the major drawbacks to this?

For the record, right now I'm doing this for a hack of Sonic 1, but want to experiment with it in Sonic 2 later. Will this break Sonic 2's animated pattern mappings?

 

Yes, and it will break HTZ's secondary block file as well, though that one is easily fixed. The animated pattern mappings I suppose could be worked around by grabbing the block data from a savestate.

 

Right, I understand. That's why I plan to do it in Sonic 1 first.

Though, I'm having some trouble atm. The title screen is working, but the levels are loading corrupt blocks.

It is something I'm doing, as far as storing the block pointer, because if I hardcore LevelDataLoad to load GHZ's blocks, it works.

Code (Text):

1.         lea (LevelHeaders).l,a2
2.         lea (a2,d0.w),a2
3.         move.l  a2,-(sp)
4.         addq.l  #4,a2
5.         movea.l (a2)+,a0
6.        
7.         move.l (a2),(v_16x16_point).w ; Load Block data from ROM.
8.        
9.         movea.l (a2)+,a0

I've tried a few different things, but nothing so far has worked... What is the CORRECT method that I haven't tried yet?

edit: Figured it out! Also, how do I bypass the limit in SonLvL?

 

That's what I did, and is why I'm having this problem...

I'm going to fix it, one way or another.

 

I have an important question, regarding my recent question about bypassing the block limit by loading data from ROM, pertaining to usage in Sonic 2.

1: Is getting the data from ROM faster, or slower than reading from RAM? How much impact will it have?
I'm afraid that it's going to be slower, something I don't want.

 

Getting it from RAM is roughly 128th cycle slower, if compared to carts that are faster than the CPU, which has been the case around the Sonic 2 was release, afaik. Older carts would reportedly be slower especially with huge transfers (DMA) but I do not have a full understanding on this. Either way, speed is not a dominant factor anymore for choosing which method to take, but the ROM space itself. Compressed is still way more compact form, albeit you need extra RAM as a tradeoff.

 

Of course, the compression is far more compact, but.. At 1 128th of a cycle, it would seem that the benefit is so minimal, it's not worth making the blocks read from ROM unless I really need the extra room for blocks that badly.

That known... Does anyone know any things I can do to improve the performance in my hack by any decent amount? I know there's not a "concrete" answer to something like this, but any suggestions?

 

It depends on the game, but unless its S3K, porting all kinds of tweaks from S3K would be a start, especially the rendering engine and object engines have been vastly improved and would help a lot with performance. But these kind of things are a lot to do and so I would advise against it unless you have a good grasp on the engine and 68000 ASM.