don't click here

Basic Questions & Answers thread

Discussion in 'Engineering & Reverse Engineering' started by Tweaker, May 29, 2008.

  1. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,651
    218
    43
    SonLVL
    Open a PVM in PVMEditSharp, go to Export Texture Pack, navigate to your mod's folder, create a Textures folder inside it, then select the Textures folder and hit OK.
     
  2. Satchel

    Satchel

    Member
    4
    0
    0
    Hi! I could use some help.

    I have two issues. (Sonic the Hedgehog 1) I'm following the guides on how to set up disassembly and whatnot, and I get to the editing art part. The problem is, I can't find artnem_u in the disassembly (git). I can in the Hivebrain one, but then when going to the next part (editing levels) It tells me to attempt to edit mz1, but when I build, the level has no background and the entire layout is glitched. What disassembly should I use, and how do I fix these issues?
     
  3. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,651
    218
    43
    SonLVL
    In the GitHub disassembly, you have to decompress and recompress the files yourself, with a tool such as KENSSharp or FW-KENSC, whose Windows shell extensions I've linked. As for the level issue, I can't say, as I don't know which disassembly you're using, or what tool you're using, or what steps you're taking to edit, save, and build.
     
  4. Satchel

    Satchel

    Member
    4
    0
    0
    I apologize for being so vague!

    I used the Hivebrain disassembly, alongside SonED2, and I've been following the guides posted on the INFO section of SonicRetro. They've been giving me step by step, which was working perfectly until the issue I mentioned. But now taht I know that I need to compress/decompress myself, I should be able to fix.
     
  5. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,384
    114
    43

    512x1024
     
  6. DetoNtn

    DetoNtn

    Layout Master Member
    I think I might need some help, as I'm cruddy when it comes to Sonic ASM's.

    I'm trying to add Special Stage Monitors, like Sonic Triple Trouble. I've used the instructions from Tamkis on how to do it , but in my s2.log, I have 2 errors:

    Code (Text):
    1. > > >s2.asm(23883): error: short addressing not allowed
    2. > > >   move.b  #1,(unk_F7CD).w
    3. > > >s2.asm(23883): error: addressing mode not allowed here
    4. > > >   move.b  #1,(unk_F7CD).w
    and this is where the error occured:

    Code (Text):
    1. loc_12AA6:
    2. teleport_monitor:
    3.     ;** SS monitor
    4.     cmpi.b  #7,(Emerald_count).w        ;Does main character have all 7 emeralds?
    5.     bne.s   warp_toSS           ;If not, branch to goto Special Stage
    6.     jsr super_ring          ;give 10 rings
    7.     jsr super_ring
    8.     jsr super_ring
    9.     jsr super_ring
    10.     jsr super_ring          ;=total of 10 ring
    11.  
    12. warp_toSS:
    13.     move.b  #1,(unk_F7CD).w
    14.     move.b  #GameModeID_SpecialStage,(Game_Mode).w ; => SpecialStage
    15.     rts;
    What does it mean by "short addressing not allowed" and "addressing mode not allowed here"? Did I misplace the "warp_toSS" function? Thanks in advance.
     
  7. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,651
    218
    43
    SonLVL
    Does the label "unk_F7CD" even exist? In the GitHub disassembly, it's now called "SpecialStage_flag_2P". Though if that is the case, it should be showing "error: symbol undefined", not "error: short addressing not allowed".
     
  8. DetoNtn

    DetoNtn

    Layout Master Member
    I'm pretty confused too. I'll substitute "unk_F7CD" with the "SpecialStage_flag_2P" and see if i get anything.


    EDIT: I swapped the "unk_F7CD" with the "SpecialStage_flag_2P" and got 3 more errors:

    Code (Text):
    1. > > >s2.asm(41137): error: symbol undefined
    2. > > > return_1F220
    3. > > >   bhs.w   return_1F220
    4. > > >s2.asm(41142): error: symbol undefined
    5. > > > return_1F220
    6. > > >   bhs.w   return_1F220
    7. > > >s2.asm(41146): error: symbol undefined
    8. > > > loc_1F206
    9. > > >   bne.s   loc_1F206
    10. > > >s2.asm(51995): error: addressing mode not allowed on 68000
    11. > > >   lea Obj70_Positions(pc,d1.w),a1
    12. > > >s2.asm(51995): error: addressing mode not allowed here
    13. > > >   lea Obj70_Positions(pc,d1.w),a1
    14.  
    now it shows that addressing mode isn't allowed in a totally different spot, and the "symbol undefined" error is showing up now. Is there a different function I can use to get the same effect, or do I need to replace some more terms?
     
  9. MainMemory

    MainMemory

    Kate the Wolf Tech Member
    4,651
    218
    43
    SonLVL
    The last two errors are just the assembler getting confused, they'll go away if you fix the other errors. The "symbol undefined" errors there, are all labels that definitely exist in my copy of the disassembly, perhaps you deleted or renamed them? They should be under Obj79_CheckActivation as part of the checkpoint object.
     
  10. DetoNtn

    DetoNtn

    Layout Master Member
    The "symbol undefined" terms, "return_1F220" and "loc_1F206", are definitely there under Obj79_CheckActivation:

    Code (Text):
    1. loc_1F154:
    2. Obj79_CheckActivation:
    3.    
    4.     move.b  subtype(a0),d2
    5.     andi.b  #$7F,d2
    6.     cmp.b   d2,d1
    7.     bhs.w   loc_1F222
    8.     move.w  x_pos(a3),d0
    9.     sub.w   x_pos(a0),d0
    10.     addi.w  #8,d0
    11.     cmpi.w  #$10,d0
    12.     bhs.w   return_1F220
    13.     move.w  y_pos(a3),d0
    14.     sub.w   y_pos(a0),d0
    15.     addi.w  #$40,d0
    16.     cmpi.w  #$68,d0
    17.     bhs.w   return_1F220
    18.     move.w  #SndID_Checkpoint,d0 ; checkpoint ding-dong sound
    19.     jsr (PlaySound).l
    20.     jsr (SingleObjLoad).l
    21.     bne.s   loc_1F206
    22.     _move.b #ObjID_Starpost,id(a1) ; load obj79
    23.     move.b  #6,routine(a1) ; => Obj79_Dongle
    24.     move.w  x_pos(a0),objoff_30(a1)
    25.     move.w  y_pos(a0),objoff_32(a1)
    26.     subi.w  #$14,objoff_32(a1)
    27.     move.l  mappings(a0),mappings(a1)
    28.     move.w  art_tile(a0),art_tile(a1)
    29.     move.b  #4,render_flags(a1)
    30.     move.b  #8,width_pixels(a1)
    31.     move.b  #4,priority(a1)
    32.     move.b  #2,mapping_frame(a1)
    33.     move.w  #$20,objoff_36(a1)
    34.     move.w  a0,parent(a1)
    35.     ;tst.w  (Two_player_mode).w
    36.     ;bne.s  loc_1F206
    37.     ;cmpi.b #7,(Emerald_count).w
    38.     ;beq.s  loc_1F206
    39.     ;cmpi.w #50,(Ring_count).w
    40.     ;blo.s  loc_1F206
    41.     ;** bsr.w   Obj79_MakeSpecialStars
    42.  
    43.         rts;
    ... Very strange.
     
  11. DigitalDuck

    DigitalDuck

    Arriving four years late. Member
    5,179
    300
    63
    Lincs, UK
    TurBoa, S1RL
    Er... where?

    I see the branches, but no labels.
     
  12. DetoNtn

    DetoNtn

    Layout Master Member
    oops I'll label them with some numbers

    Code (Text):
    1. loc_1F154:
    2. Obj79_CheckActivation:
    3.    
    4.     move.b  subtype(a0),d2
    5.     andi.b  #$7F,d2
    6.     cmp.b   d2,d1
    7.     bhs.w   loc_1F222
    8.     move.w  x_pos(a3),d0
    9.     sub.w   x_pos(a0),d0
    10.     addi.w  #8,d0
    11.     cmpi.w  #$10,d0
    12.     1  bhs.w    return_1F220
    13.     move.w  y_pos(a3),d0
    14.     sub.w   y_pos(a0),d0
    15.     addi.w  #$40,d0
    16.     cmpi.w  #$68,d0
    17.     2   bhs.w   return_1F220
    18.     move.w  #SndID_Checkpoint,d0 ; checkpoint ding-dong sound
    19.     jsr (PlaySound).l
    20.     jsr (SingleObjLoad).l
    21.     bne.s   loc_1F206
    22.     _move.b #ObjID_Starpost,id(a1) ; load obj79
    23.     move.b  #6,routine(a1) ; => Obj79_Dongle
    24.     move.w  x_pos(a0),objoff_30(a1)
    25.     move.w  y_pos(a0),objoff_32(a1)
    26.     subi.w  #$14,objoff_32(a1)
    27.     move.l  mappings(a0),mappings(a1)
    28.     move.w  art_tile(a0),art_tile(a1)
    29.     move.b  #4,render_flags(a1)
    30.     move.b  #8,width_pixels(a1)
    31.     move.b  #4,priority(a1)
    32.     move.b  #2,mapping_frame(a1)
    33.     move.w  #$20,objoff_36(a1)
    34.     move.w  a0,parent(a1)
    35.     ;tst.w  (Two_player_mode).w
    36.     3  ;bne.s   loc_1F206
    37.     ;cmpi.b #7,(Emerald_count).w
    38.     ;beq.s  loc_1F206
    39.     ;cmpi.w #50,(Ring_count).w
    40.     4  ;blo.s   loc_1F206
    41.     ;** bsr.w   Obj79_MakeSpecialStars
    42.  
    43.         rts;
    Obviously the numbers aren't part of the ASM, they're just there to label. Those are the undefined symbols MainMemory said were definitely part of his disassembly.
     
  13. DigitalDuck

    DigitalDuck

    Arriving four years late. Member
    5,179
    300
    63
    Lincs, UK
    TurBoa, S1RL
    Those are branches. Labels look like this:

    Code (Text):
    1. return_1F220:
    Those two lines at the top are labels. You have a branch, but you're not telling the code where to branch to.
     
  14. DetoNtn

    DetoNtn

    Layout Master Member
    Oh, I'm stupid! Thanks, man! You're a lifesaver!

    EDIT: Should I branch to teleport_monitor function or warp_toSS function?
    EDIT: I'm pretty sure I got it to assemble. Thanks!
     
  15. The Prof

    The Prof

    The Island Professor Member
    107
    0
    16
    Orkney, Scotland
    Sonic 1 Yarmar Edition
    I found another weird bug in my Sonic 1 hack. I recently added some art for the end sequence for my alternate character. While testing it I discovered that on the good ending, the Chaos emeralds are not appearing for either character.

    I compared my code for the sonic end object, emerald end object, and ending sequence game mode to a working Sonic 1 disassembly to check I didn't change something important by accident, and apart from a couple of character flag checks, the code is identical. I used the debug features of Exodus and found that the instruction to load the emerald object is being executed, but nothing happens.

    Does anyone have any clue what might be happening here? I normally have some idea of where to start, but I'm totally baffled this time.

    EDIT: Solved it. Turns out that in adding a new object for the alternate character in the ending, I'd misplaced a pointer. Stupid, but apparently easy to miss.
     
  16. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,384
    114
    43
    So I'm building an object handler for my engine, which will roughly be the equivalent of the SST in the classic engines, and I have a few high level questions about how loading objects into memory works.

    Firstly, where are object definitions per stage stored? Are they stored with chunk definitions, or is there a separate table? I.E. say I place a badnik on the second chunk at the beginning of a stage, where is the placement for that badnik stored?

    Sonic 2 loads all objects within a Y-range into memory, correct? While Sonic 3 takes into account a Y-range and X-range as well? My idea is to load objects depending on which chunks are around the player, but I'm not sure if that's how it's done in the classic engines.

    Speaking of loading objects into the SST, are they added into the first open slot? Or is there a more specific way they are loaded into object ram?
     
  17. Fred

    Fred

    Taking a break Oldbie
    1,563
    116
    43
    Portugal
    Sonic 3 Unlocked
    They're completely separate mechanisms. Chunks are on a grid, so all you have to do is add/subtract either 1 to move horizontally, or the overall row size to move vertically. Objects can be placed freely so you have to iterate through the object layout until you find one which is out of range. (Objects are ordered by X position so once you find one that's too far away, you know all the others past that are also too far away.)

    Sonic 3 also considers the Y position of the object before electing to spawn it. Although, I think there's an object flag to suppress it; after all, you still need to go and check the X coord of the next object. Admittedly I don't know enough offhand to answer this and the next question properly.
     
  18. MarkeyJester

    MarkeyJester

    Time to Grow Up. Resident Jester
    2,127
    253
    63
    Japan
    Right, as Neo said, the object's placement is not stored in with the chunks, instead they are all stored in a single separate list, it's what's called an "object position list". This list will hold a few basic values including: the object ID (object to load), X position in the level, Y position in the level, subtype (for different variences of the same object. e.g. springs can be yellow/red upwards/sideways), whether it's flipped and/or mirrored, and finally, whether or not it should store its status to a "destoryed/collected" list (for example, a badnik destroyed needs to not-respawn).

    As for loading objects depending on which chunks are around the screen, that is technically already done in Sonic games, for example, in Sonic 1-3, objects are loaded outside of the screen by $80 pixels minimum from the screen (basically, a 128x128 chunks worth), with Sonic 3 including the Y position to save on CPU time. While objects themselves have no relations to the chunks (they are a completely separate system), they load at a nice round 80. They didn't decide on 80 because of the chunk size, as 80 was decided as far back as Sonic 1 when the chunk sizes were 256x256, it was likely chosen as it's a reasonable balance between loading them off screen enough, and not loading too many far away for the CPU to not be able to handle.

    As for loading objects, they generally are loaded to the first available slot in the dynamic object ram list, the first free slot it can find.
     
  19. Cooljerk

    Cooljerk

    NotEqual Tech, Inc - VR & Game Dev Oldbie
    4,384
    114
    43
    Appreciate the responses!
     
  20. Fred

    Fred

    Taking a break Oldbie
    1,563
    116
    43
    Portugal
    Sonic 3 Unlocked
    Some more musings on the Sonic 3 object manager, since I couldn't figure out a better place to post them.

    Since the Y coord culling was added on top of the existing S1/S2 system, you have to move horizontally in order to (re)load new objects. This is fair, since we're used to walking off and then coming back to get blocks back where they were, etc. You would think that since the game delays spawning objects until you're close enough to them vertically, it would discard them if you moved away from them vertically as well. See the hole in that logic, though? Since objects are loaded by moving horizontally, and merely delayed from spawning until you move vertically, if objects deleted themselves when you moved away from them vertically, then they would mysteriously stay gone until you also moved away horizontally and then came back.

    In fact, that's exactly what Special Stage rings do. This is what accounts for that weird second ring in AIZ1, where if you go right through the cork block rather than bumping into the ceiling, the ring just vanishes. It was probably done so the game can load back the explosion art sooner; there are places where you can fall from a ring room straight to some monitors at least.