Basic Questions and Answers Thread

So, I'm trying to change the HUD mappings so the score part instead reads as a much longer word. It looks fine in SonMapEd, and I gave enough room for the numbers to appear, so I build and run. The only issue is, the last three letters are covered up by the "E" from the score (which never showed up in SonMapEd) and 2 blank spaces; the one letter after displays just fine. How would I remove this oddly forced segment of the Score heading?

EDIT: On a related note, how would I remove the 0 from the end of the score count? I've skimmed over the code in HUD_Score, and I can't quite figure it out; none of it is documented, and it uses commands I'm unfamiliar with.

 

The 'E' in 'SCORE' is uncompressed and included with the HUD numbers and the colon, so it isn't loaded with the rest of the HUD art. I assume you've added more art, so what's happening is that the Nemesis Art for the HUD is loaded fine, but the uncompressed art is loaded where there USED to be blank space.


Here in stock S1's VRAM, we can very clearly see the uncompressed E, along with some blank space. This explains why some of your art is covered by the E, some of it not.

So, basically, it's just a VRAM space problem. You can easily shift the Nemesis HUD art around in VRAM, but keep in mind that this is going to mess up the mappings big time. (Because the HUD art is in different pieces, its mapped around where certain art is loaded in VRAM) You'll have to adjust the mappings accordingly.

 

That's weird... You'd think they could just reuse the "E" already loaded into VRAM by the nemesis art itself :I

Where is this art loaded up? I can't find any suspicious looking files in the nemesis or uncompressed art folders, and I can't see anything relevant to this in the art load cues either. I'd rather just remove the extra e and blank spaces from the art and then shift the art up in VRAM to compensate for the lost tiles (and subsequently make room for my own).

 

The uncompressed art is loaded in this chunk of Hud_Base.

Code:

Hud_Base:         ; XREF: Level; SS_EndLoop; EndingSequence
     lea   ($C00000).l,a6
     bsr.w   Hud_Lives
     move.l   #$5C400003,($C00004).l ; <--- sets the VDP to write to VRAM at DC40
     lea   Hud_TilesBase(pc),a2
     move.w   #$E,d2

loc_1C83E:         ; XREF: Hud_LoadZero
     lea   Art_Hud(pc),a1 ; <--- the uncompressed HUD art
...

and then the Nemesis HUD art is in the Pattern Load Cues under PLC_Main.

Code:

    dc.l Nem_Hud     ; HUD
     dc.w $D940

There actually aren't any blank tiles in the uncompressed art itself. The art is uncompressed because it gets split up, and the numbers themselves are loaded as they appear on the screen. You'll notice in the VRAM capture I posted before that the time is visibly 0:09, I have no score, and I have no rings. Also, as I've said before, it isn't as simple as just shifting the art around. The HUD mappings themselves are SPECIFICALLY mapped for where the different pieces of HUD art are loaded in VRAM in stock S1. Moving the art around is going to screw up the HUD badly, for which you will need to readjust.

 

Skipping that segment of code made everything work perfectly! Now I guess I can just add the colons by hand. Also, that code also dealt with the "0" that was appended to the score, so it solved 2 big problems for me! Thank you so much!

EDIT: It didn't seem to mess with the time and ring counters like you suggested it would. However, I'm working with Sonic 2, not the first one, so it's possible that they changed how that system worked.

EDIT 2: After noting some bugs caused by the absence of said code, I examined it further and found out where it actually mapped out the placement of the characters. Now I can just add my new characters naturally into the code. Thanks again for your help :3

 

In KEH, I replaced the setup array with a string, like so:

Code:

    charset    ' ',$FF
    charset    '0',0
    charset    '1',2
    charset    '2',4
    charset    '3',6
    charset    '4',8
    charset    '5',$A
    charset    '6',$C
    charset    '7',$E
    charset    '8',$10
    charset    '9',$12
    charset    ':',$14
    charset    'E',$16

Hud_TilesBase:
    dc.b "E      0"
    dc.b " 0:00"
Hud_TilesZero:
    dc.b "  0"
Hud_TilesBase_End
    charset

Edit: Apparently I did in fact push that change back to the disasm, so you may have it already.

 

I saw that while searching through the GitHub disassembly for clues; it was extremely helpful, and gave me the info I needed to finish the job. Thanks :3

 

I'm working on the Sonic 2 Telephone Hack and have installed vladikcomper's error handler. I keep getting errors in the middle of Chemical Plant and Metropolis for some reason but, because the disassembly uses the AS assembler, the labels for where the error is occurring are in hexidecimal so I can't figure out where the error is. Using Regen's debugger hasn't been much help. How can I find where the error is occurring in the code?

 

s2.lst lists all the code in the hack, and each label and instruction's location in hex. Simply search for the hex value, and you should find the code it points to.

 

I really do not get why the concept of the listings file is a difficult one to people. I would think if you have any decent experience in assembly programming and have the basic understanding of how offsets work, the listings file should be a self-explanatory thing. Yet many people are all confused when I ask anything regarding the listings file. Listing files usually tell what the assembler is thinking and doing, and where it is putting the code, what equates are what, and one of the most important thing; show what happens inside a macro. The listings file is the most useful debugging item you will ever use as an assembly programmer. And indeed, the most reliable one. No emulator incompatibility, no quirks, just pure and raw assembly. Do yourself a favour and really study what the listings file does and can be used for.

 

Anyone know how I can add another counter?
For it to read as
Scor - Score
Time
Rings (to be changed to hearts, but as double digit, 99 max. Simple task)
Energ - Energy xx
I tried in SomMapEd, but I think I took from rings maps cause it went up with it.

 

You would need to find a free VRAM slot (universally available; that is, in every zone), where you can insert your new counter's text as well as the numbers themselves. Within your code you would then need to create the logic for your counter, which you could easily copy from Rings in your case. All that is then left to do is to make room for a RAM address that stores your "energy" or whatever this idea is supposed to look like in the end.

I honestly don't know what you tried to do in SonMapEd, but I recommend you do it by hand anyway. HUD is one of the few things that don't really make any sense within that editor.

If I were to do it, however, I would make it bloody simple and simply overwrite the Score counter with this energy thing. In my opinion, cluttering up the HUD with too much information serves no purpose, and Score has always been useless apart from getting 1-Ups anyway.

 

tried this with a free ram offset, as well as copying & changing code...

Code:

Hud_Energy: ; XREF: HudUpdate
 lea (Hud_10).l,a2
 moveq #3,d6
 bra.s Hud_LoadArt

Code:

location_1C6E4:
 clr.b (ShieldCheck).w
 move.l #$5FC00003,d0 ; set VRAM address
 moveq #0,d1
 move.w (Shield).w,d1 ; load number of rings
 bsr.w Hud_Energy

nothing shown...

...so I went to SonMapEd again, copied from "Rings" & that did no good either, but only a second ring (or in this case, Heart) Counter.

I may do it, changing some HUD art.

 

So I've recently been trying to set up a dissasembly for SonicLVL and I followed the guide on SonicRetro and the dissasembly is still not working. It's saying you might not set your dissasembly correctly. Is there anyway I can fix that or is there any SonLVL that already comes with a dissasembly?

 

Either you done something incorrectly, or you have not split the binary files. Unless you try s1 on *nix, as some files use an incorrect ' ... ' path. Not sure the exact file, but it had to do with the generics. You can fix that easily

 

It would help some if you told us what disassembly you are using.

 

Okay sorry about that. By the way I was using the Sonic 1 2005 dissasembly. Yeah I know it's outdated but I was using it because it was the exact same dissasembly they where using in the guide on SonicRetro.

 

If you want to be lazy, you could use the Github version that comes with SonLVL .ini files in their own little folder. Otherwise, I'd recommend starting from step 1, and following the guide to the letter.

 

I'm following the guide on how to add the Spindash to Sonic 1. It's working fine for the most part, but whenever I try to pad sonic.bin, its file size doesn't increase. Is this just because of stupidity on my part or something else?

 

The guide suggests creating a batch file and placing the arguements:

Code:

fsutil file createnew padding.bin 16384
ren sonic.bin sonic_old.bin
copy /b sonic_old.bin+padding.bin sonic.bin

I'm going to cover all grounds by pretending that you are an idiot (this is so that any real idiots out there can be referred to this post, it does not imply that I think you are an idiot).

Basically, you open up "Notepad", put in:

Code:

fsutil file createnew padding.bin 16384
ren sonic.bin sonic_old.bin
copy /b sonic_old.bin+padding.bin sonic.bin

...and then save it as "Pad.bat" (it MUST have the ".bat" on the end as the file extension, or else Windows will not recognise it as a batch file. When done, the batch file can be ran by double clicking on the file.

"sonic.bin" (the Sonic art file) must be in the same directory (same folder location) as your newly created "Pad.bat".

(Whether or not this works is unknown to me, but I cannot see it being on the guide if it didn't work).

If you want my advice, I would strongly suggest getting yourself a hexadecimal editor. It can be used for padding the art file out, by opening the file, and inserting extra bytes onto the end of the file ($20 bytes per tile). The hexadecimal editor is far more useful than this however, which is why I strongly suggest getting one.