- Member: Members
- Active Posts:
- 604 (0.19 per day)
- Most Active In:
- General Sonic Discussion (188 posts)
- 05-September 04
- Profile Views:
- Last Active:
- 48 minutes ago
- 19 years old
- October 20, 1993
- National Flag:
Topics I've Started
06 December 2012 - 08:59 PMI've been wondering, how does the mouse position tracking work? The wiki doesn't go into very much technical detail at all, and all I can gather is that it seems to use the regular A, B, C (and for the US model) Start buttons as a normal 3 button pad does (just an assumption on my part from what the wiki said of it).
The part I'm interested in is how does it send mouse movement information? Is it mostly hardware side and acts like an Atari paddle and positions are absolute? Or is it just sending relative info for how much it moved every interval, and mouse position is determined/handled by the software? Is it in any way using some form of D-pad commands?
24 August 2012 - 07:49 AMI've been thinking about this for a bit, and I've come to the conclusion that it's a poorly designed game. Most of the level designs feel pretty short and uninteresting, the other 8-bit games managed to have more interactive level designs. Many of the bosses were really simple and boring designs. For example, the ALZ boss. It does nothing but blows a balloon up for you to pop in its face, and it just stands there doing this the entire time, never attacking you. The SHZ boss just moves back and forth, shooting pseudo-homing projectiles. The GHZ boss moves back and forth quickly. The UGZ boss just sits there taking damage while you dodge the marbles coming down.
Also, the physics suck. I understand that it's less capable than the Genesis, but they could've done better, as this has more to do with tweaks than radical function changes. The acceleration and friction is twice as fast as the 16-bit games, and deceleration is 2.5 times slower. Also, horizontal velocity is not affected by jumping on slopes, and there's friction in midair.
23 August 2012 - 07:18 PMI just read through a bit of the physics guide on the wiki in an attempt to understand the controls better, and I now suspect that the speed cap wasn't by design, but rather oversight. Obviously, the purpose of the speed cap is to ensure that the player travels no faster than 6 pixels per second, but the problem is that it also caps off movement when the player is traveling faster than that when not using his own abilities (such as using a speed booster or horizontal spring). It's only capped off when the player is using the controller to move the direction that they are already going, even though the player was meant to travel faster than 6 pixels per second by design.
I mean, this would make it a bug due to being applied to situations where the player is supposed to be moving faster than their max speed, right? I ask because I'm inexperienced in these matters and figured that others with more experience dealing with the engine might have a different answer than me.
09 April 2012 - 07:45 PMSince this is a technically oriented question, I've put it here instead of general.
How does Sonic Jam work exactly? I know that it's a port, and not emulation, but how exactly is the engine structured? How does it store the game assets? Most importantly, how are graphics handled? Is it bitmap based, or do they have some sort of tile renderer setup instead? How easily could one include high-color graphics, like using a 256 color palette instead of a 64 color palette? Has it ever been hacked before? If not, how easy would it be? Not that I have any intention of doing so, but it was just a curious question that popped into my head.
09 April 2012 - 05:23 AMOne thing that's always really bugged me about that show is their redesign of Robotnik. They changed his glasses into black Sonic style eyes with red pupils, gave him a really retarded looking suit, and changed his pants to light grey. That, and they made Tails 4 years old even though he's supposed to be 8. I'm just curious why they decided not to use the original designs.