Topic: Really cool

I hope this turns out very modular, for something like Chaotix-style physics and loops as well as levels. I'm odd, because I prefer Chaotix over Sonic 1/2/3. (i'm aware the first level is right out of Chaotix, but it's not the same when I can't bee dash through it lol)

I was going to suggest a feature to use Tracker music, but it's already in use and I couldn't tell because the music provided was direct MIDI imports using GS instruments. tongue
The framerate is stuttery @ 85Hz.
No dramatic ring splash "blast processing" slowdown?
Blaarg MD NTSC filter? (to "fake" a TV)
Bonus stages? With TCP-IP multiplayer?

Last edited by CharmyBee (2009-04-22 20:58:08)

http://steamcard.com/do/sigcard-tf2/abee.png

Re: Really cool

CharmyBee wrote:

The framerate is stuttery @ 85Hz.

I think the goal is to perform similarly on a large variety of hardware, but you bring up a good point.  Nowadays there is no reason not to have unlimited frame rate and rely on real time for physics.  In a current game I am working on, I am processing 500-700 frames per second (render limit is capped) and even if the rate drops to 100 fps, the game performs the exact same way.

CharmyBee wrote:

No dramatic ring splash "blast processing" slowdown?

I believe that the trig functions are getting used a little recklessly which can be explained with the early version number (game is far from mature).  The ring splash has always been hard on the earlier sonic games (Sonic 1 with the rotary saws was a big ouch or sonic 2 with blue chemical plant snakes).  The biggest thing that bugs me about the rings is how they tend to pool in one spot and bounce vertically.  If the h-velocity is 0 it should be nudged I think.

CharmyBee wrote:

Blaarg MD NTSC filter? (to "fake" a TV)

I actually like the effect.  wink


Collision detection is still pretty rough too, there are plenty of places in OpenSonic where you can travel through the floors of narrow platforms.  I have no room to talk though because I can't seem to get it right when I try to patch it.

Personally I have had to step back from OpenSonic for a few revisions.  Right now I think the project is asking for more that can be reliably provided until the community can count on the behavior of the engine.  Things like completely original graphics are easy to produce if the specification is in place but right now the spec is existing brick files and in code, a spec which can rightfully change next revision.

CharmyBee: I have high hopes too.  smile

Re: Really cool

Hello Charmy Bee and welcome to the forums smile

This game will evolve a lot on July/2009 (vacations), but until there there will be only small updates.

CharmyBee wrote:

    No dramatic ring splash "blast processing" slowdown?

I believe that the trig functions are getting used a little recklessly which can be explained with the early version number (game is far from mature).  The ring splash has always been hard on the earlier sonic games (Sonic 1 with the rotary saws was a big ouch or sonic 2 with blue chemical plant snakes).  The biggest thing that bugs me about the rings is how they tend to pool in one spot and bounce vertically.  If the h-velocity is 0 it should be nudged I think.

I don't understand the question. By "hard" you mean like they had more weight? Or something like when the time passes slower than the regular time?

Bonus stages are already in our plans, but TCP/IP multiplayer is not. Of course some multiplayer game mode can be created in the future, but it won't be developed right now.

think the goal is to perform similarly on a large variety of hardware, but you bring up a good point.  Nowadays there is no reason not to have unlimited frame rate and rely on real time for physics

Actually, there is a problem. Currently, the maximum fps is 100. Suppose there is no limit. If the FPS increases too much, then the time interval T between two consecutive game steps/frames gets too small because T = 1/f. This means that the delta variables, which measures T in seconds, get too small and this would have a negative impact on animations and movement.

Some time before Open Sonic 0.1.0, there was no upper/lower bound for the FPS. I tested the old engine with my notebook (320x240 fullscreen), the FPS was greater than 1000 and I had some problems with it. I also tested it with my old computer (640x480 2xSaI), the FPS was horrible and I had terrible issues with both movement and animation (because T was too high). To solve both problems, I've included both upper and lower bounds for the framerate.

This technique is shown in a game development book called Desenvolvimento de jogos eletronicos (in Portuguese).

Re: Really cool

Alexandre wrote:

Currently, the maximum fps is 100.

Wouldn't 120 be more sensible? (i.e. 120hz TVs and displays)

Last edited by CharmyBee (2009-04-23 19:50:16)

http://steamcard.com/do/sigcard-tf2/abee.png

Re: Really cool

No. The FPS of the game tells us the time interval between two calls to some rendering method. In Open Sonic, the rendering routine copies images stored in the memory to the video buffer. The refresh rate of your monitor tell us how many times per second the hardware reads the video buffer and displays it for you (physically). Most 2D platformers run smoothly with about 60 fps.

When the FPS gets high, the time interval between two consecutive frames can get so low that in this case there will be very few pixel changes (or none at all) between them (t=1/fps; x(t)=v.t implies x(t)<1 if t-->0, v constant). So the rendering routine would render the same image over and over again. Of course we could say "oh, 500 fps is much better, 1000 fps is awesome, 2000 is super!", but in practice there will be no difference.