Basic Questions and Answers Thread

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

  1. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    I once gave a deeper explanation about the level order question, here's my old post. Please note that for some reason IPB destroyed a lot of things (colons, brackets, ...) in the code box, so good luck reading it.
     
  2. FFuser

    FFuser a.k.a Darklight Member

    Joined:
    Nov 14, 2013
    Messages:
    88
    Thanks guys. It does make a lot more sense explained that way and now knowing the file starts from GHZ2.

    Is the lvl_size.bin file also in the order of stage select like DA Garden listed (e.g. GHZ acts 1-4, then LZ acts 1-4, then MZ 1-4, then SLZ 1-4, then SYZ 1-4, and finally SBZ 1-3)?

    Still trying to decipher what the other bytes are in that file (I'm thinking the first two bytes for each stage is the left boundary since they all start with "00 40")...
     
  3. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    EVERYTHING in Sonic 1 uses the internal zone order (0 = GHZ, 1 = LZ, ...), and yes, ALL zones have 4 acts, it's just that most of them are unused.
     
    Last edited by a moderator: Feb 13, 2014
  4. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    Right, the format appears as so:

    UU UU AA AA BB BB CC CC DD DD VV VV

    Now, the A is the screen's left boundary, while B is the screen's right boundary. C is the screen's top boundary while D is the screen's bottom boundary. V is the camera's position away from Sonic vertically, (i.e. 0060 is the number of pixels the top of the screen hangs away from Sonic).

    U appears to be unused. But it does look like the number of vertical chunks sized within the level. But since no piece of software in the game uses the memory space it is loaded to, it cannot be confirmed.

    Understand though, these are "initial" settings, when the game starts it'll start with these settings, but they can be changed by the game at any time. For example, the V for the camera's position from Sonic, the Sonic object will change that immediately as Sonic has functions for looking up or down, that tamper with that value. Another example is the dynamic screen resizing routines, they may alter any of the values from A to D.
     
  5. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    One thing I noticed is that the two levels which wrap on the Y-axis (LZ3 and SBZ2) have a $FF as the first CC byte, but I'm not sure if that's related in any way.
     
  6. FFuser

    FFuser a.k.a Darklight Member

    Joined:
    Nov 14, 2013
    Messages:
    88
    Can I ask what kind of issues you ran into and if/how you resolved them?

    I made a couple of the unused monitors functional, but as I test the levels I'm changing sometimes, even though they're all set to remember the state, sometimes they either won't appear when I get to them or will be destroyed already. Sometimes the whole level will be perfectly fine, but it does bother me when this happens. I don't want to hide a monitor as a reward for exploring and finding a secret, path but then it's not there and the player feels he got dicked (Knuckles stole it lol).

    It happens with rings sometimes as well. 'Usually happens when I pass by them really fast and come back to that area and a few of them will reappear. The remember state flag for these are also set to true as that's how it is by default in SonLvL. Now I don't know if it's a limit with how many objects are allowed in the level (I try to keep it between 200-370. 308 objects was the highest amount I saw on an unchanged stage), but it feels like other hacks don't have this problem and have a lot of objects in the stages as well.
     
    Last edited by a moderator: Mar 8, 2014
  7. Flamewing

    Flamewing Elite Hacker Member

    Joined:
    Aug 28, 2011
    Messages:
    37
    Location:
    France
    In both S1 and S2, looping levels always have $FF00 as the full CCCC -- this is equal to -$100. It means that the top of the level is a negative number, so the camera continues going up when moving up from 0 ( because it is a signed comparison, and -$100 < 0) before it gets wrapped. Moreover, DDDD is always $800 for wrapping levels for similar reasons -- there is code for wrapping the level when the camera is below that, as well as to keep the camera scrolling down below the bottom of the level.
     
  8. TheInvisibleSun

    TheInvisibleSun Visible Member

    Joined:
    Jul 2, 2013
    Messages:
    424
    Location:
    Western New York, USA
    Can I ask what kind of issues you ran into and if/how you resolved them?

    I made a couple of the unused monitors functional, but as I test the levels I'm changing sometimes, even though they're all set to remember the state, sometimes they either won't appear when I get to them or will be destroyed already. Sometimes the whole level will be perfectly fine, but it does bother me when this happens. I don't want to hide a monitor as a reward for exploring and finding a secret, path but then it's not there and the player feels he got dicked (Knuckles stole it lol).

    It happens with rings sometimes as well. 'Usually happens when I pass by them really fast and come back to that area and a few of them will reappear. The remember state flag for these are also set to true as that's how it is by default in SonLvL. Now I don't know if it's a limit with how many objects are allowed in the level (I try to keep it between 200-370. 308 objects was the highest amount I saw on an unchanged stage), but it feels like other hacks don't have this problem and have a lot of objects in the stages as well.




    Though it has been a rather long time since I solved this issue, I believe it all has to do with the monitor animations or mappings; I had the same issues you describe above. Sorry I can't quite go into too much detail right now, but eventually to add new art, I ended up shuffling around some of the art, mappings and animations around to make it work (for example, the 'R' monitor overwrites the Eggman Art, all of the 'C' monitors overwrite the 'S' art, and the 'Music' Monitor's art took one of the static frames, since there is more than one). 


    What did you do exactly? If you simply enabled the Eggman and Goggles Monitors (assuming this is Sonic 1), then I'm not sure what the problem is. If you followed this guide to add new monitor slots, then the problem may have occurred due to this line in the file '26 Monitor.asm':


    ...
    move.b #9,obAnim(a0) ; set monitor type to broken
    bra.w DisplaySprite
    ...

    The guide calls for that to change, but I left it as-is, and then just left the 9th monitor slot unused, ensuring that the breaking animation was always the 9th down in the animation file. As for the mappings, since I removed one of the static frames, this line :


    move.b #$B,obFrame(a0) ; use broken monitor frame
    rts
    changes to this:



    Code:
    move.b #$A,obFrame(a0) ; use broken monitor frame
    rts 
    because the breaking frame moved to being the $Ath (tenth) one down in the mapping file.

    Sorry for the late reply, I hope this helped.
     
    Last edited by a moderator: Mar 11, 2014
  9. FFuser

    FFuser a.k.a Darklight Member

    Joined:
    Nov 14, 2013
    Messages:
    88
    I didn't really add any brand new monitors. I just made some of the unused ones do something (the eggman and the S monitor) and didn't have to change any mappings or animation for that. I did give Tails a separate file for PLCs so his life icon and extra life monitor would be different. Dunno if that matters.

    The issue didn't come up until I started changing the layouts for the level and doing some test runs through them (it also only happens on certain levels from what I can tell).

    As far as the guide, I've never seen it. It uses a different disassembly, but I looked at it and tried some things with the analogous code in the hivebrain disassembly... it didn't really resolve it, so I reverted it back and will see if there's anything else I could look into to figure this out. Did you only have the issues with the monitors or were there also problems with the rings similar to what I described in my previous post? If you had no issues with rings, then it makes me wonder if it's a limit with the object count, but I don't really know at this point.
     
  10. nineko

    nineko I am the Holy Cat Member

    Joined:
    Mar 24, 2008
    Messages:
    1,902
    Location:
    italy
    I didn't have any issue when I added the new monitors to my hack, and I didn't use that guide at all (if anything, because it didn't even exist yet, not to mention I used a different disassembly), so it's probably something else. Adding monitors is trivial, you can't really fuck that up, right?
     
  11. FFuser

    FFuser a.k.a Darklight Member

    Joined:
    Nov 14, 2013
    Messages:
    88
    Well after testing some more, I don't think it's purely an issue with monitors (their behavior is just the most noticeable to me). Other objects do the disappearing act sometimes as well (like the spikes part of the metal stomping block object in MZ will be gone or sometimes an enemy won't appear where I placed it... but it's rarely noticeable because if you leave the area and come back it'll be there). I'll see what I can do about that later because I'm happy with the object placement for the levels I've changed so far, so if I can resolve that without removing (too many) objects that'll be great.

    I just brought it up to see if anyone else ever had a similar problem so I could track down what's causing it.
     
  12. JoenickROS

    JoenickROS ROS (bug fixing in progress) Member

    Joined:
    Feb 5, 2012
    Messages:
    929
    I've been looking through the S3K asm file in the disassembly. I'm having a bit of trouble finding the art, DPLCs, and Mappings for super sonic. I found the DPLC code line, Plc_supersonic, but I could not find that label in the file, or the s3 lockon file in the disassembly. Also found the mappings code line, but not the actually label it reads to. Separating them like s3 would give me more tile space for normal Sonic, which is why I want to know. Is there another way to find them? The load from rom option in SonmapED is one thing, but to find the actually location, I haven't a clue.
     
    Last edited by a moderator: Mar 11, 2014
  13. Shockwave

    Shockwave 3 Time Stones Member

    Joined:
    Dec 18, 2013
    Messages:
    121
    Location:
    LA, CA
    They're in the mappings/DPLCs files for regular Sonic. Open them in a text editor and you'll see the labels for Super Sonic right below the first index. You'll have to take that and separate it into its own file for editing purposes.
     
  14. RandomAvatarFan

    RandomAvatarFan Well-Known Member Member

    Joined:
    Apr 10, 2009
    Messages:
    100
    I seem to be getting a bias with the RandomNumber function in Sonic 1.  Only four of my six possible events seem to happen, the fourth being extremely rare and the first happening ~ %90 (a number generated being between and included 224-255)  Is there anything I can do to reduce this bias?
     
    Last edited by a moderator: Mar 15, 2014
  15. Flamewing

    Flamewing Elite Hacker Member

    Joined:
    Aug 28, 2011
    Messages:
    37
    Location:
    France
    The "RandomNumber" function is not random at all, like almost all sources of "random" numbers in computers; the more correct name for such functions is "pseudo-random number generator" (PRNG). They basically iterate through a fixed sequence of random numbers starting from a "seed" number. How each sequence is generated depends on the PRNG in question (it can be simple operations like multiplication or division by a constant), but after each number is drawn from the sequence, it will then be used as the seed for the next.

    The Genesis Sonic games are even worse in this regard because they reset the seed to zero at the start of each act. Further, there are very few objects in S1 that actually use the function, so there is a high likelihood that the seed still being zero at the end of any given act.

    One way to get around it is to seed the RNG yourself before getting a random number in one of several ways. A quick and easy one is to seed it with the VBlank run count: just do

    Code:
        move.l   (v_vbla_count).w,(v_random).w
    once before drawing your random numbers (not once before each number, once before the event happens). This method is used by Mecha Sonic in S3&K. Another method used is to check if the low byte of the VBlank run count is in a certain range or not before drawing a random number, or drawing multiple random numbers based on the last low byte of the VBlank run count.
     
    Last edited by a moderator: Mar 15, 2014
  16. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    I'd settle for using the h/v counter as part of the random algorithm. I'm not sure you can get more random than that, especially if reading when the machine is first switched on (For Sonic games, the h/v counter should already be enabled):

    Code:
    		move.w	($C00008).l,d0
     
  17. Flamewing

    Flamewing Elite Hacker Member

    Joined:
    Aug 28, 2011
    Messages:
    37
    Location:
    France
    Yeah, the H/V counters are good candidates; "X-Men 2: The Clone Wars" is one game that uses it (actually, only the H counter) to randomly select characters when needed. The problems when using the H/V counters (and why I didn't suggest them) is that (1) they don't give every possible value for the bytes and (2) constantly reseeding the PRNG (whether using it or the v_vbla_count or anything else) can result in lower quality statistical properties for the generated numbers (i.e., it can bias the outcome in unpredictable ways).

    And some further information, in case anyone is wondering: the resetting of the PRNG seed at the start of each level is for predictability; without this, recording demos of levels can lead to the demos being broken when playing back if the seeds end up different.
     
    Last edited by a moderator: Mar 15, 2014
  18. RandomAvatarFan

    RandomAvatarFan Well-Known Member Member

    Joined:
    Apr 10, 2009
    Messages:
    100
    I found VDP documentation that explained what the H/V counter is, but what exactly is VBlank?  My searches only found posts that say to use it for this and that, but nothing that actually explains what it is or how to access it.  

    What I tried doing was using Markey's suggestion to use the H/V counter to seed the PRNG but followed Flamewing's instructions to do it "once before the event, not the number" 

    There's still a large bias for two events which will end up being annoying to the player, and not all outcomes have appeared yet, and there's also now a small art glitch in the special stage.  If this is all it is, it won't matter since I'm removing access to them anyway, but I'm worried it might be part of a larger problem.

    Finally, what I might do is just change the conditions that each event occur.  Right now, I have these ranges of numbers, and it just checks to see if the PRNG number is within each range.  I could make the events that right now have a large chance of happening into a smaller range, and give larger ranges to the events that don't happen as often.  Or I could even do a more convoluted style of branching off and running the PRNG again. 
     
    Last edited by a moderator: Mar 15, 2014
  19. MarkeyJester

    MarkeyJester ♡ ! Member

    Joined:
    Jun 27, 2009
    Messages:
    2,867
    CRT TV's use a beam of light which starts at the top left of the screen. It scans across displaying a scanline until it reaches the right side. When it has reached the right side, the beam goes off (Blanked), and then moves back to the left side and down one scanline, ready to draw the next line. (Horizontal blanking interval).

    When the beam has drawn all of the scanlines and reaches the bottom of the screen, the beam goes off (blanked), and then moves back to the top and the left side for the next frame to be drawn. (Vertical blanking interval).

    These intervals (H/V-blank) are gaps in the display process. These gaps are useful for transfering graphical data before it is displayed, most Mega Drive games have also been known to use it as a general game timer.

    As for your problem, I believe a contributing factor is down to how you're using the obtained random number, do you have perhaps a snippet of code you could share for clarity's sake?
     
    Last edited by a moderator: Mar 15, 2014
  20. Flamewing

    Flamewing Elite Hacker Member

    Joined:
    Aug 28, 2011
    Messages:
    37
    Location:
    France
    What I said to use was not vblank itself, but the vblank run count which Sonic games maintain -- it is a number that is incremented from zero whenever vblank runs (that is, once per second). You just move it like the code I gave.

    As for VBlank: if you are not interested, you can skip this. Otherwise: at the time when NTSC and PAL were crafted, circuits were slow and unresponsive compared to today's circuits (not to mention larger and more power-hungry); every action took its sweet time to be accomplished. Old TVs were all cathode ray tubes, which means they were enormous; what concerns us here is that it uses an electron beam to render images pixel by pixel, from left to right and from top to bottom.

    As I said, circuits were slow: so at the end of drawing a frame, the electron beam had to be moved back to the top from the bottom for the next frame; this was done by setting the beam to minimum intensity and making the circuits do their work. This process is called "vertical blanking". The time it takes is called "vertical blanking interval" (VBI), "vertical interval" or "vblank" -- but this is not the "vblank" generally meant when that word is used. That distinction is given to what is more properly called the "vertical blanking interrupt" (also called VBI, confusingly) or "vertical interrupt" (V-Int): this is an interrupt generated in the processor to run code when vertical blanking starts. It is also technically incorrect, but that has never stopped anyone from using it. V-Int is always enabled in Sonic games, and in many other games as well.

    The other important thing is that after each line, the electron beam had to be moved back to the left from the right in order to draw the next line; again, this was done by setting the beam to minimum intensity and making the circuits do their job. This process is unsurprisingly called "horizontal blanking"; it is faster and happens much more frequently than vertical blanking, meaning that the "horizontal blanking interval" (sometimes called "hblank") is much smaller than the vertical blanking interval. There is an interrupt associated to it too -- the "horizontal blanking interrupt" (H-Int, sometimes also called hblank) or raster interrupt, which happens can be set to happen at the start of any given line (or at the start of every line). H-Int is generally disabled in Sonic games, the exception being water levels -- it is then set to occur on the line where the water surface is (if it is on screen at all) and it is used to load the water palette to draw the rest of the screen.

    Edit: And Ninja'd by MarkeyJester.

    And he is right, seeing the code in question may help give better ideas.
     
    Last edited by a moderator: Mar 15, 2014