don't click here

Objects disappear!!

Discussion in 'Engineering & Reverse Engineering' started by Joaki, Aug 23, 2009.

Thread Status:
Not open for further replies.
  1. Aug 23, 2009 #1
    Joaki

    Joaki

    AKA BombJack93 Member
    61
    0
    0
    Nivaria Island, Spain
    Lots.
    I have extended levels in Sonic 1 and I put 500 objects for act (few ones even to be extended), in debug mode I check the act and salt ALL the objects, the problem is that if I take rings, monitors or I destroy enemies a bug appears, making that the majority of items disappears: Rings, monitors, or enemies...
    That reproduces all the objects that I put in debug means that the game is capable of create them, but for some reason (be already organization of the objects for example ghz.bin is not good, or it needs an alternative load, or shared)

    My question is... What solution exists? Does anybody have the same problem?

    Note: Please, don't say that it puts less objects because being extend the game it would stay too empty.
    I also tried the Remember Sprite option in SonED2, but the problem persists. Even I tried with last version of SonED2, no results again.
    Thank you in advance and greetings :)
     
  2. Aug 23, 2009 #2
    FraGag

    FraGag

    Tech Member
    659
    0
    16
    Québec, Canada
    Rings, enemies and monitors store some information in a separate area in RAM to remember their state, which starts at $FC00. The wiki says this area is $180 bytes long, the disassembly on the SVN says it's $200 bytes long... anyway, this means you can only remember the state of so many objects for a level (I don't know how many bytes each object takes though). If you can find some area in RAM that you can free up (for example, if you don't need water, you could remove the underwater palettes), you might be able to enlarge this table and probably change some routine to take the new size and position of the table in account. Each object with the "remember sprite state" flag on is assigned an index in this table, with 0 being reserved for "no assigned slot" - I.e. don't remember state. So in theory, since it's stored in a byte, you could remember the state of at most 255 objects for a level. If you need more than this, you'll have to relocate the index somewhere else in object RAM, which could mean relocating other values to avoid conflicts with existing objects.
     
  3. Aug 25, 2009 #3
    Joaki

    Joaki

    AKA BombJack93 Member
    61
    0
    0
    Nivaria Island, Spain
    Lots.
    Nice idea, but... Someone would know a guide does for these procedures?
    Or any location in asm/hex to change them? Thanks in advance.
     
  4. Aug 25, 2009 #4
    JoseTB

    JoseTB

    Tech Member
    716
    59
    28
    I don't think there's any other free area in the ram of such size, let alone bigger. If anything to relocate that you would have to either put it in the sram or move something else to the sram.
     
  5. Sep 5, 2009 #5
    Eduardo Knuckles

    Eduardo Knuckles

    Not a loved one, but the most hated person. Banned
    414
    10
    18
    Someplace somewhere
    Project S.A.M.G.
    The Jose's problem I'm thinking that aren't on the number of objects added.
    I think his problem is on the object subtypes on some objects using invalid values.
    Per example, if you put a monitor with 25-56, the monitor automatically is destroyed when you reach it (before it appears on the screen), and after the invalid function the monitor art bug a lot and all objects starts to disappear. I know this because I had this problem days ago in my Labyrinth Act 4 after I added a Ring monitor with the subtype 23. I was changed the object subtype for 03. This solved my problem.
     
Thread Status:
Not open for further replies.