I did some basic tests of the concept I described. The code is pretty darn simple.

Always: Set Count 1 * (60 * timedelta)

This value basically is equal to how many ticks of logic should have ran at this point. 60 can be whatever you want your logic rate to be.

For the test I used a black box coded to move with the code.

While

-Count Equal Or Greater Than 1

And then had the event as

Subtract 1 from Count

Set Position X (X + whatever)

I tested it alone and then injected it in my game so I could test it under stress. The results were pretty great -- it seemed no less attractive than the normal, low FPS movement yet, if it were a more complex engine, would be far more accurate in terms of pixel exact movement (probably at an impercievable cost of time accuracy). I'm thinking this could be programmed to use the loop function but I'm not sure how that handles I take it it runs each loop event once then repeats instead of going, say.. "loop event A 3 times. Loop even B 3 times. Loop event C 3 times."? I don't have the time to test right now.

Still, construct at low FPS seems extra stupid ugly for some reason. Maybe it's just my code in general? Who knows, but heres my thought. My idea of time scale smoothing for frame rate is a little weird and as I think about what I would do if I was making a game from the ground up would more involve not letting the FPS jump wildly in the first place -- Basically even out in frame updates instead of on a timescale basis. Would that sound more like a reasonable developers decision, Ashley.

With this process I'm still sort of concerned about properly linking animations to the logic refresh rate, but as I think of it it might not be a problem (though as I'm using animations as almost a timing function, I'm a little anal about this -- but I think I'm in the VAST minority). Thoughts on this? I could upload examples but it seems pointless as it's such an easy little setup. I might try plugging my entire engine in like this at some point and testing that to see how much the logic eats away at the framerate.

Thoughts anyone? I'm particularly curious as to what you think, Ashley, especially because this direction would mean less work for you -- but I'm not sure if it'/s the right one. It seems good and intelligent to me, but I'm a fake programmer.

I can only begin to imagine what the next year will bring. Congratulations!

(In this thread, Kayin posts an image thats way too big)

http://kayin.pyoko.org/albums/userpics/reesedragunov2jpg.jpg

^^ To see the thing in a way that fits.

<img src="http://kayin.pyoko.org/albums/userpics/reesedragunov2jpg.jpg">

I think Dawkins is too extremist in his views,

Signed.

Dawkins irritates the hell out of me sometimes. This seems pretty cool though. Not cool enough for me to drop a few bucks, but cool

I checked out the link you posted Kayin - it's a very good article, the best I've read on the subject. However, I'm still not convinced by variable rate logic. Firstly, as the article mentions, it could substantially increase CPU usage, especially with a high logic rate. Secondly - and I don't think the article covers this - if logic runs at a rate which is not a multiple of the V-sync rate, then you can get uneven motion. Lets consider easy numbers - VSync = 50Hz and logic = 75fps - for every VSync you alternate between 1 logic update and 2 logic updates. This means between screen updates, objects will move twice as far every refresh. I don't think this would look as smooth as the current system we have. Interpolation is an interesting idea, but I fear it's too difficult to retro-fit it to our current engine (and it would make eventing a custom movement much harder).

Well glad it was a good article and a good read! Yeah, which seems why a much higher logic rate would be better -- with obvious potential problems. It'd be nice if there was a good way to tell how much cpu the logic in comparison to the display. Just for theory sake. But anyways a lot of this will depend on how easily you can program it and have it work appropriately. What issues would this have with custom movement engines, for example? is it a more technical issue?

Anyways, as I think about it,the best way to handle this might be on the event list side. Say a loop-esque feature that times an event for x times a second. Basically, updating the chosen logic at the rate desired (sort of like setting it on the timing but it will interpolate how many times it has to run it per tick). I'd set this like a function. Like

-On Independant Logic "hurfdurf"

--Game jumping/moving logic.

and then like

-on start of frame

-- set Independant Logic Rate "hurfdurf" 100 cycles per second

This might even be doable with stuff already provided. The only problem involved in this is that animations would likely not sync up appropriately and we would need some way to control that. I personally like setting all animation speeds to zero and manually forcing 'tick' updates on the animations, but thats just seems like what would be the easiest answer from my view.

Assuming there was some option to run logic at a multiple of the vsync rate (eg. 5x logic runs per vsync), and assuming timers and user input were updated between these separate logic executions, I guess it might be possible to reduce the inaccuracy by reducing the quantisation effect error. I think this could be programmed like Motion Blur, but without the rendering of logic-only runs.

[quote:1u9nnqgi]

If it's easy to program, I might give it a shot. I don't think I can truly have keyboard input update fairly in logic-only runs, but it might work. It is a very CPU intensive way of solving the problem though - I have no choice but to execute the full event list, not just the motion/timer based ones, in logic-only runs. And I don't know if it'll even help solve the problem significantly. What do you think?

By the way, I've noticed fullscreen games run with very consistent timedelta values - they are usually exactly equal to 1 / vsync rate. It's only windowed games which suffer random timedelta variations, probably because Windows treats fullscreen apps with a higher priority.

I thank you for considering this as always and hopefully we can come up with a solution to the problem some of have. I don't see how this wouldn't solve the problem -- more the issue I;'d more think is if it'd cause more problems (by being stuttery or something). Maybe I'll take a stab at making an engine that does this with the available features as a proof of concept (ignoring animation issues).

Awesome to know, thanks guys. I figured that'd be the case, so thats good to know.

Anyways, as for the animation, a counter wouldn't really work. The problem here is that i need to be able to control how many ticks a particular animation stays out. Currently all my animations are set to speed 60 so I can exactly control how long everything lasts on the screen. If this was a simplier game (IWBTG), I could just use dead/repeat frames, but considering how many frames of animation I'll need in my current game, this just isn't sensible. To adequately do my own animation system I would have to have a string for every animation (or maybe just use an array) that lists all the animation data I need. That'd sort of suck.

Again though I'm just tossing out ideas and possibilities. I want to hear Ashley's thought on how sensible they are.

I don't know if this is any help, but if i'm ever in the situation where i need a little more accuracy in my movement engines, i make a little 'for' loop

Make a global varible called like, 'MovementAccuracy'

change the sampling to linear

And then at the start of layout (or change initial value) set it to the amount of accuracy you want

I usually set it to around 50, the higher it is, the more accurate you will get, although i'm not sure the cpu load it would have if you made it too high

Then do something like this

when right arrow is down

--for "Move" from 0 to global('MovementAccuracy')

== Set Player.X to Player.X + 200 * (timedelta / global('MovementAccuracy')

(the -- indicates a subevent)

(the == indicates an action)

Basically, the 'logic' runs 50 times per tick (or however many you set your global to) as opposed to once per tick, but you still get to use timedelta and use all your cool motion blur and timescaling stuff!

Apply that to your jumping code or moving code or whatever and it's pretty much pixel perfect

I had an example running at 1 fps that only went one pixel out

Or another method i suppose would be having variables like: "JumpStart" and "JumpMaxHeight" and make it so when the player jumps, the jumpstart records the Y value at 'ground level' and set jumpmaxheight to the jumpstart minus however high you want him to jump.

Then if the difference between the player's Y and jumpstart goes beyond jumpmaxheight, manually set the distance and code in the falling. Although i suppose this method would be a little harder if you weren't using a custom movement, and for REALLY low frame rates it might still require the use of that 'For' loop i just mentioned

I hope i made myself clear

This... actually seems like a potentially good idea. Granted what you said is not far off from how my engine already works, but it makes me think of things a little differently. The implementation I'm now thinking would be say.. use time delta to figure out how many times to run accuracy essential logic and run it X amount of times. I used to figure this wasn't reasonably possible, but if I'm looping the essential logic say 5-10 times normally, adding or subtracting a few reps should keep things in speed.

The problem for me though is still keeping animation properly in since (which operates with delta-time in mind). It's essential for me that animations line up exactly when they should. Any way to get around this would either involve... making my own animation engine from scratch or........ Bugging Ashley to implement a feature only I'll ever use (Something like telling an animation to advance a 'tick frame' instead of a whole frame of animation). Which is a waste of time. Alas. But for our opening poster, maybe this would work!

Anyways, Ashley.

http://allefant.sourceforge.net/wordpress/vsync

Nothing professional here and I'm sure a lot of stuff you already know. Still, it talks about the whole logic vs update thing I talk about. So at least my thoughts are somewhere on base and not some unique fabrication. Again for professional examples, I think they'll be hard to find simply because, well.. Again, theres not a lot of professional level 2d computer games these days. Though as I read around, I see a lot of this stuff mentioned, though nothing solid enough to further waste your time with.

I also saw some stuff mentioned somewhere about netplay like I said earlier about FPSs and how relying on delta time for a networked game could be a bit weird. I don't know how accurate that statement is, it's just what I read from some random internet person.

Edit: Actually now that I think of it, adding a feature like the one I'd need wouldn't be that hard I don't think and might be more generally useful. Just a command like "Random Object: Advance Animation X ticks". all the user would have to do to do what I want is set animation speed to 0 for whatever objects they want to control. Not saying you should do this, but I think it might be a valid option. I'm just brain storm thought.

Also: I'm curious how collision detection works. If I were to manually run logic several times a frame, would collisions work properly on the 'inbetween' updates, or do collisions only take into account the final or previous displayed state?

> While I'd still like to see a more processor intensive mode that runs every bit of logic at 60fps (or whatever), I don't think Ashley is ever going to go for it

>

Is this the idea of running logic at one rate and the display at another? I still don't understand how this confers an advantage. Sure, I could get the logic to run at 60fps, but if your display runs at 75 Hz, even with V-sync on, the display would update irregularly. I can't imagine it looking very nice at all! You may as well go fixed framerate if you want that.

Perhaps a higher logic rate would be better! I'm not sure though how much the logic load would be. I really can't debate that one though. Only semi example I can think of is how FPSs run game logic server side and correct the clients predictions. Not sure thats even a good idea.

[quote:36ghe52w]I'd never, for example, make a fighting game in construct. Anyone who would is crazy.

Why? What is crazy about it? As far as I know, all commercial fighting games either adopt a timedelta or fixed framerate approach. Is that bad? Do they fail in some particularly important way?

Well true I could use fixed framerate. But I know for example I can play Guilty Gear XX #R on the PC with V-Sync and I have never seen something happen that shouldn't of. If there was ever an extreme drop in framerate, the actions would resolve themselves. Same goes with Melty Blood for the PC. Theres actually a hack for advancing gameplay one tick at a time for both thats used for hacked netplay. I don't know how this is accomplished. it might just be sheer superior programming.

[quote:36ghe52w]

[quote:36ghe52w]So why is Delta Time inaccurate?

I'm not sure a widely varying framerate is responsible for TimeDelta inaccuracies. The timer Construct uses is extremely accurate (it can also be used to time sections of compiled C++ code down to microseconds). I think variations simply come from the 'quantization' effect of the game framerate. Even if you had an atomic clock accurate to picoseconds, this clock is only measured every 0.01 seconds at 100fps. The inaccuracy therefore comes from events which in the real world would happen between frames - eg. 0.005 seconds after running the logic. Since the logic only runs at 100fps, the event is delayed until the next frame.

Consider an object moving at 100 pixels per second at 100fps for one second. You'd expect it to cover 100 pixels, right? If there is a small variation in the framerate, the object would correctly only be set to 'moving' for 99 of those frames - or maybe 101. This is a deviation of TimeDelta * Speed, or in this case, about 1 pixel either way (a total of 2% error). I think the similar formulae for acceleration magnifies this a little bit more, maybe to 3% or 4% (I haven't done any specific tests here). Still, I maintain this variation is not significant enough to mean anyone should redesign their games!

I'm just theorizing here. I have test results but no knowledge of constructs code. All I know is that when the frame rate is jittery, things are inconsistent -- noticably so to the player (which is bad. A few pixels is okay since the player wouldn't notice them). So I THINk this happens say..... You jump. You're on the last 'tick' of your jump but now the frame rate is lower. Lets say, worst case scenario, something happens and your frame rate drops to 10 (it happens). That last tick would now move six times farther! Thats what I think happens at least and its's the only way I can rationalize this. Maybe you can shed more light?

[quote:36ghe52w]

[quote:36ghe52w]Anyways we use GetRefreshRate to get the baseline speed we want based on the computer. From there the process becomes something like... storing the FPS values for every frame say for the last 60 frames...

1 / TimeDelta gives you the framerate by the way. This is an interesting idea, but I can't see how it helps. The whole point of TimeDelta is it means time in the game-universe proceeds at the same speed as in the real world! Tweening timedelta values sounds like it would break this. Also, I don't think any commercial games or engines use this method. I would be very interested if you found a case of this being used professionally. Part of the reason I am reluctant to use ideas like this is because if it was a good idea, I'm sure the professionals would be doing it - so I'd be a lot more attracted to your idea if you found some examples of its usage.

Yes, but if I'm using time override, wouldn't that not give me the real framerate? Which is the problem.

Anyways, I can't answer this. Theres not a lot of 2d platformers developed for the PC these days professionally. They have the mixed blessing of being designed for a console where they can be certain of things like framerate (but a million other hassles). I do know I've seen FPSs that start slowing down after a certain point instead of skipping frames. Especially during short spikes. as I've noticed. I might have to do some research on this. I think the reason though you wouldn't see this again, you don't see a lot of PC based, high precision 2d games.

[quote:36ghe52w]

Since Construct's timer is very accurate, the gameplay still proceeds at the same rate even if the framerate is jumping wildly between 10fps and 90fps. The only difference is that the quantization effect is worse at low framerates. It might LOOK jerky - but that's only because the display is updating at an irregular rate (note this happens with logic and display at different rates). Imagine filming a car with a special camera that takes frames at irregular intervals and can play them back at the same speed they were recorded. Sure, the car would look like it was stuttering along - only because of the display updating irregularly. In the real world, the car moved perfectly smoothly.

Now a situation between 90 and 10, yeah, theres not much you can do. But I find that the display just doesn't look good under any sort of stress. I'd expect anywhere around 30 fps to look decent and be playable. I want to do this, even if it's not usual, just because I'm dealing with what I got and want things to work as well as possible. The limitations on are end as the user probably prevents many methods used by professional programmers. I see a solution that makes lower framerates look smoother and eliminates one of my problems with accuracy. I think slight flunctations in speed is worth the tradeoff. Ic ould be wrong though and may change my mind after implementing it, but I'm in fairly good mind that'll help things a bit.

[quote:36ghe52w]

[quote:36ghe52w]This is just going to keep coming up. I know you might not quite understand, but some of us are crazy or making games where we sincerely think this is necessary.

I don't think you need to design your games to NASA precision. Again, find me a commercial game that adopts a different system to one available already in Construct. I'd be very interested.

If I can I certainly will!

Okay, just use time override right now. just do it. I'm constantly bugging Ashley about stuff related to this and have done tons and tons and tons of testing. While I'd still like to see a more processor intensive mode that runs every bit of logic at 60fps (or whatever), I don't think Ashley is ever going to go for it (even though it's worth it for some people for that level of precision. I'd never, for example, make a fighting game in construct. Anyone who would is crazy. As an example).

But hey, we gotta work with what we got. Ashley has at least helped me make this situation a lot more manageable and recently agreed to implement some features that would allow great control over how the game speed works.

So why is Delta Time inaccurate? Construct has decimal based X/Y positions! It should be perfect! -- well not quite, as framerate flickers a lot, especially under load. usual flickers don't cause much of a variance (far less than 1%) but unstable framerate (For example, a quick drop to 10 fps due to some other processor load before jumping quickly back up) can cause some spectacular differences (10-20 percentin some tests. Not a common scenario but it can happen). So how can we fix this? We can't RIGHT NOW, but we can later.

Okay so this is my plan as someone who is also looking for a lot of precision. I've asked for GetRefreshRate, and GetFrameRate and SetTimeOverride. If we don't get one or two of these it'll be because there are otherways to go about it. Either way the capability will be there.

Anyways we use GetRefreshRate to get the baseline speed we want based on the computer. From there the process becomes something like... storing the FPS values for every frame say for the last 60 frames. Then periodically taking those values, cutting off the lower end extremes and finding an average. The time delta then slowly drifts toward that value over over the course of a bunch of frames. The exact process and values would have to be tested but this is the concept. What will it do? It'll smooth everything out, speed wise. Sudden/larger bouts of frame drop will slow down instead of jerking and skipping forward. You can even set a minimum framerate to use where say, if the framerate goes below 30, the game just slows down. All these things should not only make things look less jerky at lower FPS, but drastically reduce the problems of accuracy in delta time mode. You probably won't be able to be pixel perfect, but you can be 'a few pixels perfect'.

But we can't do this yet, so just use time override and develop your game. Before your done, these features will become available. When I get this system to work I'll be sure to share it with everyone in case they need something similar.

Oh and just one more time to say this to Ashley. Like i said. I wasn't going to be the last. This is just going to keep coming up. I know you might not quite understand, but some of us are crazy or making games where we sincerely think this is necessary. Heck, I'm scared of things that aren't even necessarily positionally related (but can't make a fuss about stuff I can't test yet). You might still want to consider a more 'extreme' solution, even if it doesn't make sense to you. Either way, I'll appreciate what I can get/have gotten.

> includes seem to produce anomalies as per the example I sent you before, Ashley.

>

Could you make a .cap that demonstrates events working differently in an include?

[quote:18kxujpe]Secondly I'd ike to request a "Local Sheet" feature. so that each background has one dedicated sheet that doesn't muck up the sheet list.

Each background? Huh? Don't you mean each layout? But each layout already has its own event sheet...

[quote:18kxujpe]also while I'm at it, getRefreshRate and GetFPS plzkthx -- and if you're really nice, set override to make things easier

Meh, okay, I'll try and get them in a build... but I'm not absolutely convinced they're necessary. You can measure the FPS with events by the way, look up Ticks on the wiki.

Yessir. http://kayin.pyoko.org/53.cap Just set the main sheet to base1 instead of core. Core shows how it's supposed to work. If you ue base one and jump into walls weird thing happen (like you stick). Seem slike only one part isn't working or something.

They do have a local sheet feature? I looked for it before posting (aaaahhhh why did I put background). Okay, nevermind that then.

As for measuring FPS, wouldn't that get screwed up by delta time override (which is why I'm requesting these feature)? Especially if I start changing the timescale my self to adjust game speed in a more fluid manner?

Though now that I think of it I could multiply/divide the milliseconds for the check by the timescale or whatever, couldn't I?

Anyways, thank you and no rush. I just don't want to work with the assumptions I'll have something later and then be stuck without it, I appreciate it. Though if I can do some of this stuff without it (though refresh rate I think would be important), I will.

Okay, first, even though it's reported as fixed, includes seem to produce anomalies as per the example I sent you before, Ashley. If this is somehow the correct behavior I'm curious as to why it acts the way it does. Secondly I'd ike to request a "Local Sheet" feature. so that each background has one dedicated sheet that doesn't muck up the sheet list. I don't think it'll be uncommon for people to want to have a list for each stage, using includes to insert the elements they want or don't want -- but after a good number o backdrops, the number of sheets could be in the realm of ridiculous (My current project I think would have a few hundred, I think. D:).

(also while I'm at it, getRefreshRate and GetFPS plzkthx -- and if you're really nice, set override to make things easier. I'm going to keep pimping these until I get some form of response. XD)

Ah, a topic I have strong opinion on (IE: All my opinions. )! Anyways I think Deadeye is right, through and through. Which saves me a lot of posting, but I will still elaborate.

First, I think the definition of art is something that needs to be understood a bit. Okay. To a degree, everything is art. A teacup made by a silversmith, even if plain is still a form of art. It is art as a craft. Basically every human creation can fall under this to some degree or another. But that definition is not important. We need to be talking about SIGNIFICANT art. If your definition includes "All games are art!" Its not really a useful distinction from a discussion point of view. The same applies for all media. Epic Movie and Citizen Kane should never be in the same category of 'art'. From here on out when I say 'art', I mean significant art.

What type of media has the highest percentage of 'art' in professional works? Paintings, clearly. Why is this? Paintings are a limited media. You can not tell a narrative in a painting (unless you use several!). It's hard to be 'funny'' in any significant and long lasting way in a painting(but it of course, is -- and hard enough to then roll back to being art). You have to be very symbolic, expressional and technical to portray a feeling, emotion or lesson with any sort of accuracy.

Movies on the other hand , while definitely possessing artistic entries, has a wiiiiide variety of indulgent movies. Comedies, slashers, big explosions. They don't need to be art and sometimes we don't WANT them to be art. But still, the controls are in the hand of the director and crew and, when desired, an artistic vision can come forth.

Games are like this only worse because you have to compete with the players desire to 'express' himself. The more 'art' you inject into your game of a significant level, the more restricted you are -- granted this is true for almost any gamer addition -- but art does not directly add to the game experience.

Everyone oozes over Passage. I think it's garbage. It's spoon fed symbolism with no actual "game". Why? It wanted to be art more than a game. It crafted it's artistic message and then, shoehorned a game in there. It's like cliche student art films that barely qualify as 'movies'.

Braid and SoTC were designed with no story in mind and no art inherent to the core concept. Jonathan Blow literally made Braid and phoned in for the art and plot (okay maybe not literally, but it was all done after the majority of the game was made). If you watch the early SOTC trailer, you see they clearly had no idea what they wanted to do, plotwise. They wanted you to kill giant, awesome things. They then crafted a beautiful story that fit into those confines, rather than fitting a game into the confines of the story.

and hell, sometimes games are just better as 'not art'. I liked Bunny Must Die a lot more than I liked Braid(not to diss on braid). It was awesome in ways that would not lend it's self well to being art, even though it and Braid were designed with the same base mechanical idea (time control). Jonathan Blow wanted something gentle and friendly that wanted to at least lend it's way to some nice, relaxing, artsy style (he just didn't care what it was yet). BMD gave you a cat girl in a bunny suit with a machinegun.

Besides, no one can agree to what 'significant art' is anyways. Being art is over rated -- and I'm an artist and game developer (IWBTG was totally not art)!

As for the art game I'd make... I'd make an art game meant to pander to the indy game jerkoffs who eat up the dribble that qualifies for 'art' to them and then have the ending rub it in their face -- that they got suckered in by a game with no purpose and meaning.