Demo of a missile seeking behavior and a nice flame/smoke effect. Not sure what I would use it for. Code is pretty clean and easy to follow. Toggle random target pos and mouse control with X key.
Uses some code for timers in my snippets repo https://github.com/unstoppablecarl/pico-8-snippets
v2
v1
That is a fantastic plume effect, even disregarding the fact that it's done with a limited, fixed palette. I am jaw-on-floor impressed with that.
The seeking is nice as well.
Indeed very nice (60 fps mode really shines here).
Edit: ouch! 38% cpu for a single missile - need to find a GPU for Pico ;)
Note: I usual, you can shave a lot of cpu cycle by replacing:
for x in all(xxx) do ... |
by:
for _,x in pairs(xxx) do -- or for i=1,#xxx do local x=xxx[i] ... |
For this cart, cpu goes from 50% to 38%
Because pairs() is internal to lua, it's able to iterate over the internal hash maps that Lua uses for tables. On the other hand, all() is an iterator written in actual lua and costs about 20x more cycles per iteration.
The tradeoff is that pairs() does not guarantee an ordered traversal, but all() does, which is why it needs some extra wrapper logic.
In this case I would need to use all() for the draw calls right?? They need to be in order to look right.
Are they in a sequentially-indexed array? If so, you'd be better off using a numeric for:
for i=1,#particles do particles[i]:update() end |
This has only a few cycles of overhead, 1 for the loop iteration and (I think) a couple for the array indexing. This, versus 20 for the all() iterator.
You seem to be using add/del to manage your array, so they should be sequentially-numbered.
just adding to what Felice said:
If I'm not mistaken, the only unique advantage of all() is that you can safely del() items in a table while iterating with it. (besides the token advantage over other loops which is sometimes what matters :p)
nice rocket exhaust btw! :D
nope - pairs can be iterated while doing adds & dels (doing that all over the place in my particle systems!)
Agreed, pairs() isn't a sequential iterator, so messing with the sequence won't cause problems.
ohhhhh got it. wow I don't know why I never realized that XD
actually I think it was probably because the manual specifically notes that you can del() items while using all() and a loong time ago I must have misinterpreted that as saying it was like a distinguishing feature and therefore the primary reason for its existence :p
but I guess the small character-count (and single return value which further contributes to that) is really the biggest distinguishing feature of all()
anyway, sorry to derail the thread
I thought so too. strange that it is something to be avoided.
[Please log in to post a comment]
