Basic Questions and Answers Thread

Okay I'm not sure how you're getting the subtype defining the ObjectRAM location the Object is loaded in, I've never encountered that in my entirety of object programming. Special Objects such as the Invincibility are force loaded into their Object slots so they are always the same slot when loaded. Has nothing to do with the subtype at all.

 

SingleObjLoad searches the dynamic object RAM area for the first free slot and returns its address in a1. Unless you need the object loaded at a specific address so other code can interact with it, you should be using SingleObjLoad.

 

Wow... This is starting to go over my head. Thanks for trying to help, but I still can't get it to to work. I'll get back to it when I learn more about ASM and the Sonic 1 engine in general.

 

The latest version of Retro Graphics Toolkit now supports resizing the chunks and saving the chunks as sonic 1 format. Just redownload the link is the same. https://github.com/ComputerNerd/Retro-Graphics-Toolkit/blob/master/RetroGraphicsToolkit.exe.7z




I have problems when saving chunks. It saves the chunks, but incorrectly.

 

That is quite strange. I checked my saving code and see no reason why this would happen. Using the version I released most recently v0.611 I loaded green hill zone's chunks and then saved over them. Green hill zone looks exactly the same. I will not disregard the possibility that there is a bug in Retro Graphics Toolkit however I would like more information. What are you using to load these chunks? Can you post code that loads them? What happens when you load the chunks in Retro Graphics Toolkit? I think the issue may be that when you use the import sonic 1 option it sets the width and height to 16 blocks. I will add that feature in the next release which should be coming soon. Also I apologize for forgetting to add an add and delete chunk option. That will also appear in the next version. Speaking of new features the next release of Retro Graphics Toolkit will support undoing and redoing which should make editing easier.

 

Oh, I see. My chunks are 22 blocks (2x2) wide and 23 blocks tall. That's what's happening. Oh well, I'll just stick to reworking the chunks to the way I want them for now.

 

Did you save a project? Project files store the width and height in a file. Don't discard your data this is not an issue of the saving code, the loading code is at fault. I already added the code for the costume size loading I can send you a release if needed. Also when you load the chunks useBlocks is not set. Make sure you enable that.

 

Yes, I have a project file.

Here you go.

Also I did check useBlocks.

 

The project loads just fine for me but as described above if you try and use the import sonic 1 chunks I am able to recreate the bug. However with the new custome size load option it loads just fine. Do you need a new release now (that would contain incomplete but stable undoing code) or can you wait? Sending you a new version would not be a burdan at all.

 

I can wait, I'm not doing the contest anymore. I don't want to release something incomplete after all.

 

How do you fix branch errors when the compiler refuses to tell you which line it's on? I constantly keep running up against two of them, and the compiler just telling me how many bytes away they are in the the ASM, which doesn't help me

 

If you mean the number displayed next to the error description, that's the line it's on.

Otherwise, I honestly have no idea. If I didn't know better, I'd tell you to find every instance of the branch line and replace it with a longer, more stable line, but this isn't applicable in all cases (for example, beq.w would need to become 3 lines and a label, as there is no JEQ in the 68k language by default, though there's a sort of exception to THAT in the S1 HG disasm).

 

bxx.s >> bxx.w >> branch to a jump line

or

bsr.s >> bsr.w >> jsr

 

I'll put it this way

beq.s

I just remove the .s & it works.

bra

change this to jmp

bsr (Branch to SubRoutine)

change to jsr

in the case of the bcc.s KILLSONIC, removing the .s don't work. go below the subroutine with bcc.s KILLSONIC and make the routine KILLSONIC_Jump


KillSonic_Jump: jmp KILLSONIC

then change  the the bcc.s KILLSONIC to bcc.s KILLSONIC_jump

 

This is great, but it doesn't help me find the problematic line itself. I can't fix it if I don't know where it is!

 

Maybe you should post the error log?

 

@Pacguy: I think that you should check this thread.

 

I don't think you guys were really paying much attention at all. He knows how to fix branch errors, the problem is, if the assembler does not specify the location/line in which the branch error is on, then he cannot locate and correct it as easily.

Pacguy: is there a possibillity you could share a screenshot of the console window? Usually the assembler displays two numbers, the first being the line number which is held next to the directory. The second is as you said, the distance the relative address is away from its maximum distance.

That too.

 

I think people overlooked my question by mistake, so I'll re-ask it. I hope that's ok:

I've noticed that the GHZ ball has multiple mappings for it, but only two are used. I can't find where the animation properties for it are (I use the GitHub disassembly), so does anyone know where to adjust the animation to use all mappings?

 

There is no animation file - the sprite change is coded in _incObj/48 Eggman's Swinging Ball.asm by lines with obFrame(a0) and obFrame(a1). I hope that it helps somewhat.