Basic Questions & Answers thread

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

  1. KingofHarts

    KingofHarts

    Member
    1,619
    0
    16
    Project Sonic 8x16
    Are you saying that editing objects and rings using SonED2 isn't saving? What exactly are you doing and what happens? Have you considered switching over to SonLVL? SonEd2 is kinda obsolete. MainMemory likely has INI's available for this disasm, and even if not, IIRC there is an app w/ SonLvl that can convert the SonEd2 project files to workable INIs.
     
  2. CodenameOmega

    CodenameOmega

    20
    0
    1
    Blaster The Hedgehog
    I greatly apologise for even more bother, but I have hit a road block yet again. I am trying to port the Sonic 1 invincibility theme to Sonic 2 Beta (Using Music Pointer Fixer 1.0.0.1) to take the slot of the beta's invincibility theme. When I test it, it's either silence or a buzzing noise. What can I do?
     
  3. InvisibleUp

    InvisibleUp

    friendly internet ghost Member
    126
    8
    18
    Mind if I ask if there's a good reason you're hacking the Wai beta instead of the release version of Sonic 2? The Wai proto is, well, a prototype, and the engine is buggy and unfinished. Plus, the Wai disassembly is significantly harder to work with than the final version, almost no guides or tutorials support it, nobody works with it, and as you've seen the tools might not even properly support it. If you just want the cool stuff from the beta, that can easily be ported over to the final.
     
  4. CodenameOmega

    CodenameOmega

    20
    0
    1
    Blaster The Hedgehog
    No offence, but that doesn't answer my question. I've come a long way with the proto, and I've no idea how to port it all to the final.
     
  5. CodenameOmega

    CodenameOmega

    20
    0
    1
    Blaster The Hedgehog
    I've another question. I'm trying to edit monitors in Sonic 1 (Hivebrain ASM68K Split/Text) and whenever I open the mappings, It's all just 1 static frame. Can you please help.
     
  6. MarkeyJester

    MarkeyJester

    My predecessors have nothing on me. Resident Jester
    I assume you are using SonMapEd.

    For some reason, SonMapEd has the priority order wrong and the icons are displayed behind the monitor, I believe this to be a bug with the tool.
     
  7. muteKi

    muteKi

    Fuck it Member
    7,555
    0
    16
    I was curious about the procedure discussed on this page -- http://info.sonicretro.org/SCHG_How-to:Fix_a_race_condition_with_Pattern_Load_Cues

    Here is my understanding of the issue:

    When setting compressed data to be decompressed during the level (such as loading in art for level-end sequences), the Genesis isn't fast enough to be able to handle it over the course of a single frame. The game's code handles this by having a portion of the art be decompressed and DMA'd every frame. When the Genesis VDP has dealt with a frame it generates an interrupt that the system interprets as a sign that it can continue decompressing the data without generating lag.

    Due to the way the instructions are ordered, however, the pointer to the next set of data to compress is set only after the routine to deal with queued data is initialized (i.e., a null pointer dereference in waiting -- which causes a game crash). Again, usually not an issue because the call to actually run that routine happens only once the data is set, which is done after the initial round of decompression. When the screen is drawn normally there's no issue to be concerned with, but errors occur when this interacts with the routines to change the palette for a water effect.

    Here is (are) the part(s) I think I'm confused on:
    I was of the understanding that the VDP interrupt that triggers the palette re-write is a different level from the sort of interrupt that the PLC routine would be listening for (Level 4); the VBLANK interrupt (Level 6) can only be triggered (and always triggers) at the end of the frame. Furthermore, the (L4) interrupt triggers based on setting related to the difference in height from the level frame start to the expected water level. I could understand the problem being an issue if the routine is based around the timing of the L4 interrupt (instead of L6) -- if the initial decompression finishes during the middle rendering of the frame, then if the water level is high enough on screen the L4 interrupt can trigger before the pointer is set, causing null pointer dereference leading to a crash. This seems to be against the notion of the purpose of the routine, which is to only do decompression after the frame is drawn (hence the check for the L6 interrupt). Otherwise, the system is somehow triggering the L6 interrupt during the middle of the frame which doesn't seem possible based on what the L6 interrupt is supposed to be. Am I misunderstanding how the L6 interrupt works? Is there something about Labyrinth specifically that causes the PLC routines to run more slowly than other levels?
     
  8. vladikcomper

    vladikcomper

    Tech Member
    182
    0
    0
    Russia
    Sonic Warped
    muteKi, your question is fairly reasonable, in fact, and the assumptions you make are mostly correct. As always, the devil is in the detail.

    First of all, I'd like to elaborate on the VDP interrupts mechanics, VInt (L6) specifically, to make sure there's no misunderstanding here.
    The Vertical (Level 6) Interrupt fires at the end of a TV frame, not a game frame. By the game frame, I mean one full iteration of game's main loop, where the game state, including all in-game logic, physics and objects are being updated.
    Which is important, but might not be obvious right away, there is no such thing as "frame drawing" on the Mega-Drive, as far as software is concerned. The process of forming a signal to be displayed on the TV screen is fully delegated to VDP, which, to put it simple, barely renders anything, but just streams tiles stored in VRAM (obviously, with addition of selected palettes, flipping flags, scrolling displacements and overlaying several planes). Software can only manipulate data stored in VRAM and various registers to immediately make VDP stream altered frames. This contrasts with newer systems, which have enough VRAM to implement screen buffering, whereas the GPU streams lastly flushed frame, while the new one can be rendered in software without affecting what's currently streamed.
    As changes to VPD state and VRAM are streamed immediately as displaying progresses, some care is required to alter data for the next frame without causing any visible distortions (like changing scrolling midscreen or overwriting tiles currently displayed). So, as you well aware, all games use the Vertical Interrupt to safely transfer any changes to VDP and to precisely time all the game logic.
    Vertical Interrupt happens as VDP is entering vertical blanking period, during which the CRT beam is moving back to the topmost position to start redrawing a new frame. Vertical retrace occurs every 1/60th of a second for NTSC standard and every 1/50th of second for PAL systems (at 60Hz and 50Hz correspondingly).

    One important thing to note, is that in Sonic 1 (and many other games), if the game frame takes longer than 1/60th (1/50th) of a second to process, Vertical Interrupt still fires, unless interrupts are masked or disabled. This means, it will interrupt the current instruction being processed inside the main game loop, which may happen to be inside "RunPLC" routine, which has a race condition you described. However, this is not the case (or at least, nearly impossible to reproduce in the original game), but read below.
    In Sonic 1, the Vertical Interrupt (VInt) recognizes if the current frame is lagged by looking up a certain byte in RAM, which should be non-zero if the game finished processing logic and waits VBlank to start (the byte represents routine number current game mode wants to run inside VBlank to update frame properly). In case of a lag frame, the game will not send any data to VRAM to alter the frame to be displayed, but still does some necessary work. During "lagged" VInts, UpdateMusic routine is still called, otherwise, the music would lag alongside the game. For water levels, it also transfers the palette and sets Horizontal Interrupt (L4) to fire, otherwise, the game couldn't keep swapping palettes during lag.

    So the interrupts do actually interrupt at any point of the code, so how come Vertical Interrupt is not the case for this race condition? Because the game barely lags at all where the bug actually occurs (in LZ, as the end level sequence starts, even with some decompression setup in place, this won't make the game lag at all). Moreover, while it's still present in S2, it's impossible to reproduce.

    The answer is that the Horizontal Interrupt (L4) is actually responsible.
    In Sonic 1, if the water is to be rendered above line 96 of the screen, the execution of the last few subroutines inside VBlank is cancelled, and the are executed inside HBlank instead. This routines include UpdateMusic... and the Nemesis decompressor.
    This is actually a part of major hack by the developers, as they couldn't handle concurrent work of horizontal and vertical interrupts properly, and due to the sound engine bug that they couldn't locate. You see, since Vertical Interrupt is level 6 and Horizontal interrupt is level 4, VInts have priority over Hints. Which means, if execution of VInt has prolonged well enough to the beginning of a new TV frame, HInts won't fire at all, unless VInt handler exits. Sonic 1's VInt is poorly unoptimized, and along with a heavy sound driver, it quite often takes longer than it should to execute. If it wasn't for this "hack", water portion in LZ would constantly flicker or jitter as the music plays. So they decided to move execution of heavy routines to HInt, if only it happens near the top of screen to be affected.

    As the result, since the CPU is barely loaded in the end of LZ, processing of the PLCs requested by the end of level cards happens early, during the top few scanlines of the frame. Preparation of decompression doesn't even remotely cause lag, but takes an equivalent of a several scanlines to process. HInt fires exactly near these scanlines, if you scroll camera down enough to put water surface on top, which causes this race condition and crash.
     
  9. muteKi

    muteKi

    Fuck it Member
    7,555
    0
    16
    Thanks a lot! Of course my big confusion came about by forgetting that lag exists, go figure. This was quite helpful in clearing up what I was confused by.
     
  10. Dark Sonic

    Dark Sonic

    I'll find the old avatar eventually Member
    12,184
    14
    18
    Working on my art!
    So. I'd like to experiment with modding Sonic Mania. I want to port S3K levels to Mania, not 100% faithfully mind you but in a way that might be a fun combo of the two. What tools would I need to accomplish this?
     
  11. MainMemory

    MainMemory

    Every day's the same old thing... Same place, diff Tech Member
    4,313
    17
    18
    SonLVL
    Use rsdkv5_extract to extract files from Data.rsdk for editing, then use Maniac Editor to edit the levels. The artwork is all stored in GIF images, any image editor that supports palettes will work. If you need to edit animations or sprite sheet layout for an object, you can use RSDK Animation Editor.
     
  12. CodenameOmega

    CodenameOmega

    20
    0
    1
    Blaster The Hedgehog
    I need a bit of help on another hack, this time S2 Xeno Disasm-based. I am trying to edit the ending movie sequence pictures, but when I select the mappings, they don't show up on SonMapEd. May I please have a bit of help? Thanks.
     
  13. Clownacy

    Clownacy

    Tech Member
    782
    6
    18
    If I remember right, those aren't sprite mappings, they're plane mappings. SonMapEd doesn't work with those. You'll need a different tool, like PlaneEd or Captain PlaneEd. I think there was another tool called SoniPlane or something.
     
  14. Ryuki

    Ryuki

    Member
    96
    0
    6
    So I've recently started dabbling in Unity; and have started work on a simple SHMUP.
    The camera is located behind the player ship.
    The player ship can be moved around the screen via left analogue input.
    The player cross hair moves around the screen via right analogue input.

    The player ship looks towards the crossahir, using the below code:
    Code (Text):
    1.        
    2. // Look at CrossHair;
    3.         var point = new Vector3(_crossHair.transform.position.x, _crossHair.transform.position.y, _crossHair.transform.position.z);
    4.         transform.LookAt(point);
    5.         transform.Rotate(-90, 0, 270); // fix awkward blender import;
    This all works as intended, but I also want to implement a barrel roll ala Star Fox. All previous attempts have yielded awkward gimbal lock-esque issues.
    Simply put I want the ship to look at the crosshair as they move around the screen, but I also want to be able to rotate the player on it's x-axis when barrel rolling.

    Shattered so safe to assume there wil be typo's and I'll not have made myself very clear; so if I need to clarify anything please let me know.

    Any help would be greatly appreciated!
     
  15. lil-g-gamegenuis

    lil-g-gamegenuis

    GO! GO! GO! GO! GO! GO! Member
    25
    0
    1
    olathe, ks
    Practicing to make better SMPS
    uhh... this isn't really a basic question, nor is this about hacking, or really sonic in general. You should probably ask this in some place that's related to Unity, Like the Unity forums.

    However to answer your question, use quaternions, they are made specifically to fix gimbal lock. It also might help to make a parent object for the ship that you rotate via script and a child object that only contains the model.
     
  16. Ryuki

    Ryuki

    Member
    96
    0
    6
    Funnily enough I resorted to asking here because asking in the Unity forums lead to somebody posting a link to the transform.rotation section of the manual, followed shortly by the thread being marked as solved and removed. :v:
    I was worried it would involve qauternions, I've looked into them in the past only to discover that they're a rabbit hole leading into another rabbit hole etc etc; guess it's time to finally get to grips with them.

    Additionally the project I'm working on is related to various SEGA SHMUPs, but that's all I'm at liberty to say unfortunately.
     
  17. MainMemory

    MainMemory

    Every day's the same old thing... Same place, diff Tech Member
    4,313
    17
    18
    SonLVL
    If it's a fan game, you should be asking in the fan gaming section. If it's an original game, you should ask in Technical Discussion. This section is specifically for hacks and mods of existing Sonic/Sega games.
     
  18. lil-g-gamegenuis

    lil-g-gamegenuis

    GO! GO! GO! GO! GO! GO! Member
    25
    0
    1
    olathe, ks
    Practicing to make better SMPS
    If you use the method of having a parent object that you rotate at runtime and a child object that contains the model pre-rotated, you should be able to avoid quaternions. Also they aren't too difficult to understand.
     
  19. Ryuki

    Ryuki

    Member
    96
    0
    6
    Noted, feel free to trash.
     
  20. CodenameOmega

    CodenameOmega

    20
    0
    1
    Blaster The Hedgehog
    Excuse me, but I have another question. I know, I'm annoying. I'm trying to restore Stego and Gator to S2 Beta, but I get nothing (Stego) or glitchy HPZ graphics (Gator). Can somebody please help me? Thanks.