Davioware's Forum Posts

  • To answer your question simply, they aren't compatible at all, in terms of code. They are VERY different systems.

  • If I recall correctly construct 2 automatically handles object pooling for you. Whether you can improve on the built in pooling with a custom solution depending on your use case is up in the air, you'd have to run some tests. As for the UIDs constantly increasing, that's completely normal behavior. UIDs are to be used as a replacement for reference types in traditional languages like C#. A newly created object means a new uid. They are not tied to the true memory location of the object however, so even if you create a new object, destroy it, and then create it again, the new object might be pooled internally by construct and reuse the same js object, but it will be given a new uid otherwise that would make no sense. At the event sheet abstraction level it is for all intents and purposes a completely new object, even if the back end has pooled the internal object to save GC time at the lower level.

  • NEVER have just one copy of any important project that you keep overwriting every time you save. If the editing software corrupts it somehow or you accidentally save over it or whatever, you can't go back. Every day you should zip your project completely and archive it with a date so you have a kind of "global undo stack" that spans the length of your project, so you can roll back a day if you need to.

  • Is there a reason for switching from C2 to C3 besides "It's newer" ? C2 will still work well for your courses unless you really need that cross platform support.

    I agree that the 2 layer limit is arbitrary. It's just there as a trap for absolute beginners, to incentivize them to subscribe so they can create a HUD without thinking. With so many free engines these days it just feels TOO restrictive though. The "free" version of construct 3 is basically a demo, it's not usable compared to other free engines.

  • You don't need layers for simple sorting or UI. The main purpose of them is layer effects. It would be wise to teach your students how to work around the limit, it would help expand their mind and show them that's there's multiple solutions to a problem.

  • Theoretically, If they decide to shutdown the project (say a company buys them and decides this, for whatever reason), then you're out of luck. Without contact to the license server for a specified period it would probably default back to free mode. It depends how they implement offline use. What would realistically probably happen in this case is that the new company (or scirra) would make the program free, or they would simply stop updating it but continue to allow you to buy yearly subscriptions/pay a one time fee. Or, they make it more expensive... That could happen as well.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • That's not a good solution, even though it'll work in this case (since you only have 50). With larger sizes you'll endlessly hang the cpu as it regenerates and checks the numbers. What you need to do is store all your numbers in a list, (1,2 ... 500) pick a random index from the list, and return the number at that index. Then remove the number at that index from the list and repeat. This way the operation completes in a known time.

  • the dt minimum value can be fixed to fit a 60 fps display so if the game goes under 60 fps, well, it will get slowed down.

    Yes, but a maximum can't be set. The only way would be to set the minimum to something like 600 so it has no chance of ever varying on faster displays. It's still going to run faster on faster displays though.

    using dt is still important to ensure that the result will act the same regardless of the framerate (so a 144Hz display or a 60 Hz one will still be calculated the same).

    Having a fixed framerate completely alleviates this issue, and there's no need for any dt at all. The game and rendering rate are fixed according to system time. that's the whole point of a fixed framerate.

    But apart from performance reasons (executing the logic and rendering at a fixed 30 fps is not as costly), if it is done well, dt ensures that as long as there is no lag or freezes, the game acts correctly and is as fluid as it can (since the movements aren't framerate dependant but time dependant).

    Exactly what isn't wanted, time dependent movement. For most games and applications it's fine, but sometimes you don't want that. It's good to give people control of their game's behavior. Forcing them to use V-sync and the corresponding logic rate isn't something an engine should do. Don't get me wrong, most games SHOULD use V-sync + dt. The game I'm working on now (not with Construct) uses V-sync and dt. But there are times when you don't want or need it. Old games did not use any kind of dt and thus were perfectly deterministic. Some people want that.

    Also I never thought of a single case when anyone would want to use every X seconds with such a low value as 1/60, like why even do this? I don't get it, if your dt implementation is correct you simply don't need nor want that, perhaps I'm missing something (it's early here).

    I'm showing you the only workaround that you can do in C2-C3 to acheive a fixed framerate, but I explained the problems above. The event sheet running at vsync rate makes precise timing impossible, resulting in very jerky movement. It needs to be a runtime option to work properly.

  • They days your game needs to run on different machines with different specs.

    Exactly, and a fixed timestep would fix this. It's not for every game but certain games might want it.

    weve already got a fix cap of 60hz on desktop

    Desktop isn't fixed to 60 though, on chrome on my 144hz monitor the framerate is 144 with vsync on. Anyways, suppose you could just throw everything you want with a fixed timestep into an every 1/60 seconds event and call it a day. If the machine lags, it'll execute once per frame anyway. If we had a way to lock dt in behaviors that would help, because then the logic in those would slow down as well, keeping everything deterministic. And if the framerate is let's say 120hz, frames will be skipped nicely. However... my next point:

    I see no reason to separate game logic from drawing

    Locking the event sheet rate to vsync rate has problems.

    The problem is when the refresh rate is equal to something strange like 75hz (a common desktop rate), when you want a fixed 60hz timestep. then, what happens is that since the true logic rate of the event sheet is vsynced, the every 1/60 seconds event (which is our pseudo fixed timestep) cannot be respected properly. The frame will take 0.013 seconds to execute, fail the time event (since the time accumulation isn't ready), and only check it again once 0.026 seconds has passed (the next vsync, and ~10ms off target). On this frame it'll return true, and execute. at 0.039 it'll be false again and skip that frame, and then next time it will be true again. And so on. Frames are skipped resulting in an extremely jerky "fixed" (not really) timestep. If this was built into the engine then the fixed timestep would be high precision and non jerky.

  • if you are talking about a framerate/tick cap or fix (at 30 say)

    Exactly this.

    but if you do this you would definitely be wanting to use dt for all movement and timing etc...

    Unfortunately no, you would not want to to use dt for all movement and timing. It is not bad practice to use a fixed framerate, the only side effect is screen tearing which in my experience is almost completely unnoticeable. The other trade-off is slowdown when the game lags, instead of choppy movement. Both look and play equally bad in my opinion, and a lot of times slowdown is preferable, to keep the logic deterministic. With deterministic game logic you can do things like an input based replay system.

    Ideally, games separate out the rendering and logic into two asynchronous tick updates, one fixed time-step for logic, and another vsync'd one (with dt) for graphical/ui/etc things which don't need determinism. Using interpolation you can get the graphics to move nice and smoothly at whatever refresh rate you want, while keeping a deterministic time-step for game logic. This allows you to keep the best of both worlds (no tearing+higher refresh rate graphics AND deterministic logic) Unfortunately Construct is more beginner targeted and does not use this type of system. It can be hacked in with events (kind of) but it won't always work well. The next best thing is just a regular fixed timestep, at 60 fps.

  • How do you disable Vsync in C3 and lock dt? For certain games/applications Vsync+a variable dt doesn't cut it. If you want your game to have completely deterministic results you operate off of a fixed time slice. I see you can set the minimum dt to lock it under a certain fps, but how do you cap dt and the framerate on faster refresh rates as well? Ideally there should be a fixed framerate mode and an option to lock dt completely.

  • You can see on the example sheets that the loading of PFX wastes so much VRAM. PFX can fit in a 128x256 texture most likely, but loading it in causes a 256x256 AND a 1024x1024 texture to be loaded. 33x more than the amount of VRAM required. In most use cases this won't matter because you'll be using the other loaded sprites at the same time so they'll be needed anyway, but in certain situations, in games with a lot of art, it could be very wasteful. If every particle effect you load consumes 34x the amount of VRAM required, in a worst case scenario, that's bad. A little bit of control in this area could let devs optimize. Maybe add a field to animations that lets you specify a packing group.

  • I need to be sure everything is being transmitted securely and make it very difficult or impossible hackers to gain an edge. Are there any features that facilitate this, or will I have to do my graphics and all scripting manually in real code?

    You'll have to implement cheat detection/prevention yourself with events, on the server. What do you mean by real code? When you're making a multiplayer game you're going to have to be more hands on at a low level with events. If you aren't experienced at programming you might have a hard time with this.

  • It's the same runtime as C2 so it should be exactly the same in terms of game smoothness. AFAIK right now the only thing different is the editor.

    The reality is that HTML5 isn't good for console export. It sucks for WiiU, and it'll probably suck for the switch. You probably aren't going to get good performance on a complex game with HTML5 on anything that's not a PC. The exception might be Xbox one, since they're trying to unify apps across windows based devices, so they have more incentive to get things working smoothly on that front.

    If you want a game with good performance on all consoles today, don't shoot yourself in the foot from the start by using HTML5.