Basic Questions & Answers thread

^^ That's interesting. I'll look into the other zones as well.

 

Hi all, I wonder if someone can shed some light on why the Insta-shield mappings don't appear to work properly in SonMapEd. I've loaded:

Code (Text):

1. "General/Sprites/Shields/Insta-Shield.bin"

as the art,

Code (Text):

1. "General/Sprites/Shields/Map - Insta-Shield.asm"

for the mappings, and

Code (Text):

1. "General/Sprites/Shields/DPLC - Insta-Shield.asm"

for the DPLC. I've remembered to select Sonic 3 mode and everything - anyone have any ideas? Maybe I'm just doing something wrong? Here's a screenshot:




Thanks in advance!

 

SonMapEd does not support the DPLC format used for non-player objects. Presently your best bet is to use MappingsConverter to convert the DPLCs to Sonic 2/S3K player format, then convert back to normal S3K after editing.

 

Never knew that, thanks a lot for your help!

 

Just to clarify... The separate DPLC formats... they only apply to S3K, correct? S2 uses the same format for both players and objects, yes?

 

Yes.

 

I have a simple question in regards to optimizing Sonic 2.

Right now, I'm looking at these values:

Code (Text):

1. Horiz_block_crossed_flag:   ds.b    1   ; toggles between 0 and $10 when you cross a block boundary horizontally
2. Verti_block_crossed_flag:   ds.b    1   ; toggles between 0 and $10 when you cross a block boundary vertically
3. Horiz_block_crossed_flag_BG:    ds.b    1   ; toggles between 0 and $10 when background camera crosses a block boundary horizontally
4. Verti_block_crossed_flag_BG:    ds.b    1   ; toggles between 0 and $10 when background camera crosses a block boundary vertically

I'm thinking if they really do just toggle, wouldn't it be best if they were all just converted to a single byte, having their individual bits tested for for the different things?

Well, I decided to give that a try, and I want to know the best way to deal will a certain situation, namely, setting two bits at once. The original code:

Code (Text):

1. move.w  #$1010,(Horiz_block_crossed_flag).w

I'm not 100% sure a bout the method I used, which is this:

Code (Text):

1. ori.b #$3,(block_crossed_flag).w ;Set Horizontal and Vertical scrolling flags.

Will this set the correct bits, and not interfere with the others?

Additionally, how much will instead using bits rather than bytes actually save? My logic tells me that it would usually be about 8x faster, since it's only working with an eighth of a byte, but I don't have a full understanding of what is always faster.

 

Yes, with a bitwise or, any bits set in either number will be set in the result.

 

Okay, I'm having two things now, one is a problem, which I'm asking for wisdom on, and the other is a question about an issue with Sonic 2 itself.

First off: I just re-implemented a zone in my hack, and before, it was having a problem where Sonic and Tails' DPLCs would not update at the start of the level, so they would either be invisible, or use the player's last loaded art from the previous zone, causing them to look like a garbled mess. It's still happening, even in the new ROM.
Does anyone know why or how this can happen, and what the correct way of fixing it is?

Second question, theoretically easier; Does anyone know how to fix Tails' odd behavior when respawning and landing that causes him to get stuck spinning?

 

(Your second question) What, you mean this?

 

So I just purchased a Sega Ultimate Arcade Handheld by AtGames. I can use an SD card and play any of my favorite games or hacks, but it doesn't have built-in SRAM so it obviously doesn't save anything, even in games like S3K, no progress or anything is saved. I'm already aware that it's an emulator and not actual Genesis hardware.

Anyway, this is probably a dumb question and the answer is probably NO, but I'm no hacker. Is it possible to build a SRAM into a ROM? I know emulators make SRAM files when ROMs tell them to, however, can a ROM be engineered to store and delete its own saves so you don't have to depend on the emulator?

 

I'm gonna go with probably not. I believe the only purpose for the info in a ROM is to be read and stored into wherever the hardware stores said data... whether it be instructions to be carried out, art, sound, etc.

What you are talking about is writing data back to that ROM... That would require the hardware to even be capable OR allowed (programmed to) write data back to the ROM... and that'd probably be a bit of a headache for the designers to do.

So, theoretically, you could have padding space in a ROM that COULD be used as such... and instruct the game to use that data to load a game based on the parameters... but unless the soft/hardware running the game is programmed to write back to the ROM, I'd imagine it ain't happening.

Someone more qualified could clarify... but I believe that's the case here.

EDIT... as far as the ROM itself instructed to write to itself... I believe there are no instructions in 68K ASM that could do that... AGAIN, I could be completely mistaken...

 

Doesn't the unused demo-recording code try to write to ROM? I recall hearing that it tries to overwrite the already existing demo data. From what I heard, you could even modify it to write to SRAM with relatively little difficulty, so I'd assume the methods and use of instructions are similar, but I could be wrong.

On the topic of SRAM, how would I go about using this? I know that you first need to modify the header to "activate" it, but how would I write and read? Would I be right in assuming that it's similar to RAM so I can use the same tricks?

Also, how would I go about adding entries to the Sonic 2 level select? I understand the L&R jump and go-to-level tables, but looking at the code that loads them, I can't see anything that resembles text being loaded.

 

When using SRAM, you need to be aware that you can only use odd addresses, and because of that, everything takes twice as much space as normal: a byte is 2 bytes, a word is 4 bytes, and a long is 8 bytes. When reading/writing word or long values, you must use the movep instruction rather than move.

The level select text is a static plane mapping which can be edited with PlaneED.

 

First of, thank you Clownacy, the fix for Tails you showed me was exactly the fix I was looking for!

Now I just hope I can figure out a fix for Sonic's inital DPLC not loading.

But I've got another issue that I need to ask about; Dose anyone know why Casino Night Zone's boss mapping won't open in SonMapEd? As far as I can -tell-, looking at the file in Hex Workshop, there doesn't seem to be anything wrong with it, and it works fine in-game..

 

Looking into that now. I noticed this when putting together my mappings editor. I thought it was an issue on my end... but I get the same result there too... I'll look into it and get it figured out. I hope.

 

EDIT - My apologies for making this a double post... I meant for this to be an edit.

Ok so I tested this on my own mappings tool... it was exactly I was expecting. The reason for it, is in the game, this is essentially the mappings used for Eggman in CNZ:

Code (Text):

1.  
2.  
3. ; CNZ boss
4. ArtTile_ArtNem_CNZBoss                = $0407
5. ArtTile_ArtNem_CNZBoss_Fudge          = ArtTile_ArtNem_CNZBoss ;- $60 ; Badly reused mappings...
6.  

The second constant is used for art_tile when the object is created. The tile index for the mappings take this -$60 tiles into account. THAT is why when loading it into SME or Triad, or any other similar tool doesn't look right.

Hope this clears it all up.

DOUBLE EDIT: SME doesn't seem to take this particular mapping file at all. +1 for me then.

 

What's the VRAM write address to $4A20? I've used this guide here over and over, yet I can't seem to get it to work. My result is $4A200002, but that's apparently wrong.

And speaking of that, isn't there some small tool that calculates this for me on the fly?

 

I got 4A20 0001... IDK how off you think you were but I believe you got your A14 and A15 mixed up

 

Furthermore, the Sonic 2 disassembly (at least the newer versions) have a function for exactly that purpose.