Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

Calling destroy in Entity update function crash the game #409

Open
Meoo opened this issue Jan 1, 2017 · 4 comments
Open

Calling destroy in Entity update function crash the game #409

Meoo opened this issue Jan 1, 2017 · 4 comments

Comments

@Meoo
Copy link

Meoo commented Jan 1, 2017

Destroying an entity in update function crash the application at Scene.hx:514
The "entity in entities" iterator is invalidated when the current entity is removed from the list, causing a null exception.

@ruby0x1
Copy link
Member

ruby0x1 commented Jan 1, 2017

One usual approach is to defer the destroy till the end of the frame (start of the next frame) by using Luxe.next(function() { entity.destroy(); }).

@Meoo
Copy link
Author

Meoo commented Jan 1, 2017

Alright, I see.
I can't use Luxe.next directly though, because it's bound to Snow ticks, and as I'm using fixed timestep my game can have multiple updates within a single tick, but it's not the same problem.
I'll fill in a Snow ticket soon since I can't see the way I could fix this myself (it also impacts input system).

@ruby0x1
Copy link
Member

ruby0x1 commented Jan 1, 2017

I think I get what you mean though, are you using the fixed tick rates from snow app level or are you doing it yourself?

You can limit the rate of update() calls using snow (via luxe also iirc) to get update() called at a fixed rate btw. There are two calls actually - the tick happens as fast as the system will run it (with a slight rest for the os), and then update() is limited either explicitly by the update rate settings or implicitly by the vertical sync and rendering.

You can tell it to give you a fixed delta, call update at a fixed rate, and there is also a fixed_timestep (ref) version which calculates the alpha time to interpolate your visual updates against. Those can also be mixed in variations.

How were you approaching it?

@Meoo
Copy link
Author

Meoo commented Jan 1, 2017

I am using Luxe.fixed_timestep and Luxe.fixed_frame_time, 128 updates per second and no interpolation for rendering. For some reason, with the exact same code it is much smoother than per frame delta time and vsync.
I always have 2 to 3 updates per frame, and on one computer with intel graphics I even manage to have 0 (I still don't understand how though).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants