Not logged inGosu Forums
Forum back to libgosu.org Help Search Register Login
Up Topic Gosu / Gosu Exchange / Game Loop and Drawing in the Update
- - By Basic Date 2011-07-05 08:43 Edited 2011-07-05 09:04
I was wondering how this worked, I would try this but I am traveling about at the moment and dont have access to windows atm.

I know that drawing in the update() is generally not a good idea, however I am trying to add some stuff to Gosu and it seems legitimate for the time being.

iirc simply calling the drawing commands queue up the requests which are then blitted at the end of the draw call. So why would it be a bad thing to call the render functions in the update method?

On a side note: I noticed that the game loop is (on Windows)

Process Messages (Draw)
Update

Is it guaranteed that WM_PAINT will be called each tick? While it stops sending the message when its minimised etc, I thought it wasn't a sure bet it would be called, which could lead to an update update draw no?
Parent - - By jlnr (dev) Date 2011-07-05 10:48

> which could lead to an update update draw


Right. I guess there are circumstances where Windows might decide to draw your windows a second time too, so you might end up with update draw draw. And then there are three other platforms… :) What are you trying to achieve?
Parent - - By Basic Date 2011-07-05 12:54
I want to make gosu event driven as that is generally the first thing I do when I start a prototype or some such, I was digging in the game loop to try and find out what the effects of calling drawing functions in the update cycle. Which is when I noticed WM_PAINT etc.

I have looked at the drawing queue as well, I dont see much actual problem calling drawing calls from the update method as they get queued anyway. Am I missing something for that?
Parent - By Spooner Date 2011-07-05 13:25
I use Texplay's render_to_image in update (which draws to the screen, flushes, then pastes the screen area into an image). It works cross-platform, but jlnr told me that he couldn't support that always working. If it stops working, I'll have to wrangle it a bit to make the drawing happen at the start of the draw phase instead, but that would be messy.
Parent - - By jlnr (dev) Date 2011-07-05 15:03
It is unexpected behavior from Gosu's side. Even though the current system is very clear with the queues, I am free to change the implementation any way I want and it would break your gem. And I don't know how your game would react to draw-draw-update or update-update-draw, but I guess it could detect that.

What do you mean by event-driven? I am still trying to understand the use case.
Parent - - By Basic Date 2011-07-05 15:16
In the way that buttonUpButton down are single events, the last bunch of uni projects I've used use an event system which goes along the lines of

class Player
{
    /* some code */
    void update()
    {
        SomeEvent event;
        /* some code */
        eventManager.triggerEvent(&event, PLAYER_MOVED_MSG);
    }
};

class SomeEnemy
{
    /* some code */

    void eventListener(void* data, int msgID)
    {
        if(msgID == PLAYER_MOVED_MSG)
        {
            SomeEvent eventData = static_cast<SomeEvent>(data);   
            /* react to the event */
        }
    }
};

This is a (very) rough example, dont do it this way :) But I think it shows what I mean.

Essentially I was thinking about adding this to Gosu, and adding buttonEvents into this. I know I can easily write this on top of Gosu for each application, and essentially that is what I was going todo, but I was thinking about adding drawing operations into the event system, which would mean that the update would be calling the drawing operations, although I could queue the ops, however Gosu does this anyway.
Parent - - By jlnr (dev) Date 2011-07-05 17:23
I see. The event system itself doesn't really conflict with the drawing, you could just have void draw() { eventManager.triggerEvent(REDRAW) }. It's the mix of logic and rendering that I am not sure I want to support in Gosu. It's too bad that you are not using Ruby or C++0x (I guess), otherwise you could have super-easy enqueuing with lambdas.

Unrelated, but this is a great use case for boost::any, my favorite C++ thingie! In case you need inspiration for the non-rough version.
Parent - - By Basic Date 2011-07-05 19:42
I'm not sure what REDRAW is doing? Is that related to gosu? I know of the needsRedraw().

I really like the decoupled nature of event/messages nothing really needs to know about anything else just the ability to send receive messages. I could split the messages to updateMsg() drawMsg(), that should be in keeping with Gosu

So do I understand that it should work but dont rely on it :)

boost::any is nice, I dislike void* but when doing the PS2 stuff its a 10 year old compiler and while some boost works on it, I've been avoiding it incase some insidious bug creeps in. I'm actually using boost::serialize ( this was recommended to me, I think primarily to be able send data over networks.)
Parent - - By jlnr (dev) Date 2011-07-05 21:12

> I'm not sure what REDRAW is doing?


Something like const int REDRAW_MSG =….

Also, this does not really belong in here, but isn't this equivalent to just using virtual functions? I usually have an Object base class which has a gazillion empty virtual methods (virtual void getHitBySilverBullet() { /* Vampire subclass can override this */ }).
It means that the Object class is fat and has a gazillion methods, but the same is true if you have a gazillion message IDs, and you get all the type safety and an easy way to specify default behavior. I can imagine that it would be easier to do catch-all forwarding with void*/int though :)

Oh well, sorry for the Off Topicness!
Parent - By Basic Date 2011-07-06 05:36
Ah I thought you where hinting at something Gosu related with the REDRAW_MSG.

Yes the huge enum is a fairly crap way of doing it, it just moves the mess, one change and everything needs recompiling. I use hashed strings now, Which are alot nicer, but there is a small danger of a hash collision.

The two problems I've had in the past are insane logic in the object managers update and lots of pointer/refs flying around particularly in the player class, just to have access to a tiny amount of info. Events clean that up only having to know about the event manager (and messages), objects could also just send drawing request which would be picked up by a graphics object.

Events have the added bonus of easily being able to respond that frame and send another message to another object without having to loop over.

I guess its apples and oranges really.

Well off topic now :)

PS: I like the simplicity of your gazillion virtual methods (not the object class so much :) must remember  for LD21
Parent - By Basic Date 2011-07-05 14:25
I guess what I really want to know is it ok to send drawing info in the update() cycle? or will this result in unexpected behaviour
Up Topic Gosu / Gosu Exchange / Game Loop and Drawing in the Update

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill