Basic Questions and Answers Thread

Discussion in 'Discussion & Q&A' started by Malevolence, Jul 7, 2009.

  1. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    @Billy:


    I don't think it's about objects, since objects are stored far from this in memory:



    Code:
    $0000 - $7FFF	 Metablock table
    
    $8000 - $8FFF	 Level layout
    
    $9000 - $A9FF	 Block table
    
    $AA00 - $A?FF	 Decompression buffer
    
    $AC00 - $AFFF	 Sprite table input. Intermediate storage for sprite attribute table data destined for $DD00 or $F800.
    
    $B000 - $D5FF	 Object attribute table
    
    $D600 - $D8FF	 Primary collision index
    
    $D900 - $DBFF	 Secondary collision index
    As you can see, the first group in memory are the "metablocks" ie the chunks. I'm pretty sure they're safe here, otherwise the only visible chunk would likely be garbled.


    Then there's the level layout, the problem could be here. Maybe there are too many chunks and one of them overwrites the level layout. Problem: isn't the level layout used for collisions? if so, the collisions should be wrong, but they're right. I could be wrong though. If this is the problem, there may be too many chunks, so if you added new chunks, you may have too many of them.


    If that's the problem, you'll either have to delete some chunks or to load uncompressed chunks from the rom rather than decompressing them into the ram. Like this: http://info.sonicretro.org/SCHG_How-to:Loa..._ROM_in_Sonic_1 but you'll have to adapt the solution to work with S2.
     
  2. D.A. Garden

    D.A. Garden Sonic CD's Sound Test Member

    Joined:
    Aug 6, 2009
    Messages:
    582
    Location:
    England
    Billy, the problem is very most likely too many rings in the act. If you have over 255 rings in an act of Sonic 2, the ring data spills over into areas it shouldn't causing all manner of problems. I can attest to this problem happening quite frequently back in my days of Sonic 2 editing a few years back. If, of course, it's not the rings then I apologise because I really wouldn't know what else would be causing it.
     
  3. egdelous2

    egdelous2 Newcomer Member

    Joined:
    Nov 3, 2010
    Messages:
    11
  4. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    Not sure that's what's happening, but I think in the original mapping and DPLC files, there were labels at the beginning of the file (MapSuperSonic: and PLCSuperSonic: ), and when you saved, sonmaped replaced them with random labels.


    The solution should be to add those labels before the "include" for those files (eg: MapSuperSonic: include "whateverthenameofthefile.asm") rather than directly including the files.
     
  5. egdelous2

    egdelous2 Newcomer Member

    Joined:
    Nov 3, 2010
    Messages:
    11
    I caught the disassembly S3K text format and I have copied the entire map of sonic and supersonic in a new file.


    and the same with the sonic and supersonic plc.


    and now this appears in the window.


    http://img43.imageshack.us/i/error2aj.png/
     
  6. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    The error message says "symbol undefined PLC_SuperSonic", so there should be a "PLC_SuperSonic:" somewhere but it isn't there. As I wrote before, just add that "PLC_SuperSonic:" before the include for the plc file and you should be fine.
     
  7. egdelous2

    egdelous2 Newcomer Member

    Joined:
    Nov 3, 2010
    Messages:
    11
    lI'm sorry but I do not understand what you mean.


    Can you explain me better?


    please my friend.


    thank you very much
     
  8. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    Forget it, I thought supersonic had it own plc file, but it's in the same file as Sonic's PLC.


    I checked the disassembly and here's what's exactly the problem: there is a file, "sonic pattern load cues.asm", that file unfortunately contains both PLC_Sonic and PLC_SuperSonic. You'll have the exact same problem with mappings.


    PLC_Sonic is written before the include as you can see:



    PLC_Sonic: include "General\Sprites\Sonic\Sonic pattern load cues.asm"



    That's why there's no problem with that one.


    The problem comes from the fact "PLC_SuperSonic:" is written inside that asm file, and when you save in sonmaped, the program probably removes that "PLC_SuperSonic:".


    Open the file "Sonic pattern load cues.asm" and add the "PLC_SuperSonic:" where it's meant to be (you'll have to do this every time you save in sonmaped), it should be around the 252th line, if sonmaped didn't remove them :/


    If sonmaped didn't remove them, you should have around 504 line looking like "dc.w word_147BC8-Map_146816" (with different numbers). In that case, simply find in the list the second reference to the first line after that list:




    dc.w word_147C50-Map_146816


    dc.w word_147C64-Map_146816


    dc.w word_147C72-Map_146816


    ; << THIS IS THE END OF THE LIST


    word_146A0C: dc.w 0 ; << THIS "word_146A0C" IS WHAT YOU HAVE TO FIND


    word_146A0E: dc.w 3


    dc.b $EC, $D, 0, 0, $FF, $EC


    dc.b $FC, 6, 0, 8, 0, 4


    dc.b $FC, $A, 0, $E, $FF, $EC



    The first "word_146A0C" is on the first line and the 252th in the original file, so you have to find the second (which is in the middle of the list).


    If sonmaped removed them (the list is about 250 lines long), you'll have to make two separate PLC and Mapping files for Sonic and Super Sonic, and make changes for newly added sprites the same way for each one and save them separately, and of course add a line in the disassembly to include those new PLC and mappings. It won't be optimized for size, but it should be easier.
     
    Last edited by a moderator: Apr 13, 2011
  9. egdelous2

    egdelous2 Newcomer Member

    Joined:
    Nov 3, 2010
    Messages:
    11
    thannnnnnnnksssssss


    your are the best, my frieeeeend


    thank you so much!!!!!!!!
     
  10. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    I noticed this problem for the second time:


    [​IMG]


    This is in the first special stage, entering from the end of Spring Yard act 2. I've never seen it under other circumstances.


    It disappeared after a few seconds, and reappeared.


    I had found an explanation for something similar on retro long ago, it was about dynamic resizing routines and boss mappings being loaded or something like that. Anyway the solution was to skip the dynamic resizing while in special stage, which is already in my code. As you can see, the problem is still there, and I really can't find what's happening. :/


    Any idea?


    (note: of course I can't manage to reproduce it. Like every respectable bug, this one won't show its face if one tries to find it)
     
    Last edited by a moderator: Apr 26, 2011
  11. FireRat

    FireRat Do Not Interact With This User, Anywhere!!! Exiled

    Joined:
    Oct 31, 2009
    Messages:
    535
    SpirituInsanum: I see that graphic error is in the Plane A, right? well, I think, the problem is just that the previous level layout is not correctly unloaded...


    Well, do you know the S tube in GHZ, right? and do you know how the collision reacts different on that chunks, right? Well, Deox explained me that Roll reaction is defined somewhere, and that code have a index of what Chunk's ID will react with a roll. Well, where's that index?
     
    Last edited by a moderator: Apr 30, 2011
  12. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    That could explain it, I'll have to look into this. Thanks.


    The index you're looking for is right under the start location array, "LoopTileNums" in Hivebrain's disassembly.
     
  13. FireRat

    FireRat Do Not Interact With This User, Anywhere!!! Exiled

    Joined:
    Oct 31, 2009
    Messages:
    535
    Thanks...


    And well, if unloading the layout is not sufficient, probably you will need unload the blocks and the chunks too...
     
  14. PsychoSk8r

    PsychoSk8r HighKnights Member

    Joined:
    Aug 9, 2007
    Messages:
    271
    Location:
    Birmingham, UK
    Question:


    In Sonic 1, is there a way via ASM to check the 3rd variable in the object type? I know the 2nd variable (sub-object type) is $28(a0), but what's the third?
     
  15. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    As far as I know, there's no such thing as a 3rd variable. Here's the object loading routine with comments on relevant points:




    OPL_MakeItem:


    bsr.w SingleObjLoad


    bne.s locret_DA8A


    move.w (a0)+,8(a1) ; x position


    move.w (a0)+,d0


    move.w d0,d1


    andi.w #$FFF,d0


    move.w d0,$C(a1) ; y position


    rol.w #2,d1


    andi.b #3,d1


    move.b d1,1(a1) ; render bitflag (for mirrors)


    move.b d1,$22(a1) ; status bitfield (for mirrors as well)


    move.b (a0)+,d0


    bpl.s loc_DA80


    andi.b #$7F,d0


    move.b d2,$23(a1) ; respawn index reference number (for destroyable objects)


    loc_DA80:


    move.b d0,0(a1) ; object's ID


    move.b (a0)+,$28(a1) ; object subtype


    moveq #0,d0


    locret_DA8A:


    rts



    There's nothing else. Or maybe I misunderstood your question? :/


    Sometimes, the object's code will create a different object depending on the zone number, but there's no variable for it.
     
    Last edited by a moderator: May 3, 2011
  16. PsychoSk8r

    PsychoSk8r HighKnights Member

    Joined:
    Aug 9, 2007
    Messages:
    271
    Location:
    Birmingham, UK
    Ah, OK then.


    I was referring to what appears to be a 3rd variable in SonED2. =P
     
  17. SpirituInsanum

    SpirituInsanum Well-Known Member Member

    Joined:
    Feb 11, 2010
    Messages:
    642
    That's probably the draw direction (mirrors), in Soned2 you can read three bytes on the line "Object Type ID": TT BB DD, where TT is the object type (in 0(a0), changed with AZ), BB it the bitfield (aka subtype, in $28(a0) changed with SX) and DD is the draw direction (mirrors changed with DC).


    The draw direction only uses half of the byte, so it should be possible to use the other half if you need it (you'd only have to modify a bit that subroutine above to load it somewhere in the object's ram), but I think it can't be edited in Soned2 (or at least not by default), so it may not be convenient. Used for Y position, indeed.
     
    Last edited by a moderator: May 3, 2011
  18. MainMemory

    MainMemory Well-Known Member Member

    Joined:
    Mar 29, 2011
    Messages:
    922
    The draw direction uses half of a nybble, the other nybble is part of the Y position (see here for details).
     
  19. FireRat

    FireRat Do Not Interact With This User, Anywhere!!! Exiled

    Joined:
    Oct 31, 2009
    Messages:
    535
    Hi guys. Well, I tried to do an effect in my main menu, fading the palettes. The code is this:




    jsr Pal_FadeFrom


    move.l #$40000003,d5


    lea (MenuScreen_ASCII_SelChar),a1


    move.w #$6580,d3


    jsr LoadASCII


    jsr Pal_FadeTo


    rts



    But, when I try that, after the image reappear, the game crashes. Why is that crash caused?


    (Note: That code is from an object. Obj8E)
     
  20. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Routines "Pal_FadeFrom" and "Pal_FadeTo" were not designed initally to work during the object's routines, and because of the nature of the game mode, it's not recommended either as the other routines within the game's loop will not be called before the end of the frame.


    The crashing itself of course: The object engine keeps the object's ram address stored in a0, and after an object is finished, it's increased by 40 (advancing to the next object), that's what's suppose to happen, but "Pal_FadeFrom" and "Pal_FadeTo" overwrite the address of a0 as it uses it to maintain control over the palette's fading.


    Possible solutions are:

    • Store a0 away somewhere (a ram location, another register that isn't used by "Pal_FadeFrom" and "Pal_FadeTo", or to the stack)
    • Call the fading routines at the end of the main loop itself (just before the call to "DelayProgram" waits for V-Blank), insted of in the middle of an object's routine.