game-editor.com

Take this with a grain of salt: I didnt write GE, so only Makslane really knows. This is how it SEEMS to work however.

First, your game starts up. Something similar to a create game event happens. You will not find this in the list of events. Its behind the scenes; only Makslane has access to it. In it, all the variables get created, the actors, and whatnot. Incidently, the Global code happens around here.

Actors are really just complicated variables, you see. Just a little collection of numbers and functions, and a series of pointers to graphics in memory.

Anyway...

The first thing that your new game does is execute a special function called create actor for View! Did you know view has a create actor event?

It sure does, and you can put stuff in it just like an actor! It is an actor! furthermore, it calls each actors create actor events.

So what happens next? Create actor->view calls another function belonging to view, and not so coincidently, every actor. That function is the Draw event. Again, you can put stuff here too, and it only happens once every frame, so its a great way to reduce lag.

Inside the views draw event, GE makes a list of all the actors in the game, that are at least partially in the limits of view, and then calls their draw actor events.

Each actors draw event does what you tell it(events, scripts, whatnot), then it communicates how to draw itself to the view. It finishes and hands control back to view.

One per draw event, the keyboard gets checked for keypresses, and the mouse does too. All the other events happen around here.

View takes over and sorts the actors by their z depth and draws the furthest first, and the closer ones last. Then it makes a new list of all the actors in view... and starts all over again.

Thats it in a nutshell.

What makes you so sure that this is how it works? Did you do an strace or disasemble it etc, or did you just guess.

Also- Makslane, can you tell us anything about the code?

My understanding of this may be fundamentally flawed, but isn't putting code in any Draw Event undesirable? Surely it would increase lag, not reduce it, because it happens once every frame. This means that instead of displaying the actor in the view, the draw event is now tied up to all kinds of superfluous tasks that would be better suited by a quick call to a function in the global code.

Like I say, probably my mistake - but I usually program in Java, and know that framerate is massively - potentially fatally - reduced by the addition of further functions within the draw function of a given piece of code - why is this not so for the code logic in GE?

Maybe misunderstanding how it's all put together in GE. If anyone could explain the benefits or disadvantages of adding script to a draw event, I'd appreciate it. Because as far as I can gather, it's a sure-fire way to slow down your application.

Using SDL is one of the fastest ways to draw stuff on the screen.

I woul like to add that there is probably a flip event in the code somewhere, so you don't see the program drawing on the screen

Mardi-Gras wrote:Maybe misunderstanding how it's all put together in GE. If anyone could explain the benefits or disadvantages of adding script to a draw event, I'd appreciate it. Because as far as I can gather, it's a sure-fire way to slow down your application.

I totally agree with you. I guess in some ways my meaning just came across wrong.

Personally, I avoid using code within an actors draw, for those very reasons. What I was trying to get across was that you would be better served using the VIEWS draw event, rather than an individual actor, if you must do so at all.

Are you saying, and you may be right, that you dont feel the view calls the on screen actors draw methods?

This was purely a matter of on my part; It made logical sense to me, from what I know of things like bounding boxes and inheritance.

Are you saying, and you may be right, that you dont feel the view calls the on screen actors draw methods?

I definitely agree with you that it seems likely that the view calls on the screen actor's draw methods.

What I misunderstood was thinking you were suggesting that it was somehow desirable to bring functions into play within an actor's draw event, and this got me a little confused. I understand what you meant now - sorry, I can be a little bit slow.

Thanks for the clarification.

Oh no! You are certainly not slow. Its just that I can be a little obfuscated in my ramblings!