Ashley's Forum Posts

  • Do you mean you want 'marker' to be 0 for when it's not overlapping? You could just set it to 0 in an Always event just above it.

  • I've read about this on the news - I think Dawkins is too extremist in his views, but it's definitely an interesting project. Quite often I see slogans on buses telling me to go read the bible, I don't see why we can't have these adverts as well!

    I wonder if in future advertising belief systems will be big business... "Hey you, believe in this!"

  • Can someone send me a .cap that clearly demonstrates this? With just one object if possible...

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • In a recent build a crash was fixed which required that newly created objects don't really "fully exist" until the next event tick. You can use them in the same event that created them, but the next events won't treat them as existing until the next tick. It's a bit of an annoying quirk but it seems it's the way the engine has to work, in order to avoid other crashes in the event engine that have been reported. In this case, the 'For each' subevent to the start of layout event will not consider the tanks created in the same tick, but the 'for 1 to 8' loop will. As Linkman pointed out, you can do everything in the same event anyway.

    As a side, you don't need any of the for-each loops in the 'Pick tank' groups. The conditions work like that normally.

  • when right arrow is down

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

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

    This is essentially saying:

    + Every tick

    + Repeat 10 times

    -> Set X to X + 1

    instead of:

    + Every tick

    -> Set X to X + 10

    In other words it's identical to the simpler one - the only advantage you get is if you do all your collision testing in subevents (collisions are checked on-the-fly when the condition is run). Then the ONLY advantage you get is fast objects are less likely to skip over small obstacles. It won't directly solve any problems with accuracy.

    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).

    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.

    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.

  • It looks like a graphics card glitch. Maybe try updating your graphics card drivers?

  • the particle sprayer is there so you don't have to make your own...

    That's true, but I'm not sure it's worthwhile making the particle spray object increasingly complicated with more and more properties and controls until it can completely match what you can do with Sprites. If you want 100% flexibility, I think the best thing to do is just use Sprites - it'll run just as fast as using the advanced controls on the particles object.

  • Yeah, my course is keeping me a lot busier this year...

  • Welcome to the forums Construct is primarily a 2D game development tool - but you can do some very basic 3D stuff with the 3D box object. I'm not really sure if Construct will eventually turn in to a full 3D tool, partly because I'm not sure it's possible a decent tool like that can exist, and secondly the barrier of entry to 3D development is much, much higher than for 2D.

  • 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.

    [quote:1a2fp02h]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?

    [quote:1a2fp02h]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!

    [quote:1a2fp02h]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.

    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.

    [quote:1a2fp02h]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.

  • Use a global variable to only play it once.

  • Tick 'Global' under 'Common' properties.

  • I tried enabling the override already with very weird results. You would get randomly stuck in the ground for example. And since it doesn't fix the different speeds anyway, doing the events without TimeDelta would be basically the same, right?

    Sounds like a bug in your code - by chance, without override, you might get the same sequence of timedelta values - so I doubt that is directly caused by timedelta override. And yes, your application becomes framerate dependent again. However, you can still use timescaling, and you have the useful ability to turn off the override and go framerate independent again!

    [quote:1f2b8n6i]Using round(.X) etc like Arima suggested is a quite good method and gives better results. But still you may get stuck where you shouldn't or detectors that are supposed to stop when they overlay solid objects actually stop 1 pixel before. Therefore other events may not be triggered...

    I wouldn't advise this purely on the basis it will make motion less precise and you lose the smooth rendering.

    [quote:1f2b8n6i][quote:1f2b8n6i]MMF suffers exactly the same problems regarding refresh rate and speed of gameplay as Construct

    But then I don't understand why my MMF stuff seems to run exactly the same speed on the tested 60 and 85hz with no special settings, just plain set X to X + 1 stuff. I know I'm stupid but I don't really get it.

    I think by default it uses 50fps fixed framerate, V-Sync off (so the display tears). 'Fixed framerate' is a misleading name, because the gameplay speed is still completely framerate dependent anyway: if a low-end computer can only run the game at half the intended framerate, the game only proceeds half as fast. And bleh, tearing displays aren't nice :-

    [quote:1f2b8n6i][quote:1f2b8n6i]If you absolutely insist on it being pixel perfect (and I still struggle to get my head round why this is absolutely necessary)

    Like it says in the wiki:

    "However, some specific games (such as low-resolution pixel-drawn retro games) require movements to be exact to the pixel."

    At least I'd like to get close to the pixel perfect optimum. Maybe I should just start using many more pushout events or whatever you may call them.

    Yeah, I wrote that - but I'm starting to disagree! You might argue that in your game your player can jump exactly 32 pixels high so you fill your level with 32 pixel high blocks to jump over. Then you turn on timedelta, and you get a 3% random variation, which means 50% of the time you jump ever so slightly less than 32 pixels, and you can't clear the obstacle. I think the correct action in this case is to design a game with 30 pixel high obstacles! In other words, allow for the small random variations. I can't see how this would be a serious issue if you are just starting out your game. I think it would make very little difference - and then you can use motion blur, timescaling, v-sync quality display, framerate independent runtime, etc. etc...

  • MMF suffers exactly the same problems regarding refresh rate and speed of gameplay as Construct - there are just different options available to handle it. In Construct, I strongly recommend you code your game to simply take in to account the 2-3% random variation caused by timer inaccuracies. It's not much and shouldn't affect your game much. If you absolutely insist on it being pixel perfect (and I still struggle to get my head round why this is absolutely necessary), you can enable the TimeDelta override in Advanced application properties. You can have your game V-syncing for high display quality, and have TimeDelta return a constant value so it plays out identically every time. However, this means your game will run faster on 85Hz monitors than 60Hz monitors. I have heard of 120Hz monitors, so it could be as much as twice as fast. But that's why TimeDelta exists. It's designed to solve that problem

  • I personally just use number variables for flags - 1 for on and 0 for off. I'm perfectly comfortable using it considering I'm from a programming background, but if you prefer, you could just as easily use text like "yes"/"no", "y"/"n", "on"/"off", "true"/"false" etc...

    If you use a number you can toggle it with 1 - value (1 - 1 = 0, 1 - 0 = 1), or with text you could still use: value = "yes" ? "no" : "yes"