| 1 |
If lua callins results were only applied on the next frame, would that break anything? In other words, anything that touches the game state would not effect other calculations based on current game state. (Two lua calls that need the dead/alive state of a unit would both 'see' it as alive even if one of the calls killed the unit; callins on unit death would only happen next frame)
|
1 |
If lua callins results were only applied on the next frame, would that break anything? In other words, anything that touches the game state would not effect other calculations based on current game state. (Two lua calls that need the dead/alive state of a unit would both 'see' it as alive even if one of the calls killed the unit; callins on unit death would only happen next frame)
|
| 2 |
\n
|
2 |
\n
|
| 3 |
Ie. In such a scheme, a chain reaction of unit dying leading to lua callin leading to unit dying- etc. Would take a minimum of one frame per unit death because each lua code effect on the game state would not take effect until the next frame.
|
3 |
Ie. In such a scheme, a chain reaction of unit dying leading to lua callin leading to unit dying- etc. Would take a minimum of one frame per unit death because each lua code effect on the game state would not take effect until the next frame.
|
| 4 |
\n
|
4 |
\n
|
| 5 |
I
programed
a
tiny
ui,
event
handler,
engine
setup
because
I
was
curious,
and
was
following
such
a
scheme.
Then
I
found
the
need
to
multi
thread
and
realised
that
my
initial
scheme
greatly
helped
matters.
|
5 |
I
programed
a
tiny
ui,
event
handler,
engine
setup
because
I
was
curious,
and
was
following
such
a
scheme.
Then
I
found
the
need
to
multi
thread
and
realised
that
my
initial
scheme
greatly
helped
matters.
Going
to
multi
was
almost
trivial.
|
Zero-k Running on ONE core at a time!!!