Sonic and Sega Retro Message Board: Basic Questions & Answers thread - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
  • 408 Pages +
  • ◄ First
  • 402
  • 403
  • 404
  • 405
  • 406
  • Last ►
    Locked
    Locked Forum

Basic Questions & Answers thread NEWBIES: Start here!

#6046 User is offline MarkeyJester 

Posted 13 May 2018 - 06:23 AM

  • It's Saturday TV Toons!! (90's Style)
  • Posts: 1851
  • Joined: 22-July 08
  • Gender:Male
  • Location:Japan
  • Wiki edits:16
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.

#6047 User is offline muteKi 

Posted 16 May 2018 - 12:06 AM

  • Fuck it
  • Posts: 7532
  • Joined: 03-March 05
  • Gender:Male
  • Wiki edits:91
I was curious about the procedure discussed on this page -- http://info.sonicret...ttern_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?

#6048 User is offline vladikcomper 

Posted 16 May 2018 - 10:00 AM

  • Posts: 182
  • Joined: 13-June 09
  • Gender:Male
  • Location:Russia
  • Project:Sonic Warped
  • Wiki edits:1
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.
This post has been edited by vladikcomper: 16 May 2018 - 10:02 AM

#6049 User is offline muteKi 

Posted 16 May 2018 - 11:58 AM

  • Fuck it
  • Posts: 7532
  • Joined: 03-March 05
  • Gender:Male
  • Wiki edits:91
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.

#6050 User is online Dark Sonic 

Posted 16 May 2018 - 08:07 PM

  • Posts: 11531
  • Joined: 21-April 06
  • Gender:Male
  • Project:Working on my art!
  • Wiki edits:10
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?
This post has been edited by Dark Sonic: 16 May 2018 - 08:12 PM

#6051 User is offline MainMemory 

Posted 16 May 2018 - 10:20 PM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4194
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
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.

#6052 User is offline CodenameOmega 

Posted 19 May 2018 - 01:58 AM

  • Posts: 20
  • Joined: 22-April 18
  • Gender:Male
  • Project: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.

#6053 User is offline Clownacy 

Posted 19 May 2018 - 09:57 AM

  • Posts: 718
  • Joined: 06-July 13
  • Gender:Not Telling
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.

#6054 User is offline Ryuki 

Posted 20 May 2018 - 12:53 PM

  • Posts: 96
  • Joined: 18-January 11
  • Gender:Male
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:
        
// Look at CrossHair;
        var point = new Vector3(_crossHair.transform.position.x, _crossHair.transform.position.y, _crossHair.transform.position.z);
        transform.LookAt(point);
        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!
This post has been edited by Ryuki: 20 May 2018 - 12:54 PM

#6055 User is offline lil-g-gamegenuis 

Posted 20 May 2018 - 04:48 PM

  • GO! GO! GO! GO! GO! GO!
  • Posts: 24
  • Joined: 03-April 12
  • Gender:Male
  • Location:olathe, ks
  • Project:Practicing to make better SMPS

View PostRyuki, on 20 May 2018 - 12:53 PM, said:

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:
        
// Look at CrossHair;
        var point = new Vector3(_crossHair.transform.position.x, _crossHair.transform.position.y, _crossHair.transform.position.z);
        transform.LookAt(point);
        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!

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.

#6056 User is offline Ryuki 

Posted 21 May 2018 - 05:34 AM

  • Posts: 96
  • Joined: 18-January 11
  • Gender:Male
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.

#6057 User is offline MainMemory 

Posted 21 May 2018 - 11:47 AM

  • Every day's the same old thing... Same place, different day...
  • Posts: 4194
  • Joined: 14-August 09
  • Gender:Not Telling
  • Project:SonLVL
  • Wiki edits:1,339
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.
This post has been edited by MainMemory: 21 May 2018 - 11:48 AM

#6058 User is offline lil-g-gamegenuis 

Posted 21 May 2018 - 03:00 PM

  • GO! GO! GO! GO! GO! GO!
  • Posts: 24
  • Joined: 03-April 12
  • Gender:Male
  • Location:olathe, ks
  • Project:Practicing to make better SMPS

View PostRyuki, on 21 May 2018 - 05:34 AM, said:

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. //forums.sonicretro.org/public/style_emoticons/default/v.png
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.


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.

#6059 User is offline Ryuki 

Posted 21 May 2018 - 06:28 PM

  • Posts: 96
  • Joined: 18-January 11
  • Gender:Male

View PostMainMemory, on 21 May 2018 - 11:47 AM, said:

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.


Noted, feel free to trash.

#6060 User is offline CodenameOmega 

Posted 26 May 2018 - 01:17 PM

  • Posts: 20
  • Joined: 22-April 18
  • Gender:Male
  • Project: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.

  • 408 Pages +
  • ◄ First
  • 402
  • 403
  • 404
  • 405
  • 406
  • Last ►
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users