Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Darkylight]

I'm looking for your engine but I dont understand... various things, why do you use global alterable values without names? xDD, and... You complicate too much with the engine. You made your own version to make the kids move and same for triggers, I dont know the extensed code to do it... xD

Anyway, cool, I think, I only want to see , I saw much interestant things in your engine.

Um you do know this game was made as he learned how to make games right?

I know, that's why I dont know how he complicated it too much in the engine o.o

[Valkema]

I'm looking for your engine but I dont understand... various things, why do you use global alterable values without names? xDD, and... You complicate too much with the engine. You made your own version to make the kids move and same for triggers, I dont know the extensed code to do it... xD

Anyway, cool, I think, I only want to see , I saw much interestant things in your engine.

Um you do know this game was made as he learned how to make games right?

really? woah, he made a masterpiece while he was learning o.o

You don't have to be a great programmer to make a platforming engine, double jump, a gun, and a save feature. You don't have to be a master programmer to design a good game.

[Kayin]

The version of MMF2 I used didn't even allow the renaming of variables. So that wasn't a "I'm learning" thing, that was a "I hate this program" thing that I'm glad got rectified.

Though if you wanna see examples of me learning, look at the Apple code in the first layout as opposed to later layouts. I really sorta figured out how to simplify stuff later on.

[Sarah]

GUYS. It's not complex because he was learning or anything.

It's because understanding the works of a god can be hard sometimes.

Seriously though, I hope to see a bug-free version and although I doubt it'll ever happen, maybe a finished game? <3

[Ellipsis]

Ah, just another bug I'd quite like to be fixed:
timers - you've used literal time (like 1 second) and no offence but measuring delays in frames would have been nicer.
For example Mecabirdo places bullets close together in slowmo if you have lag, this is because the game runs slower but the bullets are created with delays between them as if the game was running normal speed.
Instead of using timers you can instead have a variable that you set to 0 when the game starts, then just add one to it each frame. Lets call that variable "framesFromGameStart" this lets you keep track of the number of frames passing. You can just store its value in another variable to start a timer (call this bulletTimer), then see if bulletTimer+30>framesFromGameStart. Or whatever.
If that makes any sense. Regardless hopefully it should be easy to change and it would help remove a few glitches.
If someone could do this that would be great, otherwise *maybe* I'll get a copy of MMF2 and try edit it myself (I have no idea how to use it).

[Kayin]

Yeah, I didn't do any sorta delta time stuff in IWBTG. Though I don't in Brave Earth either, but there won't be any sort of 'modes' or anything. 60 frames fixed, that is all.

But it's supposed to be a nintendo game so thats okay in that case.

[Ellipsis]

I don't know. I mean, using timers instead of frames would be fine if there was never lag.
However I guess you have to plan for it?
I remember Mechabirdo was really really easy for me on my old computer.

[Kayin]

Well with mechabirdo, using time obviously is an issue because I didn't realize that I was building the game around a 'tick' model instead of a 'real time' model so I didn't see the problem in mixing them. For stuff like BEPRO, I'm never using time calls. I'm measuring things by ticks. So if there is lag, the game slows down and that's just the way the cookie crumbles.

I generally don't like using times like delta time because you get movement that isn't totally predictable. For example if you have a jump that's like, every frame, set y to like...

player.y - (jumpheight * (timedelta * 60))

The * 60 is nice because it makes the timedelta roughly around 1 when running the game around 60fps and makes a lot of numbers make more sense. But whatever. So lets assume on a normal frame it looks like..


player.y + (jumpheight * (timedelta * 60))
(436)    -  (    10        *           (1)       )

So we get a position for that one tick of 426

So lets craft a totally impractical situation where it takes 5 frames to get to the peak of the jump and theres no gradual acceleration or deacceleration.  If we do this 5 times, we get 286. If the game is running only a 30 FPS, what happens?


(436)    -  ((    10        *           (2 (due to the lower frame rage)       )
This makes us move 15 frames per tick and what was 5 ticks at 60fps is now...... 2.5 ticks? Yikes. So our final position in the air is either. 296 or 276, both of which are 10 frames off of what we want.

In a real world situation, with jumps that go on for awhile and bigger numbers, the variance can be as low as a pixel. That can still matter, but it can be designed around. But here comes another nasty situation. Lets say the game moves at 60 fps and then like, near the top of the jump arc, the game lags -- especially if it lacks for a moment into the 10s of FPS. You can get a significant jump boost from there. Now you can limit that too by say, capping the minimum FPS at 30 (anything under 30 produces slow down) but still, this all adds to a lot of uncertainty. When working on BEPro, the NES style made me forgo all of this. Every pixel matters when your character can precisely jump a 48 pixel gap. It seems more legitimately NESy too.

There are other tricks and work arounds too that might show up in future games. One method is controlling how much something's logic loops and mix that with time delta. For example you can have the player's platform code run like, 180 times per second. At 60 frames per second, the platform code for the player will run 3 times.  at 30, it'll 6 times and at 120 fps, it'll have to well, alternate the amount of updates each frame. But in practice it shouldn't be so hard to notice gives you totally reliable jump arcs and stuff. You can then use standard time delta for things that don't particularly matter much.

[tijit]

Delta time is appropriate for some games, but I agree stuff with pixel perfect precision, ie something like IWBTG or certain shmups, the programmer should just be writing code that isn't horribly inefficient so it runs at 60fps no matter what. Unfortunately with things like MMF2, that isn't always possible :~

Also lag spikes can cause some ridiculous collision bugs in frame rate independent games, as Matt found out while he was hatlands, the most common being falling through the floor.

[Kayin]

Yeah. You can get around that if you use an incremental style of player movement (Instead of moving a player up or down 10 pixels and checking for collision, you increment him down 1 pixel at a time in a loop). But yeah thats what leads to nightmares with the frameskip version of IWBTG and platforms. I think my goal in BE:TiTS, when I get there, will be to mix time delta movement (For things like enemies or fireballs or other bullshit) with high iteration logic for movement for the player. So that way the amount the logic loops per tick can be figured out by a time delta expression and movement will still be pixel perfect, but without the huge overhead that comes with applying that to every bit of logic.

Though this potentially could lead to some weirdness so who knows if it works it. I would like BE:TiTS to be vsyncable at variable refresh rates though.

[Ellipsis]

Yes I totally agree with you, delta time frame independent things are a total pain and mostly you should avoid them.
Slowdown in lag is much better in my opinion.
In my games I've recently  found a bit of a compromise. My game always, always runs at 60 frames per second, however in times of lag it just doesn't show some frames. Now strange as it is, actually showing a frame uses a lot more cpu time than just working it out. So working out 60 frames per second uses about 1% of the cpu, the rest is just updating the image (if I used video card acceleration I could cut this down a lot).
So in this way my game is ideally 60fps shown also but if there's some lag it just drops with say, 30fps and should still look seamless. In more lag it could drop to like 10 frames per second and then it starts to look very jerky but the jumps are still all correct and really my game never lags too much any how. I mean there's always a breaking point somewhere with any "solution". On the bright side, by doing this there's never any slowdown and jumps remain pixel perfect and predictable.

[Storyyeller]

Well with mechabirdo, using time obviously is an issue because I didn't realize that I was building the game around a 'tick' model instead of a 'real time' model so I didn't see the problem in mixing them. For stuff like BEPRO, I'm never using time calls. I'm measuring things by ticks. So if there is lag, the game slows down and that's just the way the cookie crumbles.

I generally don't like using times like delta time because you get movement that isn't totally predictable. For example if you have a jump that's like, every frame, set y to like...

player.y - (jumpheight * (timedelta * 60))

The * 60 is nice because it makes the timedelta roughly around 1 when running the game around 60fps and makes a lot of numbers make more sense. But whatever. So lets assume on a normal frame it looks like..


player.y + (jumpheight * (timedelta * 60))
(436)    -  (    10        *           (1)       )

So we get a position for that one tick of 426

So lets craft a totally impractical situation where it takes 5 frames to get to the peak of the jump and theres no gradual acceleration or deacceleration.  If we do this 5 times, we get 286. If the game is running only a 30 FPS, what happens?


(436)    -  ((    10        *           (2 (due to the lower frame rage)       )
This makes us move 15 frames per tick and what was 5 ticks at 60fps is now...... 2.5 ticks? Yikes. So our final position in the air is either. 296 or 276, both of which are 10 frames off of what we want.

In a real world situation, with jumps that go on for awhile and bigger numbers, the variance can be as low as a pixel. That can still matter, but it can be designed around. But here comes another nasty situation. Lets say the game moves at 60 fps and then like, near the top of the jump arc, the game lags -- especially if it lacks for a moment into the 10s of FPS. You can get a significant jump boost from there. Now you can limit that too by say, capping the minimum FPS at 30 (anything under 30 produces slow down) but still, this all adds to a lot of uncertainty. When working on BEPro, the NES style made me forgo all of this. Every pixel matters when your character can precisely jump a 48 pixel gap. It seems more legitimately NESy too.

There are other tricks and work arounds too that might show up in future games. One method is controlling how much something's logic loops and mix that with time delta. For example you can have the player's platform code run like, 180 times per second. At 60 frames per second, the platform code for the player will run 3 times.  at 30, it'll 6 times and at 120 fps, it'll have to well, alternate the amount of updates each frame. But in practice it shouldn't be so hard to notice gives you totally reliable jump arcs and stuff. You can then use standard time delta for things that don't particularly matter much.

This, so much. Game coders that use delta time should be sent to the moon. *cough* Team Meat *cough*


Anyway, I unfortunately don't know MMF2 and don't really feel like learning, but otherwise, I might have a try at porting it to C++/SDL sometime.

[Einstein1896]

There's a very good reason why one would use delta time: the game can be slowed down or sped up dynamically. (E.G, bullet time fighting!)
Also, you can completely avoid the jump height problem with calculus or kinematics: just add 1/2 * g * t^2 to the y position every update, where g is the gravity and t is the delta time.
full pseudocode:

let dy = yspd*t + .5*g*t*t;//dy is the change in y this update, yspd is the current vertical velocity (positive or negative) in units per second, g is the acceleration y-component in units per second per second, and t is the delta time in seconds.
yspd += g*t;
for (int i=0;i<dy;i++)
{
    if (no obstacle one pixel below)
        y++;
    else
        yspd=0;
}


of course, you'd also check if there was something below you /before/ you accelerated in the first place.
If it's not a pixel-based game, still use the same dy code, but instead of iterating through every pixel of vertical movement, iterate through all the obstacles, find the highest one that intercepts your path (from the starting y position to y + dy), and set your y position to be that objects y position (minus how tall you are)
theoretically, this will work perfectly and consistently with any amount of lag, though it gets more complicated with horizontal speed; rather than plotting a linear path, the path has to be a parabola.

Furthermore, the problems with this being hindering to user input under laggy conditions can be fixed by inserting fake slow-down under heavy lag.

[Storyyeller]

I know how delta time works. It's just that it's a horrible idea that should never be used in a game under any circumstances.

The problem is that you throw consistency out the window, which also means it's impossible to balance and debug.

[Winhelp]

I know how delta time works. It's just that it's a horrible idea that should never be used in a game under any circumstances.

Now i am totally confused (or I really don't understand what do you mean by "delta time"). What is wrong with this(Free the Physics paragraph): http://gafferongames.com/game-physics/fix-your-timestep/

It is still "delta time" for me and solves almost all problems mentioned.