In response to reply on Delta Time vs. Frame Rate
0
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
2
140 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.

0
101 Jan 25, 2014 at 16:03

Available February 6th on the Apple AppStore

In response to reply on Delta Time vs. Frame Rate
0
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
0
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
0
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
2
165 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
0
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
2
165 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.

1
117 Jan 23, 2014 at 02:53

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

1
140 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.

2
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
1
165 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.

0
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?

0
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

2
178 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
0
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.

1
102 Jan 21, 2014 at 14:21

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

1
146 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”

0
104 Jan 21, 2014 at 09:21

this video kinda explains it, you can see it working better, it just has a feature for every cell, it similarity matches to it by itself… so the end product is a subset of the total features.

but… its not really working properly :) im still working on it.

In response to reply on OpenGL Texture Compression
0
146 Jan 20, 2014 at 09:19

in the old days!

I STILL have to decode manually on some platforms. :<

A lot of set top boxes and TV’s have really good GPU’s, but since texture compression is not a requirement for OpenGL ES, just an optional extra, many devices don’t support it.

0
102 Jan 20, 2014 at 07:06

I used the form on their website, after contacting Juan directly from my email he replied the following day. There might be something wrong with their form, however i own an apology.

0
106 Jan 20, 2014 at 04:02

Well, I am not much of an artist, just basic Photoshop. Uni2D seems a bit out of my reach. Just wanted to know whether my sprite alignment method was right. Thank you, TheNut. Your help has been great so far. Giving both your replies the up arrow (like button?) beside the post. I’ll be sure to ask if I have any more questions! :-)

EDIT: OK… So, it increases the rep. Cheers.

2
178 Jan 20, 2014 at 02:56

The easiest way to animate sprites of different sizes is to enlarge the canvas so that all frames are the same size and are centred in the image. This way the animation appears proper for all frames, but also leads to texture waste.

For tightly cropped sprites, you have the right idea. You need to pin a source object and have your sprite offset to align correctly with the animation. This means your transforming the actual rectangle and not the texture. So when your sprite frame increases in size by 20 pixels, you need to enlarge your rectangle to compensate, and then offset it so that the animation is pinned correctly. This is pretty tricky and some artists I know do this by hand. They have tools and whatnot to help them, but generally it’s quite manual.

A alternative solution is to look into skeletal sprites. For example, you can checkout this tool for Unity. Break your object down into smaller pieces that you can join together into a skeletal structure. This isn’t always possible though, so it depends on your needs.

0
109 Jan 19, 2014 at 23:52

just how did you manage to do that with NN?

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

android × 3
opengl × 2
animation × 2
indie × 2
opengl-es × 1
rpg × 1
film × 1
royalty × 1
music × 1
licensing × 1
glsl × 1
ios × 1
linux × 1
audio × 1
gui × 1
contest × 1
native × 1
web × 1
hardware × 1
testing × 1
water × 1