There are two ways that spring to mind:

Either when racing starts you use [ System>Set time scale ] to set the time scale to 0 - which will pause the game. You can then update the counter (either a sprite with animation frames, or a text object) using [ System>Every X Seconds ], and when the counter hits 'Go' or 'Race' or whatever, set the timescale back to 1. The disadvantage here is that animations won't run whilst the timer counts down.

Alternatively, you could disable the parts of your game that allow racing to take place (so disable the car behaviour on the player and other racers, and hold any timers you might be running, until the timer has counted down. At which point you enable the car behaviours etc. This way animations can still be run - but depending on the complexity of your game this could be a lot more work.

Using vanilla Construct 2 (as in without plugins etc) I do this using CanvasSnapshot. Add the action 'Snapshot canvas', which is found in 'System'. You then need to use the corresponding condition, which is 'On canvas snapshot' (also found under 'System' to collect the image. At this pint the image is stored in the expression 'CanvasSnapshot'. You can store this data in a sprite, tilemap, or tiled background by using the action 'Set frame from URL' and entering 'CanvasSnapshot' as the URL.

Beware using this alongside save/load, as the image will be lost. Store the expression 'CanvasSnapshot' into a variable on the sprite, and have the sprite update its frame from the URL provided in the variable when the game loads.

Hey Rojo - I'm just making them by hand. With only 12 layers per floor that means any given decoration etc only has 12 slices to worry about. I draw most features first as a standard sprite (how I want it all to look at the end) before drawing the 'slices', which gives me a good guide on dimensions etc. It's some trial and error - and some stuff just looks horrible.

I Googled Paster - it might actually solve some of the issues I've got with using canvassnapshots as I am at present. Great work!

I'm currently using this trick to make a 3D dungeon - it's working very well so far. I can render about 5-600 of these 'slices' before the CPU usage starts climbing, around 1300-1500 before it goes through the roof. Work within the constraints and it's a pretty usable little trick for 3D fun Right now I've got a three-storey dungeon averaging ~20 rooms, made out of just 36 slices. Plenty of room left for enemies and particles. I'm even handling some collisions in 3D, to allow the player to clamber around the level - I've been amazed at how little these have added in terms of performance concerns. As Rojo points out, static scenery is comprised of single objects, which makes for a huge optimisation, and no limit on draw distances. I just use canvassnapshot to build my slices (not sure what Paster is!) with little to no problem.

Update: Got it - on generation I push all the canvassnapshots to a Dictionary. I save the Dict.AsJson in a LocalStorage value. Works just fine - although loading them takes a while, and will need to be concealed. Marking solved.

Hey guys

So I'm working on my ProcJam entry already, and I've got a lovely way of generating 3-dimensional worlds in slices. This is all well and good and running with a minimum of CPU overhead - I'll document it once I'm done. Essentially it just generates the slices on start one by one, exporting each to a sprite animation frame using canvassnapshot. Again, all well and good.

What breaks it is using save/load functions. If the window is closed, and the game loaded again, the slices are missing, and the animation frames have returned to their greybox placeholders.

Any suggestions on how to retain the generated artwork in-between sessions? I don't want to go the long way round, storing all saveable data separately so that I can re-generate a level from a save array - as I know this will be a bit of a 'mare.

Much love.

When it's pivoting, you can use this:

Angle(Obj.X, Obj.Y, Pivot.X, Pivot.Y) ± 90

To set the angle, and continue moving 20px forward each tick. In this case the ± will be decided by whether the pivot is to the left or to the right of the object according to how it's facing.

In the top-right of the debugger panel you'll see 'Watch' and 'Profile' - click Profile. For a start it'll run faster when in Profiling mode - and it'll give you feedback on what part of the code is using what % of CPU cycles.

Welcome

Have you tried using the Profiler in the Debugger? If you've grouped your code, it's very easy to find offending chunks.

One way around it is to have the offset distance applied by the sprite's width or height (or a combination of the two). So:

Set Healthbar position to:

X: Sprite.X + ( {Offset} * Sprite.Width )

Y: Sprite.Y + ( {Offset} * Sprite.Width )

Where {Offset} is a fixed value that determines how far from the origin of the sprite you want the healthbar to be, this example will give you a healthbar to the bottom right of your sprite.

Where you currently set the width of the bar, in the every tick action, change the value to:

lerp( Self.Width , {NewValue} , dt * {factor} )

Where {NewValue} is the current equation you are using to determine the width of the bar, and where {factor} is the speed by which you want it to animate.