Hi!

I came to openfl from love2d and first thing that struck me down was how to organize game code. In Love2d I got 3 functions for load, update and render vars/objects and now I got confused in openfl. I know that openfl depends heavily on events. I found on openfl's github page sample file demonstrating how to main loop but I still doesn't understand whats the difference between game loop and event loop.

I tried to find answer on google but english isn't my first language,

If anyone can explain it to me I would be very grateful

ok not related to openfl, but the principle should be the same, here is a basic explanation…

a basic game loop goes somewhat like this:

// pseudo
int main( )
{
	...
	
	while (!end_of_game)
	{
  		read_or_poll_input() 	// check state of keyboard, mouse, joyst... here
  		update_game(dt) 		// update the game state based on input and some time since last render
  		render()				// render the new game state
  		dt = ...				// update/fix your game time step
	}
	...
}
	

a basic event loop goes somewhat like this:

// pseudo

class some_class
{
	...
	void tell_me_what_has_happened( event X )
	{
	  if (X == A/B/C)
	    then I'm in interested do something( )
	}
}


class event_class;
...
int event_class::create_my_events()
{
	create_event(A)
	create_event(B)
	...
}

void event_class::register_for_event_A/B/C......(some_class s)
{
  add_to_A/B/C...queue(s)
}

void event_class::notify_registered_(X)
{
	for (i : get_listeners_for_A/B/C/..queue(X))
	   i->tell_me_what_has_happened( X (A/B/C) )
}

void event_class::start_event_loop()
{
   while(!end_of_game)
   {
   		// this could be input eventing
   		I = read_or_poll_input()
   		X = should_i_generate_a_new_A/B/c_event(I)
     	notify_registered_listeners(X)
     	
     	// or it could game eventing
     	X = NPC_health_has_dropped()
     	notify_registered_listeners(X)
	}
}

int main()
{
	some_class s1, s2;
	
	event_class s3;
	
	s3.register_for_event_A(s1); // tell s3 that s1 is interested in s3's event A
	s3.register_for_event_A(s2); // tell s3 that s2 is interested in s3's event A
	s3.register_for_event_B(s2); // tell s3 that s2 is interested in s3's event B

	create_thread[]
	{ 
		s3.start_event_loop( )	// this is usually a blocking call that can be executed on a separate thread
	}
	
	// Put game loop here //
}	 

i tried to simplify this, but it could still be confusing… so:

• if u still don't understand then look here: https://gameprogrammingpatterns.com/event-queue.html​
• if u still don't understand then look here: https://www.gamedev.net/tutorials/programming/general-and-gameplay-programming/effective-event-handling-in-c-r2459/​
• if u still don't understand then we have a problem ?

That's it … all the best ?

https://gameprogrammingpatterns.com/event-queue.html​ -wrote :

“ You only need a queue when you want to decouple something in time.”

Events like mouse click need some code in order to be processed, so event handler provides it by linking to other block of code (from external file for example). And (event handler) does it only when proper event call in event loop (which is basically while loop) is dispatched. Because it is needed right now.

And game loop also process input from user (mouse click etc.) How does it differ from event loop?

the game loop and the event loop both process input. Great, so we can say that we have established that there's no difference there (i.e. processing input);

so how do they differ?

the difference is in:

• how they store the input data and when that data is used: a game loop read-or-poll's job will usually be called to ONLY store ALL CURRENT states from all inputs, it will read the current state of all keyboard keys, mouse state, joystick, etc… (so no queueing of data involved). This means the next time the game loop calls read-or-poll, there is a chance that it may have missed some input states from those inputs (due to slow loop iteration). If your game doesn't care about the loss of those states then the CURRENT state being read again will suffice. But if your game does care about ALL (lossless) input states that's when queueing is needed

So depending on your game needs, you can have an informative system designed like this:

• poll + queue (i will find out what the current state is but -dear system- let me know when input state is available and what state it is because i could be losing some due to slow game loop)
• poll only (i don't care about losing input states, i'll be fine with any current state)
• or queue only (let me know when input state is available and what state it is)

And usually when u poll, u store all the polled data in an array, for examples:

unsigned char keyboard[ 256 or 1024 …. ]; etc…

and events are usually queued in vectors, lists, or system queues…etc…

hope this clarifies it a bit more;

have fun ?

YES! Thank you. This clarify a lot ?

Often there is also an “event bus”, basically a broadcast system. Basically any system or object can register a callback for an event, and when the event happens the callback is launched immediately.

An “event queue” is similar, often per task or per process. Then can be on a per-listener basis, or they can accept all the broadcast events. Instead of being processed immediately, the work is delayed until a known time.

Often there are specific known times, such as pre/post update, pre/post render, pre/post load, pre/post save, etc. There are good reasons to attach on to many different times, such as not destroying something until after processing is complete, or running initialization after load is complete, etc.