Hi !

Don't use a "every x seconds" trigger condition for this ; if the actual framerate is slower, or not a multiple, of your time, it's not guaranteed to run at regular intervals. It's not a flaw in the "every x seconds" block, it's just bad logic.

Use a timer you update every frame with dt to make sure events like that happen at a fixed frequency.

E.g in pseudo logic :

every tick >

timer -= dt

while (timer <= 0.0)

{

dostuff();

timer += interval

}

(this version ensures that if the frequency of the event is much higher than the actual framerate, the logic can run multiple times every frame ; this may or may not be desirable depending on the case ; change the "while" to an "if" depending on the requirement)

[quote:3u2ngezv]"I wasn't aware that the tint effect would impact performance"

Anything can affect performance ; whilst tools like C2 are quite high-level, in terms of abstraction, understanding how it works internally can be useful to explain why things are the way they are.

Basically, by having unique sets of shader attributes per instance, you prevent the system from batching similar objects. The hardware is very efficient at processing large amount of identical data ; the more you make the data unique, the more the objects have to be broken down into smaller groups, each generating drawcalls with specific render settings and shader parameters.

It's much faster to render 10.000 triangles with the same attributes than 1000 triangles with unique attributes ; in the second case, you spend most of your CPU/GPU time in the pre-render stages and the driver overhead.

There's always a trade-off between CPU/GPU time and memory/video memory, and a balance to find between these. If you don't need to dynamically colour sprites, just bake predefined colours into texture atlases ; you'll burn a bit of memory, but the geometry will be quick to process.

There isn't a universally "better" way of doing this, it all depends on the application and the external requirements.

I guess the context is that it's being used in front-end logic ; if that's the case, 'just use the UIDs to know which element (button, sprite, etc.) is being pressed.

No need. [...] Far more versatile this way.

This.

Personally I'm all in favor of less built-in behaviours, and keep/request only what is really saving time. The more generic, the more constrained ; and the more automated, the more limited. Therefore if people rely too much on default behaviours, they ask for new features as things never exactly fit their needs, to a point where the behaviour becomes too complicated and counter-productive to use.

Continuing with the example of the directional movement, some people might want crouching, some might want dashing, some might want double-jump, some might want animations for jumping at specific angles, etc. Or any combination of the above, e.g. dashing while jumping at specific angles. Should all these become attributes of a default behaviour ? I don't think so, as some of the requirements are likely to be conflicting.

It's much easier to use the building blocks and create the logic required for each game specifically. It's much more flexible, and reusable.

Also, if a similar structure is used anywhere else ("every x seconds..." with very short time steps), they should be converted to dt logic as well, otherwise the game is likely to have some imbalanced elements depending on platform performance (shooting faster/slower, moving faster/slower, etc.)

Few things should run at fixed timesteps, if any, and these should always be at a lower frequency than the minimum game framerate to guarantee you don't accumulate delays and errors.

Maybe... if you have animations for moves like dashing, falling, etc. use larger hitboxes specifically on these to counterbalance the movement speed. Assume a minimum framerate of 15fps, and given the size and speed of your object, and the size of other entities, you should know the size of a hitbox that can never tunnel through enemies or environment bits.

[quote:3k8y5269]it only happens on my iphone. On my desktop, it didn't happen a single time and i checked that a lot of times

There is a correlation between framerate, object size and object speed that explains when tunneling can or cannot happen. What I meant when I said the framerate was "irrelevant" is that 30 or 60fps, or even 120fps, doesn't guarantee consistent collision detection ; if you had smaller or faster moving objects at 60fps, you could see the same issue.

Commercial games use solutions that work decently in all situations ; for example a bullet in a first person shooter, a small and fast moving object, is never actually a bullet from a physics representation point of view, it's a line, and physics raychecks are used to compute collisions so that bullets don't through thin walls.

As for doing this with C2... No idea, honestly. But the problem is well-known.

'Hope that helps a bit !

Tunneling is an inherent problem of collision detection using discrete timesteps ; the framerate is actually irrelevant, as this can always happen as long as an object is moving "fast enough" (compared to its size).

I haven't used the physics module of C2 yet, so I don't know any good solution from top of my head, but see if you find anything that relates to continuous collision detection (CCD, raychecks, extrusion, etc.) ; otherwise you might have to do some linecheck or swept surfaces manually.

Alternatively, maybe use an additional bigger hitbox that's big enough given your level design to prevent tunneling ; knowing that when your larger box detects a collision but your smaller one doesn't, a collision *might* have happened, and you'll need more computations to know what actually happened

'Just to add to the WiiU performance discussion -

WebGL is a JavaScript API ; while some consoles have built-in support for WebGL, no console is expected to run games in a web browser. All modern devices have support for either DirectX9/11/12 (PC, XBO, etc.), OpenGL (Mac, Linux, etc.), OpenGL ES (mobiles, FireTV, etc.) or OpenGL variants.

Usually consoles are powerful enough so that exporting a non-native simple game and using a wrapper to map compatible layers of abstraction is a viable option as the performance overhead is negligible for small applications.

WiiU supports OpenGL ; but the GPU is based on an old-ish R700 (custom AMD, HD4xxx, very close to a HD4770) and the architecture is a bit exotic (little video memory, shared pool, etc.) meaning it's imperative to have low-level programmers optimising for eSRAM use to get anywhere with performance. Also, publishing on WiiU has some unique certification constrains (using the gamepad display, etc.)

As a result, all of these together mean that porting to WiiU is usually a non-trivial task, the console requires lots of specific work and optimisations ; which also explains why it's usually left out when games are published on PC/Xbox/Mac/PS or mobile platforms iOS/Android.

Scroll to the mid-point between the two players (+/- offset you want to make it easier to look ahead in one particular direction, for example), and then constrain the players to the visible area (simple rectangle clipping) so that they can't leave the screen

Basically, you don't scroll to a player in particular ; you compute the area you want to frame, based on the position of the 2 players, and you prevent the players from going beyond that area

Just to add to the discussion -

"Old-style" performance timers have also become less and less accurate and reliable due to more recently designed CPUs scaling their internal clocks dynamically (downclocking or upclocking, on a per-core basis, up to the max frequency they are sold for). Therefore you have to query the system's frequency very regularly to try to keep in sync, and you're never guaranteed the clock speed you got a few ms ago is still valid and/or is a good approximate for the core that executes your instruction.

Low-level high resolution timers are definitely the most reliable solution. This is true for desktop computers, but also consoles and mobiles.

As for fast moving objects and collisions ; it's much easier to make a consistent physics implementation at a stable fps (which is why certain physics modules of game engines usually run at a different constant frequency, e.g. 15 or 30 fps), and use continuous collision detections with swept surfaces/volumes specifically for objects that require it.

Niiice I'm really glad to see some regular updates on this ! Being a megatroidvania-fan, this seems Epic !