# GMLscripts.com

Discuss and collaborate on GML scripts

You are not logged in.

## #1 2011-07-29 05:21:09

paul23
Member
Registered: 2007-10-17
Posts: 110

### future unimprovement of gamemaker

Well I was about to post this earlier but lost the link to the topic so had to do quite a bit of searching:

in this bug report
Russell comments about the ios runner not being capable of executing any draw function outside the draw event.

Especially his last reply raised quite a few questions (which I'd love to see explained):

The problem is that on newer platforms i.e. iOS etc then we cannot do the screen redrawing etc outside the draw loop (we can also not allow scripts to do their own loops i.e. mouse_wait etc.... this will be forbidden in the future for compatibility reasons).

We will be providing other ways to handle pause and flow control in an easier fashion.

Are they considering removing any "draw" function outside the draw event? That would be quite a step back for gamemaker: as with this you can't for example use your own ordering rules when drawing things.

Can somebody explain how I'm wrong and misunderstood russell?

Offline

## #2 2011-07-30 01:43:57

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

I believe you have interpreted Russell's statement correctly and your fears are somewhat justified. What follows is largely conjecture based on my limited understanding of iOS development and the iOS GameMaker runner, but I believe it gets to the crux of the problem.

As I understand it, GameMaker for iOS uses OpenGL ES for all of its drawing. iOS screen operations using OpenGL ES are limited in some important ways that differ from traditional desktop applications.

Normally, when an OpenGL ES application needs to update the display, it must inform iOS first. When iOS receives this request, it prepares itself for drawing and produces an event to tell the application to start sending drawing instructions. Drawing outside of this event is impossible which could prevent the easy or timely availability of a back-buffer. Drawing events are also fired for "dirty rectangles" in which iOS informs the application to update a region of the display that needs to be restored after a compositing operation (eg. moving an icon from one part of the screen to another).

The other screen update method OpenGL ES applications may use is called the animation loop, which is what I suspect GameMaker uses. Here, iOS automatically fires a redraw event for the entire screen with every screen refresh (normally 60 Hz), or after some interval of consecutive refreshes (eg. every third frame for a 20 Hz update). In this case, the only opportunity to draw is when the display will be visibly updated, which makes a back-buffer somewhat superfluous. Although it is still possible to work around this, compromises which can severally affect performance must be made. In addition, the GM iOS runner does not yet support off-screen render targets (surfaces), which is an another reason a back-buffer might not be available.

If you require special handling of your object drawing, it will have to be done in the draw event.

Abusing forum power since 1986.

Offline

## #3 2011-07-30 03:37:14

paul23
Member
Registered: 2007-10-17
Posts: 110

### Re: future unimprovement of gamemaker

Well as people should have noticed already I don't care at all about the ios runner. But this post was in a reply to a gm 8.1 bug, so it makes me wonder what future limitations in gamemaker (desktop variants) will show up.

A few example I won't be able to do anymore:
-Surfaces should be removed - anything based on surfaces won't work.
-My widget engine has the draw code completely taken out of the draw event. So it can work with sub windows.
-In many more advanced games you see the engine running at a certain X frames per second. And then the drawing executes only ever when there's "time left".
-For debugging purposes I often write variables to the screen and then add "screen_refresh".

Offline

## #4 2011-07-30 04:07:27

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

Well, I'm not sure those particular fears are justified. I would be extremely surprised if they did anything that radical to GM for PC, although his statement does read that way. I presume what he's saying relates to GM Studio and hopefully the restrictions will be platform specific. That particular D&D action may be a casualty of this, but I'm not overly worried about the elimination of drawing outside of the draw event entirely for all platforms ... yet. I'll prod Russell and Mike to get some clarification.

Abusing forum power since 1986.

Offline

## #5 2011-07-30 05:13:02

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

First trickle of information isn't looking good, to be honest. Nothing is set in stone, of course. According to Mike Dailly, GM8.x should be unaffected, but after that, it does look like they are going to restrict drawing to the draw event. This seems to be a performance-driven design choice, and I take performance to mean speed of execution.

If GM8.x is unaffected, it doesn't look like it will be an issue for quite some time. All indications are that GM9 (or whatever it's called) will be wholly different beast than the current product. I'm expecting OpenGL/SDL being used as a base, so who knows what will be possible.

In the meanwhile, I'm trying to get some elaboration on what sort of drawing is expected to be restricted ...

Abusing forum power since 1986.

Offline

## #6 2011-07-30 11:30:31

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

OK. It does appear that all drawing will have to happen during the draw event in the next major version of GM.

Your examples will need some re-engineering. Your "widget" may be a lost cause. Surfaces wouldn't be removed because it is of course possible to draw to them during the draw event, something I keep forgetting you can do now. [correction: You always could, but it messes up the viewport & projection. I'm trying to convince Mike that surface_reset_target() should restore it automagically, but he says there is a reason it doesn't ... which he can't remember. For now it's up to the user to reset the viewport.]

Now I'm trying to learn if GM Studio will be built off of GM8.x or this new optimized engine ...

... answer: "Sorry, can't say yet." which I take to mean it has not yet been determined, rather than it's a secret.

Last edited by xot (2011-07-30 14:09:05)

Abusing forum power since 1986.

Offline

## #7 2011-07-30 18:02:42

paul23
Member
Registered: 2007-10-17
Posts: 110

### Re: future unimprovement of gamemaker

Hmm unless we are given much more ability to do drawing options in the drawing event that would be a "deal breaker" for me. I'm hope there's some real good (technically justified) reason for the windows version to share the limitation in drawing.

I would honestly not update and without a possibility to use structures/OO-interfaced containers I'll honestly have to rethink gamemaker :|. Should I post this on the gmc, I'm honestly asking myself now how to do above things without resorting to a dll for drawing? here even chance at gmc showed he didn't expect it.

Offline

## #8 2011-07-30 23:20:09

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

This is all speculation at this point, even by YoYo. We are talking about a product that is easily over a year away. I'm not telling you what to do, but personally I wouldn't post anything yet because I don't see it having any effect beyond stirring up complaints over something that hasn't been implemented or even announced. I'd hate to see any backlash over these morsels of information in no small part because I know it will aggravate the hell out of Mike. And let's face it: the direction GM takes is not really up for debate. They are going to do what they want. Restructuring the game loop should bring significant performance gains for all targeted platforms. Increased speed and multi-platform support are two of the top requested features for GM, and are areas where GM lags behind its competition. As far as multi-platform support goes, GM's non-uniformity is certainly the largest complaint. Code base unification is naturally going to require some compromises. I doubt anything will sway YoYo from that course.

Abusing forum power since 1986.

Offline

## #9 2011-08-03 10:27:24

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

GM Studio may be further along than I suspected. David Galindo (Mr. Chubigans) let slip a couple of comments about it just now.

Chubigans wrote:

Beta testing some YoYo Games stuff...by this time next year, YoYo is going to be a HUGE player in the digital distro. of multiple platforms.

Chubigans wrote:

The stuff in the pipeline- GM Studio in particular- is just crazy amazing. Wait and see!

Russell Kay wrote:

@chubigans Alpha Test and. sssshhhhhh

Chubigans wrote:

@RussellKay whoops, alpha testing, I'm just really excited...and I'll say no more.

I know YoYo is trying hard to keep the lid on things. Even I've been asked not to talk about some rather minor things I've seen. I'm expecting a big reveal in two weeks during (or immediately prior to) GDC Europe.

Abusing forum power since 1986.

Offline

## #10 2011-08-04 09:15:31

Rani_sputnik
Member
Registered: 2011-04-24
Posts: 18

### Re: future unimprovement of gamemaker

OK. It does appear that all drawing will have to happen during the draw event in the next major version of GM.

This is interesting, it's the first major change to GML that I've experienced while working with GameMaker and you know what? This doesn't bother me. If anything it's more intuitive for beginners to see all drawing happen in one place plus the debugging tools should get better with time so hopefully refreshing the screen to check how a variable is going will be a thing of the past.

One thing that I hope hope hope gets taking into account here is the design of GML itself. All events are set up to respond in a uniform way atm. If they are only allowing drawing in the draw event I feel there needs to be a clear indication that that event is different. For instance, perhaps the object events box gets divided into 2 areas, one contains the draw/create and possibly step events that can't be deleted (even if they're empty) and then the other events are separated as they are something different altogther.

Another alternative is that the draw event is opened like the creation code of a room, a separate thing altogether rather than an event. I fear that a lot of GameMaker is simply getting tacked together at this stage, I do not think this is the way a program for beginners should be approached.. I dunno usually I hate people discussing what Yoyo should do as it seems so arrogant but I can't keep my nose out of this one. It's like how Mike wanted to introduce a COMPLETELY different syntax for structures... Yes beginners wont use it anyway, but even so, even pros like stuff to be done in a sensible way, if rules HAVE to be introduced they need to be communicated clearly...

Oh well I'll be interested to see where this all goes but to be honest, I hope Yoyo have taken a good look at how the software is designed and come up with something elegant.

Offline

## #11 2011-08-07 10:10:46

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

Oh no! Paul, I accidentally erased your post. I hit "edit" instead of "reply". Unfortunately, I was unable to restore it from my local cache. I'm very, very sorry and embarrassed. One of the hidden perils of moderation. It's easy to do at the GMC, too. Until now I've managed to catch myself before it was too late.

Also obviously surfaces & views should work together better, can you even restore the viewport?

Still working this out correctly, but for simple 2D games with views this seems to do the trick:

    d3d_set_projection_ortho(view_xview[view_current], view_yview[view_current], view_wview[view_current], view_hview[view_current], view_angle[view_current]);

For multiple views/ports things get a little more complicated.

Honestly never spent any time figuring this out over the years since the manual said never to draw to surfaces during the draw event. If restoring the projection is really the only issue, I can understand Mike's reaction when I pointed out this part of the manual to him: "LOL...I'll find that and nuke it from orbit. That's rubbish."

Abusing forum power since 1986.

Offline

## #12 2011-08-07 15:33:47

paul23
Member
Registered: 2007-10-17
Posts: 110

### Re: future unimprovement of gamemaker

Oh no, an extraordinary piece of craftship eternally lost! :shock:

As said, the "major" issue I have with this is the lack of control over the ordering of the draw events. Sure with "just depth" it is possible to order everything. However this ordering is very limited. And error prone/not intuitive.

A good example can be found again in my widget system:
Each "window" is supposed it's own window. Objects can have a depth, and that depth would describe the ordering INSIDE the window. Each window also has it's depth (which describes the ordering of the windows). So the order I need to execute the events is:

<window1 depth 100>
<object in window 1> Ordered by depth of the objects
<window2 depth 0>
<object in window 2> Ordered by depth of the objects

In my time with gamemaker I've seen quite a few system which "use" a similar ordering system (sometimes hidden, but often it can be abstracted to above).

Of course I could use a control object which handles the ordering. But how can I be sure that this control object is the very last to be executed before drawing starts? Putting it at the end-step event would put a big strain on what the engine can handle (no longer can the depth be changed in the end-step event). Better would be if there's also a special "pre-draw" event then. (As end-step event might also be executed to perform tasks finalizing user input, the user-input commands are executed between step & end step event).
The other option would be to call draw events during drawing. Something like "draw_set_automatic(false)" and then being able to manually start drawing 1 object only. (who handles all the other draw-events, maybe a call like "execute_draw_events()").

What I fear will happen though is that people -when they can't have full control over the draw-event order- will put everything inside 1 big draw event. This will greatly reduce readability & modularity.

Above described problem, as well as the "side effects" from surfaces are the biggest problems I see. Doesn't the surface_set_target command also reset the x,y port of the view in the window (mainly used with multiple views). Maybe it is a simple line, but it's not "obvious" for me, and I think a command should be added (heck they even added "draw_self()", so this should also be there).

@Rani_sputnik:

Yes beginners wont use it anyway, but even so, even pros like stuff to be done in a sensible way, if rules HAVE to be introduced they need to be communicated clearly...

Not sure what you meant with this , however I for one am eagerly waiting for this feature to be added. - There are countless things GM does behind the schemes.. Which I don't want to happen more often than not. Sometimes it will only slows the program down, but quite often it is against what I wish it to do. Take for example how sprite creation from surfaces happened in GM 8.0.
If you had a completely blank - transparent surface, with alpha "0" it created a sprite as if the alpha was "1" everywhere. As apparently gamemaker thought I made a mistake and thought it was more clever than me. But what if I did this on purpose? (IE in my case I was loading a big "map" image for lemmings, and splitting it up in several parts to increase collision detection speed - there are obvious parts which are completely empty).

Problems like these make me hunger for a simple container which doesn't do anything except what I tell it to do.

If you mean the problem was in the syntax, more object orientated syntax: well I can only suggest to stand open for this and learn it. All modern general purpose languages use OO features, and it is considered the best programming paradigm nowadays.

Offline

## #13 2011-08-07 17:30:01

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

Doesn't the surface_set_target command also reset the x,y port of the view in the window (mainly used with multiple views). Maybe it is a simple line, but it's not "obvious" for me, and I think a command should be added (heck they even added "draw_self()", so this should also be there).

Yeah, positioning and limiting the extent of the view port seems to be a bit of a problem. At the moment I'm not sure there is any way to set it correctly using GML. I agree that there should be a simple command to reset the projection of a view just as GM would automatically.

All modern general purpose languages use OO features, and it is considered the best programming paradigm nowadays.

But is that a valid consideration? OOP is certainly en vogue and if one wanted a job as a programmer one should be prepared to use it, but there are plenty of arguments against it as well. It's only one paradigm of many and some critics would argue that OOP languages are becoming increasingly unsuited for modern computing because they don't handle concurrence/parallelism gracefully. There are numerous non-OOP languages that are modern and/or currently in wide use, including a couple of big ones you might have heard of: C, Assembly, JavaScript, Lua, Haskell, Cobol, Fortran, Lisp/Scheme, Tcl, Forth, IBM RPG (and many others that are less common).

Abusing forum power since 1986.

Offline

## #14 2011-08-12 06:59:59

Rani_sputnik
Member
Registered: 2011-04-24
Posts: 18

### Re: future unimprovement of gamemaker

however I for one am eagerly waiting for this feature to be added

Don't get me wrong, I am really looking forward to structures too! And it's not that I don't understand the syntax, it works great in something of a C++ framework. The issue I have is if Mike Implements structures in GameMaker with the same syntax that is used in C++ because it would be adding another layer of complexity to an already mashed up language. Structures should be implemented as a resource, as that is the GameMaker flow. Thus I think they should be treated as such

// Instead of this

struct MessyCode
{
// structure code here
}

// It should be like this

instance_create(x,y,MessyCode)
structure_delete(MessyCode)

Something like the above is what I mean, I feel like it would integrate better with the current frame work. On a side note, I feel constants and triggers are also handled poorly as they are not in the left-hand menu with all the other resources and are hidden away for users to stumble upon. Both need to be moved out into the menu with the other resources, and in addition I think constants could be turned into constant groups, (Enums?) that'd make them more useful IMO... But I dunno, each to their own. I just feel that doing everything in the same or at least similar way is the way to a more intuitive program, and thus a far better program.

What on earth will happen to the sprite_create_from_ functions? They are such a pain in the **** to use when you have to use them in the draw event. Ugh, all I want to do is load my sprites at the start of the room. I am disappointed in this decision to be honest. Surely it wouldn't be too much to ask to still allow drawing in the other events, even if they make it painfully slow? That way at least we still have the option if we really need it. I got GameMaker because it just gets out of the way and lets you do your thing, now it's sounding more and more like its gonna get all fussy on me, and I don't like that.

On the flip side, Mike has A LOT more experience than me and he knows what he's doing. It will be interesting to see what sort of repercussions this has... Only time will tell.

EDIT: Oh and if you read my other post before this one you'll notice my opinion shift quite drastically, that's because I have spent the last couple of days writing code with all drawing in the draw events and I am now officially frustrated haha.

Last edited by Rani_sputnik (2011-08-12 07:02:40)

Offline

## #15 2011-08-13 06:46:12

paul23
Member
Registered: 2007-10-17
Posts: 110

### Re: future unimprovement of gamemaker

xot wrote:

here are numerous non-OOP languages that are modern and/or currently in wide use, including a couple of big ones you might have heard of: C, Assembly, JavaScript, Lua, Haskell, Cobol, Fortran, Lisp/Scheme, Tcl, Forth, IBM RPG (and many others that are less common).

This is a bit diverting of the issue, and maybe my choice of words was unlucky. But I don't really consider the list there to be "general purpose" languages, but even in those languages you see programmers add OO features to help them - not in the least datahiding to keep yourself sane.

@Rani_sputnik: the first codepiece would be just a cleaner way to define a structure, consider how other structure code would have to be added:

MessyCode = structure_add();
t = instance_create(MessyCode);
t.myvar1 = 0;
structure_delete(MessyCode);

Above is in my opinion more difficult to read than:

struc MessyCode {
myvar1 = 20;
myvar2 = "hello world";
}

t = instance_create(MessyCode);
t.myvar1 = 0;

But back on the original topic:
I do indeed hope there will be something like: "invoke_drawing()" which starts a drawing occurence for the current code piece. But what you could do is initialy make all objects invisible, and then use the first draw event to build sprites.
Initializer start

alarm[0] = 1;
with (all) {
visible = false;
}

Initializer draw
Build sprites
Initializer alarm0

with (objParentAllVisibleObjects) {
visible = true;
}
instance_destroy();

Offline

## #16 2011-08-14 11:12:51

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

An alternative is to just call screen_redraw() whenever you've used the screen buffer to build a sprite or background (or wrecked the view transform drawing to a surface). Even without duplicated drawing, invoking screen_redraw() is a little slow by itself. Shouldn't be a problem if it's not being called many times every step. An advantage of this approach is that it doesn't impact the behavior or settings of other instances. A disadvantage is that it may cause code to be executed multiple times if the object requesting the redraw isn't at the front in the depth queue.

Abusing forum power since 1986.

Offline

## #17 2011-08-20 09:15:24

Rani_sputnik
Member
Registered: 2011-04-24
Posts: 18

### Re: future unimprovement of gamemaker

@Paul to clarify, you may still be missing my point.

I agree with you, the syntax structure {} is far cleaner than using functions. The problem I have with it is that it is not intuitive in the current GameMaker frame work. It would be adding a new syntax to an already mashed up language. If Mike wants the structures to be defined in curley braces he should make ALL resources done in that way. Do you see what I mean? That way anyone learning GameMaker (It is a learning tool after all) only needs to learn one syntax structure and then they can apply it to lots of different things.
Sorry for the diversion, wont happen again

Offline

## #18 2011-12-28 20:21:59

Daniel
Member
Registered: 2011-05-04
Posts: 25

### Re: future unimprovement of gamemaker

Double the framerate, draw the surfaces/room in every odd frame, draw TO the surfaces in every even frame.

Offline

## #19 2011-12-29 14:55:16

xot
Registered: 2007-08-18
Posts: 1,201

### Re: future unimprovement of gamemaker

An interesting idea, although it may not be possible with iOS (and other 60fps platforms) unless you are willing to have 30fps be your screen update rate, you don't mind an extra frame of lag, and you can live with using up to twice as much texture memory.

Abusing forum power since 1986.

Offline

## #20 2011-12-29 15:04:46

Daniel
Member
Registered: 2011-05-04
Posts: 25

### Re: future unimprovement of gamemaker

Most games run in 30fps anyway, and I don't know what lag you're talking about, you'd be doing those operations in your STEP event otherwise? It's not EXTRA lag. I know in GM if you turn off the "draw background color" thing, the stuff on-screen will remain on-screen, so every second frame you would re-draw the screen, so there's no extra texture memory either. The only downside is that you are stuck at 30fps refresh rate, which is perfectly fine.

I say 30fps, you could even go 2:1 for 40hz drawing rate, or 3:1 for 45hz drawing rate... Or 5:1 for 50hz... Only updating your Surfaces every third, fourth, fifth, sixth frames.

Offline