Ashley's Forum Posts

  • Still, this is definitely a bad idea. What does it aim to accomplish? Religious advertisements shouldn't be allowed, fullstop...

    I totally agree, I think no adverts of the type (atheist or religious) should be allowed at all. But if this campaign makes that happen, then that's a good thing - I don't think you'd get far trying to ban all religious adverts unless you also get atheist adverts. You risk looking anti-religious otherwise, whereas we can now argue we simply don't want beliefs shoved in our face on the bus.

  • The best way I've found to avoid spammers picking up your email address is incredibly simple... just throw some tags in there. Eg. ashley<a name=""><b></a></b>@<i></i>scirra.com.

    Not only can visitors directly select the text and copy-paste it instead of copying it out manually like you have to do with images, but AFAIK spammers don't yet bother parsing HTML. For them to start doing that would significantly complicate their efforts and cost them more processing. If you're ultra-paranoid, generate it with javascript!

  • Because you're using 'Compare values' in the system condition (by the looks of it), the values returned will be for the first instances only, and it won't pick any of the objects meeting the condition (it just compares the raw numbers). The 'For each object' condition should solve this, you can try adding 'For Each box' or 'For Each marker' just after the overlap condition. (Not sure which object to use, depends on what you're doing)

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

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

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Use a global variable to only play it once.

  • Tick 'Global' under 'Common' properties.