TOUCHES_BEGIN and ENTER_FRAME serialized?

marc

Just wanted to be sure, Gideros** calls these event listeners serialized, doesn't it? (at least on for same scene graph stage?)
If not, my Lua code will now have a possible race condition, because I don't like superfluous code in Lua...

**or OpenGLES or Android touch api etc

marc

did ..anyone understand what I mean?
sometimes I'm bad at explaining..
or... is it just an unknown subject?

i looked at the activity .java but i couldn't spot any of the keywords for this matter..
and the rest is closed source, isn't it?...

thanks for any information

OZApps

@marc,
maybe it wasn't understood.

Do you mean are the events queued up? if there are say a series of ENTER_FRAME events and because your code is (let's say for arguments sake) slow and still processing the first ENTER_FRAME.... then YES, it will queue up for you to clear and handle.

With touches, you tag the touches (in a multi-touch) and if it is a single touch, there's hardly an issue.

marc

Ok, that (queing up the input events and calling them before ENTER_FRAME) is kinda what I need/expect. But I also mean the way round, that BEGIN_TOUCHES is not run reentrant, regarding ENTER_FRAME.

I mean, currently I have code in the BEGIN_TOUCHES handler that does:

1)
stage:addEventListener(Event.TOUCHES_BEGIN,
function(event)
global_thing_for_rendering_is_initialized = true
initialize_global_thing_for_rendering() -- only now
end

And I'm curious if with Gideros I'm actually supposed to write:

2)
stage:addEventListener(Event.TOUCHES_BEGIN,
function(event)
initialize_global_thing_for_rendering() -- already now
global_thing_for_rendering_is_initialized = true
end

I know, "safe" code would try to be prepared like 2) against the reentrancy or closed code issues of any kind, but as soon as I know what I'm allowed to do, I like to write the shortest possible and laziest (Lua) code, and that will sometimes be like 1) ....

PS: ..I know, Gideros main loop looks most probably like this
call_qeued_touch_events()
call_enter_frame_event()
But I've got no source to look at... :-?

OZApps

@marc,
I still do not get what you are after, looking at some of your pseudocode, I think you are trying to do something like

the app starts and does nothing, you touch the screen and it starts to do whatever animation, etc

If that is correct.... then

in your ENTER_FRAME handler

if not can_start == true then return end   -- your code to do whatever you wanted to do

In your TOUCH_BEGAN handler

if not _started == true then initialise_to_start() _started = true end   can_start = true

I hope that helps you, or else you will have to be more specific on what you are trying to achieve.

marc

In your example, could I write it also this way?

can_start = true   if not _started == true then initialise_to_start() _started = true end

When you know two functions (in this case the two handlers) won't run concurrently, you can. And when you can, it's easier for prototyping a game, because you can - most of the time - write it where the cursor is.

In contrast, when you have to write those things always at the end of a block, this takes more time, overall.

And since I can't know how Gideros runs these handlers, I felt I had to ask.

OZApps

@marc, you can write as you want, however there is a reason for writing it the way I did, good practices.

if you set the can_start first before initialisation, you *can* run the risk of allowing the ENTER_FRAME event to run once on an uninitialised environment.

as for your sentence,

When you know two functions (in this case the two handlers) won't run concurrently, you can. And when you can, it's easier for prototyping a game, because you can - most of the time - write it where the cursor is.

In contrast, when you have to write those things always at the end of a block, this takes more time, overall.

I did not quite understand what you mean there. What do you mean by write where the cursor is? and at the end of a block, this takes more time, overall...

Hope that your main issue is resolved.

Just out of curiosity, what do you do? Student/Work/Retired, IT/Non-IT

marc

if you set the can_start first before initialisation, you *can* run the risk of allowing the ENTER_FRAME event to run once on an uninitialised environment.

Do you mean, in general, because of early returns, gotos, continues, exceptions etc? Ok, this is actually true. I should follow this practice just for this reason.

But I couldn't stop thinking about whether the two handlers are really serialized ("sychronized" keyword in Java etc), and whether my badly prototyped code was able to crash or not.

With the "where the cursor is" etc. I meant, that sometimes I'm too lazy to follow good practices, keeping something in order etc. So I'll write something just somewhere, as long as it will work while creating the game.

I think my issue is resolved, I'll write it just as you suggested. Thanks for the help
I'm a Non-IT guy, doing a bit of everything for a mobile game.

OZApps

@marc,

glad that you get somewhere and can move forward with that.

it is always nice to have good practices in place, it means the difference of a minute to hours when trying to debug and find errors/bugs.

eezing

@marc

Not sure I quite understood the original question... but as far as I know, because the code you type is running on one thread, Lua will just throw an error if something isn't valid. I think the worst thing you can expect from lazy code is poor performance.

ar2rsawseen

@marc everything in Gideros is run on a single thread and every function executed as atomic, there is no possibility of changing variable value inside enterframe, while it is used in other function, they are not concurrent

marc

@marc everything in Gideros is run on a single thread and every function executed as atomic, there is no possibility of changing variable value inside enterframe, while it is used in other function, they are not concurrent

thanks