Submit
In response to reply on Delta Time vs. Frame Rate
A638aa42130293f319eda7fa4ba121f4
1
fireside 141 Jan 26, 2014 at 19:59

Try giving it an even slower frame rate and see if it changes anything. If you use Reedbeta’s code, you can use any frame rate. If the frame skipping stops with a slower frame rate, then you know that you aren’t getting the times fast enough. If it’s the same no matter how slow the frame rate, then you have a logic error somewhere, and it’s not in Reedbeta’s code, so you may have changed something without knowing it. What I’m wondering, and why I put that pseudo code up, was if you are sure which frame is skipping? Are you positive it’s the third frame? That’s why it would be good to have it actually print the current frame to see what’s what. I really find it hard to believe that glut can’t get the times fast enough, unless you are trying for a really high frame rate or something.

In response to Delta Time vs. Frame Rate
6837d514b487de395be51432d9cdd078
2
TheNut 179 Jan 26, 2014 at 17:48

You mentioned frame skipping because of timing. I don’t know what GLUT is doing behind the scenes, but it’s possible its timer resolution might not be good enough to keep up with your frame rate. Each timing function on an operating system has a minimum resolution, and it depends on the hardware as well (what works for you might not for others). Take for instance the WIN32 call timeGetTime(). It has a default 5 millisecond resolution. I think clock() has a 10ms resolution, which is quite bad for low-latency applications like frame rates and realtime sound mixing; however it has its uses and is not as expensive to call compared to higher resolution timers (ie: use the right tool for the job). On the other hand, if you want micro second accuracy you should use QueryPerformanceCounter. In fact, every game engine should have a “StopWatch” class that uses a high resolution timer. Not only can you use it for controlling frame rates, but also in physics and particle simulations as well as measuring runtime performance of your render pipeline, various function calls, etc where timing is important.

In response to HTML 5 is rubbish ?
6837d514b487de395be51432d9cdd078
0
TheNut 179 Jan 26, 2014 at 17:04

I use JavaScript to get the dimensions of the browser page window and update the canvas accordingly. I plug this in the <body onresize=''> event so that it scales with the browser window. It looks like you’re also setting the body margins to 0px, which is a good thing to do as well.

HTML:

canvas id="MyCanvas"

JavaScript:

var canvas = document.getElementById("MyCanvas");
canvas.width = window.innerWidth
canvas.height = window.innerHeight

BTW, as spolsh mentioned, it would be nice to have a preview/syntax guide for markdown. I too have difficulty getting certain things to work. I use DokuWiki and Confluence all the time and this markdown stuff keeps messing me up :)

In response to HTML 5 is rubbish ?
7aeee6bdf472f8cc5d7853b2b5aae133
0
spolsh 101 Jan 26, 2014 at 14:02
<html>
<head>
</head>
<body>
   <canvas id="c" width="800" height="600" style="border-style:solid;"> </canvas>
</body>
</html>

Only added style to your first try so you can see the dimensions. Works for me. tested on chrome and firefox.

btw. How to fix code markup?

In response to reply on Delta Time vs. Frame Rate
Adfa6cf87d3749a0e1acd928285b3f23
0
WDR 106 Jan 26, 2014 at 09:09

I’m sorry, but I didn’t get you. It’s not because of the code tags. I didn’t understand what you did there. Please explain. Thanks.

In response to reply on Delta Time vs. Frame Rate
A638aa42130293f319eda7fa4ba121f4
1
fireside 141 Jan 26, 2014 at 01:49

It should start with zero.Do something like: I can’t get the code tags to work for some reason but:

lastFrame = currentFrame; currentFrame = //get times and change to int; if(lastFrame!= currentFrame) //print lastFrame;

haven’t used c++ for a while, but cout lastFrame if it changes.

In response to reply on Delta Time vs. Frame Rate
Adfa6cf87d3749a0e1acd928285b3f23
0
WDR 106 Jan 26, 2014 at 01:08

I AM doing that! Here’s what’s happening… The accumulated time for the, let’s say, 5 frames is coming out as, 1 for first frame, 2 for second frame, 4 for third frame, then 5 for fourth frame, and so on. When it gets to the third frame, it is not 3, but 4. Here is where the frame skipping occurs. Is there something that I can do in this method or use a completely new method that uses elapsed time of the loop to perform the animation? Please help. Thanks.

In response to reply on Delta Time vs. Frame Rate
A638aa42130293f319eda7fa4ba121f4
2
fireside 141 Jan 25, 2014 at 22:47

You have to zero out when you reach the number of frames in your animation. If you have a 5 frame animation that loops, then you have to zero out your accumulated time after you play the 5th frame. Other than that, it should work. Pretty clever idea of Reedbeta, but you could just as well play the animation and zero out the accumulated time after it was greater than the frame rate and cycle the animation.

15b49ecb37f32eca4d5db9ef199d4cd5
0
ReadySetRetro 101 Jan 25, 2014 at 16:03

Available February 6th on the Apple AppStore

In response to reply on Delta Time vs. Frame Rate
Adfa6cf87d3749a0e1acd928285b3f23
0
WDR 106 Jan 25, 2014 at 15:52

Hello again… Would you please elaborate more about how to use the accumulated time. I used it to animate my sprites using the method you described, but at one point the accumulated time gets incremented so much that it causes a skipping of frames. The sprite jumps from frame 1 to frame 3 directly. How would I go about doing the animation smoothly without that happening? If it is any help, I am using glutGet(GLUT_ELAPSED_TIME) to calculate delta time and accumulated time in OpenGL. Please help. Thanks.

In response to A voxel renderer
40fd50c8665e5b5f4233e4c0587a9d47
0
17_Gen_r 105 Jan 24, 2014 at 20:38

It is not that fast actually. Back-face culling should cause much better performance but UD makes do without. A novel thing occurred:

Suppose you are being given a pyramid P & a cube C. Narrow P horizontally & vertically about C with C still in that narrowed P i.e., P’. Let the rectangle R be the intersection between P’ & the view plane. If R not occluded then if R small enough or C is a leaf, output R in the color of C. Otherwise, apply this procedure to P’ & the octants Ci of C, in front-to-back order.

The above admits of a filth-less formulation, meaning free from /, * or those heinous floats. See Q*.c except *M.c in the archive (second link). Am I the only person trying to reverse UD on the whole Internet?

In response to reply on Delta Time vs. Frame Rate
Adfa6cf87d3749a0e1acd928285b3f23
0
WDR 106 Jan 24, 2014 at 18:28

Funnily… That actually happened. The sprite sped up on a higher spec PC which gave a higher frame rate, which is why I opted for variable frame rate where the frame rate is calculated based on delta time. But, since you said both frame rates are independent of each other and fixed frame rate on sprites is unaffected by window frame rate, the accumulator method seems like the ideal method to use in this case. Thanks again, Reedbeta! Your help was once again invaluable to novices like us. Up-repped your post. :-)

In response to reply on Delta Time vs. Frame Rate
A8433b04cb41dd57113740b779f61acb
2
Reedbeta 167 Jan 24, 2014 at 18:06

Yes, the sprite’s animation will have the same smoothness. Well, if the game runs at a framerate lower than the sprite, then the sprite will be just as jerky as the rest of the game…but that would be a pretty extreme scenario. :)

I’m assuming you don’t want the sprite to speed up just because the game is running at a high fps.

In response to reply on Delta Time vs. Frame Rate
Adfa6cf87d3749a0e1acd928285b3f23
0
WDR 106 Jan 24, 2014 at 17:58

OK, Reedbeta… So, the sprite’s movement is independent of the delta time. Well, not completely independent, but not directly multiplied with the sprite’s frame rate as I thought. I didn’t really find anything on accumulated time in my search, but I completely understood what you explained above. I still have one doubt though. You say the sprite’s frame rate is independent of the game’s frame rate… Does that mean, even if I give a constant frame rate such as 10 fps, my sprite’s animation will have the same smoothness irrespective of whether the game window is running on a low frame rate or a high frame rate? Please just clear this one for me. Thanks.

In response to Delta Time vs. Frame Rate
A8433b04cb41dd57113740b779f61acb
2
Reedbeta 167 Jan 24, 2014 at 17:39

Looks like you’re calculating the delta time correctly. If you want the sprite to cycle at, say, 10 frames per second, then each frame would be shown for 1/10th of a second. Therefore you need to accumulate delta time and swap frames when the time passes 1/10th of a second.

So you’d create a float member in your sprite class to store the accumulated time since the beginning of the animation. When you create the sprite or start a new animation you’d initialize that to zero. Then, each frame, do something like this:

Sprite.Accumulated_Time += Delta_Time;
Sprite.Current_Frame = (int)(Sprite.Framerate * Sprite.Accumulated_Time)

That way, suppose Sprite.Framerate is 10, you’d have Sprite.Current_Frame come out to zero for the first 1/10th of a second, one for the next 1/10th, two for the next 1/10th, etc.

Note that the sprite’s framerate is independent of the game’s, here. The sprite will run at 10 fps always, even if the game runs 60 fps or 5 fps.

B20d81438814b6ba7da7ff8eb502d039
1
Vilem_Otte 117 Jan 23, 2014 at 02:53

No, just no - it’s already too huge in my opinion. I like simple standards, not overcomplicated.

A638aa42130293f319eda7fa4ba121f4
1
fireside 141 Jan 22, 2014 at 05:32

I think it goes counter to what c++ is all about. It’s always stayed as just a language, even if you count STL. Languages like Java that get into things like that have really gotten bogged down and become specialized.

868af2b1008f30c80a06e5b1ac3d37c5
2
dzada 103 Jan 21, 2014 at 21:17

Hello

1.@dk Just to mention, they do not want to include Cairo in the standard at all. If you read the proposal they want a simple 2D graphics interface in the standard and explained why not starting from a c++ lib, and why cairo was an interesting starting point.

2.@TheNut One of the writter (H Sutter) is in charge of c++ devs at microsoft and explains how a 2D interface could be standardized and be based on Direct2D behind.

3.@gasto this is not about language standard but standard library. stdio is as much domain specific as 2D could be. you don’t have to link it, but if you do, it could be nice to have a well designed interface that is STL compliant, you could maybe change your runtime if you want. Anyway a lot of company are currently reimplementing all this for tablets and PC portability by using openGL primitives so it sould not be bad to consider something that everyone does and that is pretty basic.

best

In response to reply on OpenGL Texture Compression
A8433b04cb41dd57113740b779f61acb
1
Reedbeta 167 Jan 21, 2014 at 20:55

Compression formats are all standardized, so it doesn’t matter which vendor’s tool you use.

NVTT contains a library that you can link into your own projects, as well as a set of command-line tools, and Compressonator is a graphical tool (it may also have a command-line interface; I’m not sure). Also, NVTT is open-source while Compressonator isn’t. So it all depends on what you’re looking for.

88dc730f0f71e55be39de0ad103bd9ff
0
Alienizer 109 Jan 21, 2014 at 19:36

ok, it’s sounds and look really cool but, are the movements that of what the NN learn? or is it learning as it goes? What prevent it from moving off screen? I guess I’m still not clear on how you get NN to work with what’s on the screen. Is every pixel an output from your NN?

194653f6bf54cad70a7cf97e6b7f35a4
0
benrawlesmusic 101 Jan 21, 2014 at 16:57

I’m going to the Steinway Hall in London next month to show some new stuff I’ve been working on! scrolls through Heisenberg bowler hats

6837d514b487de395be51432d9cdd078
2
TheNut 179 Jan 21, 2014 at 15:57

Guaranteed won’t pass. It would start a chain reaction where next follows 3D, then audio, then physics, etc. All of those APIs could become standards too, but one quick look at history will show you that people are so different, can never agree on anything, and don’t like a single solution. And a standard isn’t a standard unless people adhere to it. I doubt Microsoft, Sony, Nintendo, Apple, Google & co will be willing to sink mega dollars into implementing that standard when they already have their own designs and technologies.

In principle though, C++ is a language and should remain that way. Improve the language and its syntax, let the community produce substance with it. APIs improve over time, become easier, more flexible, more innovative, more up-to-date. You can’t do that with a standard. STL vs Java and .NET BCL is a fine example of API evolution.

In response to reply on OpenGL Texture Compression
Adfa6cf87d3749a0e1acd928285b3f23
0
WDR 106 Jan 21, 2014 at 15:14

Since we are on the topic… Does the Compressonator for ATi GPUs work for nVidia GPUs? I know there is one for nVidia i.e. the nVidia Texture Tools but overall reception on the internet about that tool is mostly kind of negative.

Ff5202ba30e6f1939125be77d81d1dae
1
gasto 102 Jan 21, 2014 at 14:21

It is random to support domain specific libraries in a language standard.

B5262118b588a5a420230bfbef4a2cdf
1
Stainless 151 Jan 21, 2014 at 10:56

Hell no.

Hell hell no

Worse idea since someone said “hey that Hitler bloke, he’s kinda charismatic. How about we make him leader”

Welcome to DevMaster, a community-driven game development website of posts and resources!

Recent Tags

indie × 5
game-development × 5
ios × 3
android × 3
iphone × 1
c# × 1
mobile × 1
physics-engines × 1
native × 1
macos × 1
sound × 1
music × 1
multiplayer × 1
networking × 1
testing × 1
game-programming × 1
design-patterns × 1
3d-engine × 1
shaders × 1
cross-platform × 1
gaming × 1
game-design × 1
game-industry × 1
graphics × 1
royalty × 1