Basic Questions & Answers thread

I mean, setting Sonic's position does make the camera try to catch up to Sonic.
do you mean like making the camera just snap directly to Sonic?

 

That's right, it does. I was thinking of doing a snap. If you do that, I recommend applying an effect to make the palette flash white temporarily (kinda like the Ending sequence if you have all emeralds).

 

For camera snapping, you will need to redraw the entire screen as well, because the stage renderer only updates per row/column during gameplay. Sonic 2 implemented a flag that does just that, so that can be ported over, and you'll have an easy way to redraw the screen.

 

ehh, if you're trying to teleport Sonic into a room that looks the same as the one he was in, but is actually different, you won't need to make the palette flash. you can, but it's not necessary. let the player wonder how they went in one room and emerged out of it to a completely different reality =)

 

Well if you intend to keep Sonic in a visually identical room then don't bother redrawing the tilemap at all. We just established that level drawing is the biggest contributor to lag in the classic games, may as well reduce that.

 

@Kilo While I missed their point about going into an identical room (in that case, redrawing would be redundant, yes), I don't agree with your point about the stage drawing.

For one, stage drawing is not the biggest contributor to lag, it's just not handled in a nice way (Sonic 3K just splits up the workload as to put less stress on the V-BLANK interrupt routine). I'd say objects make a far greater impact on performance, especially objects like bridges and swings that use multiple objects in Sonic 1, and also rings, especially the ones that you drop when getting hit (dropped rings all check floor collision, and it's not exactly a cheap and fast operation. They did attempt to get around this by only splitting the collision checks into quarters, with only 1 quarter checking collision in a frame, but it's still not perfect).

Second, in this case, it'd only be redrawing for like 1 frame when the teleport happens, so it wouldn't even be noticeable anyways. It'd be different if it was constantly redrawing.

 

I’m currently trying to build a ROM hack I’m working on. When I go to build, nothing… happens. It just hangs and only displays “SN 68k version 2.53” (I’m using Hivebrain), but the ROM never actually builds no matter what I’ve done. ASM68K.exe is responding (as I see it in Task Manager). Any help or anyone else have this problem before?

 

What changes have you made since the last time it was able to build, did you move any files, rename them?

 

The only change I made was importing an Options Screen I made in an older cancelled hack I made, which is what causes the hang. No already existing files moved or renamed.

 

I haven't used ASM68K in ages, but IIRC you can check your disassembly folder for some kind of log file, likely called "errors.txt".

You can sort files by Date Modified after a build attempt to temporarily sort your files to make it easier to locate.

 

Anyone familiar with the S3K disassembly able to tell me why I get a weird build error when trying to build S&K? I tried adding a single art file, then opted to build SK alone and it wouldnt build.

There is a line for the assembler near the end of the main asm file, and commenting it out allows me to build, but then the SK ROM file is double the size. Here is the message in question:

Code (Text):

1. > > > sonic3k.asm(203252) org(4): error: too much stuff before org $200000 ($200000 bytes)
2. > > >                         error "too much stuff before org $\{$200000} ($\{(-.diff)} bytes)"
3.  
4. **********************************************************************
5. *                                                                    *
6. *     There were build errors. See sonic3k.log for more details.     *
7. *                                                                    *
8. **********************************************************************
9.  
10. Press any key to continue . . .

What should I do?

 

SK alone is very tightly packed; you’d be best cleaning out unused data and/or compressing the existing data.

And, if you want to maintain UPMEM compat, make sure all the data KiS2 uses (such as the Knuckles Sprites and KiS2 object layouts) are in the exact same spots as the base ROM.

 

UPMEM compatibility is not a factor for this mini-project so I could probably remove KiS2 content. Perhaps removing that will help.
Thank you!

 

What are the "Unused Bits" used in SMPS files?

 

You're gonna have to be a bit more specific.

 

I think they are referring to the "smpsVcUnusedBits" macro in smps2asm. Basically, some games that use SMPS will have bits stored in the unused parts of the feedback/algorithm and decay rate register data for some reason, and the macro is there to provide compatibility for that (useful for disassemblies that aim for bit-perfect results, I had to make use of it for Chaotix).

 

My observations on this:

 

A small question, would there be a way to change the level's pallete whilst in a level? I've tried many things, including using PalLoad1 and adding the new palletes through pallete pointers. In case you're wondering, I'm using 2005 Hivebrain Sonic 1.

 

You need to use PalLoad2. PalLoad1 loads the palette into a target buffer which is referenced by palette fading functions. PalLoad2 loads it directly into current palette buffer.

 

I have it working, although it lags tremendously when loading the new pallete. I'll work on optimizing that, if I can!

You sure it's PalLoad2? Here's the code for all of this by the way, not sure if I need to set any values before calling PalLoad2

Code (Text):

1. Obj2E_ChkSonic:
2.         cmpi.b    #2,d0        ; does monitor contain Sonic?
3.         bne.s    Obj2E_ChkShoes
4.  
5. ExtraLife:
6.         moveq #14,d0 ; load next GHZ pallet
7.         bra.w    JmpPalLoad