Ashley's Forum Posts

  • I personally do not see much wrong with this thread; it is a sensible discussion of some people's opinions. However, out of respect, I will lock this thread and end discussion of it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Objects don't really count as created until the event finishes. Use your workaround - when the fastloop is triggering, the object's in it's quasi-existing state. You can use the created object normally in the same event, but triggering a loop and using it in other events before the end of the event will not work as you expect.

    It's a strange quirk of the engine but also a fairly well-known one - it has to work this way I'm afraid (it's involved in a number of bug fixes that involved crashing events).

  • AWESOME! This is going to make a great game

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