Basically, wrap the C++ class members (startTicks, etc...) into a struct, and have each function take a pointer to such a struct and operate on it (akin to the "this" parameter in C++). This is the simplest example of an "object" in C.
simple SDL framerate?
Author
I see. Perhaps I haven't conveyed everything correctly. I apologize if I haven't. Take a look at these:
timer.h: http://pastebin.com/9tqwGasJ
timer.c: http://pastebin.com/3mW61LEf
main.c: http://pastebin.com/hwmrbEax
these work nice, just like lazyfoo's system. The system's themselves aren't bad, I can get a good delta time, and I see the game running at the same speed on an old Dell Dimension 4550 or a newer custom FX-8350 machine with the dt I use. The problem I am having is locking the game to a framerate. Say it runs at 300fps on one pc and 100fps on the other, even though your monitors refresh rate may not be that high. Say I want to record footage from it using fraps, if the framerate was locked at 60, wouldn't it show me 60 in the corner (before it's recording, i think it changes if you are recording at a different frame rate)? Do you know what I mean?
You need to look into fixed-time updated and separating rendering and game logic.
Fixed-Time-Step Implementation
FIX YOUR TIMESTEP!
Forget about using timers.
L. Spiro
Fixed-Time-Step Implementation
FIX YOUR TIMESTEP!
Forget about using timers.
L. Spiro
Author
I had those in my favorites already. I've used those before, but that doesn't still solve the issue of limiting the games framerate. Fraps tells me the timestep game runs at about 3000fps. I am trying to make it so I can have a capped and uncapped framerate, do you know what I mean? It works perfectly fine in Allegro, but not SDL (I am not talking about delta time, that works fine in both cases). Any time I limit the framerate in SDL with SDL_Delay(), everything seems to "tick" as it moves, even if it is moving with a delta time.
But what is the point in that?
Who cares if it runs at 300/3000/100/60 FPS? It’s not correct for you to limit that.
If users want to cap the frame-rate they can force v-sync.
Say it runs at 300fps on one pc and 100fps on the other, even though your monitors refresh rate may not be that high.
So? Then it runs faster than the refresh rate, 300 on 1 and 100 on another.
What is the problem? Why are you trying to fix break this?
L. Spiro
Author
That was a hypothetical scenario. I just want to cap the game's framerate without having this "tick" issue SDL is giving me (Allegro or SFML did not give said issue). You know how console games tend to be capped at anywhere from 30 to 60fps? That's what I want to do. Half-Life 2 is normally uncapped at 300fps when I boot it up, but I can cap it at 30, 60, or any other fps I desire. That's what I want to do.
Game consoles are “capped” because they have v-sync enabled and you can’t disable it.
Again, if the user wants a cap on his or her PC, he or she can enable v-sync.
L. Spiro
That was a hypothetical scenario. I just want to cap the game's framerate without having this "tick" issue SDL is giving me (Allegro or SFML did not give said issue). You know how console games tend to be capped at anywhere from 30 to 60fps? That's what I want to do. Half-Life 2 is normally uncapped at 300fps when I boot it up, but I can cap it at 30, 60, or any other fps I desire. That's what I want to do.
You seem to be confusing the concepts of frame rate and game speed (see the article I linked to below).
Ticks in SDL are a solution rather than an issue. As for SFML, did you use sf::RenderWindow::setFramerateLimit() or sf::RenderWindow::setVerticalSyncEnabled()? The first calls sf::sleep(), the latter does what @L. Spiro mentioned. Either way, you need to understand what's going on under the hood.
Consider reading deWiTTERS Game Loop, a well-known article about this topic; in particular, I think the Constant Game Speed with Maximum FPS section could help.
Author
I am really confused now. I'm not sure every console game has vsynch enabled, maybe a buffer, but i'm not sure. You and I may have a different definition of framerate, look at this:
[attachment=22477:timestep_fps.PNG]
fraps shows me the framerate the game is supposedly outputting. Take a look at this:
[attachment=22478:ocarina_fps.jpg]
Ocarina of Time was capped by Nintendo to operate at 20fps. I'm pretty certain not every game on the Nintendo 64 is 20fps. Here's a picture of Half-Life 2 uncapped:
[attachment=22479:hl2_uncapped.jpg]
I can cap it's framerate to 30 if I want, and I can visually tell it's not as smooth as if it were capped at 60fps (or uncapped in general):
[attachment=22480:hl2_capped.jpg]
and it's not vsynched
[attachment=22481:hl2_novsynch.jpg]
So I am really confused all by what you are telling me. Maybe i'm not saying the right words. How is that measurement capped? If I make a game, i'll make a setting so it's capped at 30, 60, or uncapped.
georger.araujo, I saw you replied while I was typing this. I will take a look after I post this.
I'm not sure every console game has vsynch enabled
Every console and mobile device has v-sync forced enabled.
All frame-rate capping is done by syncing to v-blank.
Frame-rate (FPS): Number of times the game is drawn per second. The yellow number in your images.
The question still remains as to why you want to do it on PC (you don’t have a choice on consoles or mobile devices, just a few options as to which cap you can use).
Do you think it is just cool?
Do you think it makes your product “pro”?
When a game company puts a cap on the frame-rate there is a reason.
For example, we developed a bunch of games for Xbox 360 and PlayStation 3. We aimed at 60 FPS (the max you can do) but in some games in some areas we had to reduce to 30 FPS (every 2nd v-blank). For Infinite Undiscovery and Radiata Stories there was too much to draw within a single v-blank so again the whole games had to use 2 v-blanks (30 FPS).
If Nintendo made a game run at 20 FPS it is because they needed more time to render, not because, “Oh, FPS caps are the cool new thing.”
Half-Life 2 is doing the same thing. Their reason (something you lack) is because their games were fairly heavy on the CPU (and GPU) back then and would consume a lot of power. Forcing the FPS down reduces power consumption and heat generation, but that won’t apply to your games. You are not a huge team of experienced veterans making a multi-million-dollar AAA title.
And even if you did have a reason to use a cap, it is implemented via v-blank. It is always implemented in relation to v-blanks to prevent tearing.
If your SDL does not give you v-blank access, give up and move on to the next task. Any other way of doing it will lead to the same problems you had before (after some time there is a 1-frame jitter), and you don’t even have an actual reason to do it in the first place. Your time is better spent anywhere else on your project.
L. Spiro
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
