Sonic and Sega Retro Message Board: Green Snake - Viewing Profile - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help

Group:
Member: Members
Active Posts:
69 (0.06 per day)
Most Active In:
Engineering & Reverse Engineering (29 posts)
Joined:
08-February 12
Profile Views:
4938
Last Active:
User is offline Yesterday, 08:32 PM
Currently:
Offline

My Information

Age:
17 years old
Birthday:
October 14, 1997
Gender:
Female Female
Location:
0x00
Interests:
Hacking

Contact Information

E-mail:
Private

Previous Fields

Project:
SoniPlane
National Flag:
fi
SA2 Emblems:
1

Latest Visitors

Posts I've Made

  1. In Topic: General Project Screenshot/Video Thread

    21 February 2015 - 02:23 AM

    Fuck yes! We will finally have a working sprite mappings editor? The UI looks kinda messy, but that may just be because we can't try it in action.
  2. In Topic: Basic Questions & Answers thread

    09 February 2015 - 07:40 AM

    The issue is how large the games are and how much they are hardcoded and placed in code. However I can help you research this and test in action for accuracy. I have some knowledge of this and have ported some code from the original game which also contains some of the mask sizes, and as well can probably track down all the changes. I can also try to make a code to display the bounds of a hitbox ingame, albeit it wont be easy task. Overall I can see if I can help somewhat
  3. In Topic: Basic Questions & Answers thread

    09 February 2015 - 05:38 AM

    The classic Sonic games and really most games of the era usually use very basic and cheap ways to deal with collision. That being said it does not mean it is bad, but it is very simple. Lets imagine Sonic's standing pose. The sprite is shown relative to Sonic's X and Y positions. Not all of the sprite is on positive axis however, which allows the hitbox be more "accurate" or fair. While the hitbox is calculated from X 0 Y 0, the sprite is usually shown somewhere in the negatives. This allows to not have to make exceptions for all sprites, especially sloped running ones, which use the same collision hitbox as standing sprite for example. In fact, in original Sonic 1, there is only two hitbox sizes, one for jumping/rolling and spinning, and one for everything else (or at least from what I remember this is the case), while Sonic 2 and 3K adds few different sizes, for example Tails as he is shorter. In Sonic 1 all the hitbox sides, as with floors, walls and ceilings, so with the objects is hardcoded, while in Sonic 3K it is controlled by value in RAM which allows easier change. The way the collision hitbox dealt, is the game checks for object RAM for each object with collision value of not 0, and then gets its size and position, and does simple calculations to check the two overlap at least slightly. Each object has custom size which is often the size of the sprite itself. Then the objects have a collision value, which determines how they act. Most objects are made to just hurt Sonic on touch, unless he is rolling. However some have special behaviors, such as monitors break if Sonic rolls into them, or caterkillers scatter, and some objects simply increment the routine counter where the object itself determines what to do. Or even in some cases, the collision is hardcoded to the object itself, such as spikes, which are actually a solid object, which is a common way to make Sonic push against an object and stand on it. Objects such as springs and spikes use this to bounce or hurt Sonic when standing on top of them or push against them. Here is a quick mock-up of how the game approximately process the hitboxes:

    Posted Image
  4. In Topic: SoniPlane

    03 January 2015 - 07:16 AM

    Update beta 1.1
    (* = fixed bug, + = added feature, - = removed feature)

    + Windows have borders
    + Windows can be resized and moved
    + Windows can be minimized and maximized
    + cursor images can be customized
    + proper hotkeys for menu functions
    + when project is loaded the taskbar will blink until the app is focused.
    + save states added
    * commandline would not work properly
    * all tiles were not rendered properly
    * now all menu items are grayed out instead of hidden when not used
    * program reset is now CTRL+ESC
  5. In Topic: Random Hack/Mini Project Thread

    24 December 2014 - 07:13 PM

    Well you also realize how limited the Mega Drive, and especially its palette is, so its hard to make believable palette cycle without either hardcoding it, or making the game slow down a lot. Also the cycle is the original, with just palette swapped to account the day/night cycle. There has been some bug where it would reset once in a while, its due to the fader being imperfect, and not stopping when it should, although should only occur rarely from my testing.