GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#21 2009-07-20 21:09:07

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

Re: GM8 - Things that work differently than GM7

GML > GAME PLAY > MISCELLANEOUS VARIABLES AND FUNCTIONS

Hidden constants gamemaker_registered and gamemaker_pro have finally been documented and they've got a new pal.

The following variables can be used to make sure your code will work for the appropriate version and edition of Game Maker.

gamemaker_pro Indicates whether the game is created with the Pro Edition.
gamemaker_registered Same as gamemaker_pro
gamemaker_version The version of Game Maker. This is an integer. For version 8.0 this can be anything between 800 and 809. For version 8.1 this will be something between 810 and 819, etc. So never check a particular version but better check for a range. This variable is not available in version before 800.

http://www.gmlscripts.com/gm8beta2/help … _misc.html

Last edited by xot (2009-07-23 01:05:51)


Abusing forum power since 1986.

Offline

#22 2009-07-20 21:12:59

flexaplex
Member
Registered: 2008-12-11
Posts: 72

Re: GM8 - Things that work differently than GM7

Well a lot of those changes will make people happy, he seems to of covered most of the problems people were complaining about. I would of suggested he added a zoom function so you could see/draw the mask more easily but never mind smile

A quick change to note since the space at the end of lines things has been removed, you can still get the functionality though by double clicking to type anywhere in a line, this was nicely thought of by Mark.

I still have several issues with the script editor but I'm not going to complain.

Last edited by flexaplex (2009-07-20 21:15:03)

Offline

#23 2009-07-20 21:14:16

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

Re: GM8 - Things that work differently than GM7

GML > RESOURCES > SPRITES

These functions have been deprecated.

Game Maker 7 Help wrote:

sprite_get_transparent(ind) Returns whether the sprite with the given index is transparent.
sprite_get_smooth(ind) Returns whether the sprite with the given index has smoothed edges.
sprite_get_preload(ind) Returns whether the sprite with the given index must be preloaded.

http://www.gmlscripts.com/gm8beta2/help … rites.html


Abusing forum power since 1986.

Offline

#24 2009-07-20 21:18:22

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

Re: GM8 - Things that work differently than GM7

GML > CHANGING RESOURCES > SPRITES

Here's another change due to the new collision system.

sprite_collision_mask(ind,sepmasks,bboxmode,bbleft,bbright,bbtop,bbbottom,kind,tolerance) Changes the collision mask for the sprite with index ind. sepmasks indicates whether there must be separate collision masks for all subimages. bboxmode is the bounding box mode (0=automatic, 1=full image, 2=user defined). bbleft, bbright, bbtop, bbbottom indicate the bounding box in case of user defined bounding box. You can use 0 for all these values in the other cases. kind is the kind of mask (0=precise, 1=bounding box, 2=disk, 3=diamond). tolerance indicates the tolerance in the transparency value (0=no tolerance, 255=full tolerance).

http://www.gmlscripts.com/gm8beta2/help … rites.html


Abusing forum power since 1986.

Offline

#25 2009-07-20 21:24:31

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

Re: GM8 - Things that work differently than GM7

GML > FILES, REGISTRY, AND EXECUTING PROGRAMS > FILES

Here are a couple of new file functions to make you better safe than sorry.

Finally, if you are interested in the size of the disk and the free space, you can use the following functions:

disk_size(drive) Returns the size of the indicated drive in bytes. drive must be a capital letter, e.g. 'C'. If you do not provide the drive the drive of the current working directory is used.
disk_free(drive) Returns the amount of free space on the indicated drive in bytes. drive must be a capital letter, e.g. 'C'. If you do not provide the drive the drive of the current working directory is used.

http://www.gmlscripts.com/gm8beta2/help … files.html


Abusing forum power since 1986.

Offline

#26 2009-07-20 21:27:19

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

Re: GM8 - Things that work differently than GM7

Just noticed this bit of unsubstantiated claim:

The speed of games that use code has been considerably improved. A speed-up of up to 100% is sometimes possible. Also the loading time for games is often considerably improved. Also when running a stand-alone game.

Any takers?

http://www.gmlscripts.com/gm8beta2/help/new.html


Abusing forum power since 1986.

Offline

#27 2009-07-20 21:41:07

flexaplex
Member
Registered: 2008-12-11
Posts: 72

Re: GM8 - Things that work differently than GM7

xot wrote:

Just noticed this bit of unsubstantiated claim:

The speed of games that use code has been considerably improved. A speed-up of up to 100% is sometimes possible. Also the loading time for games is often considerably improved. Also when running a stand-alone game.

Any takers?

http://www.gmlscripts.com/gm8beta2/help/new.html

lol. I suggested to him in the glog the boast more about the speed improvements as it is a good selling point, looks like he listened.

I do not think he means a speed gain of 100% is possible in a game but rather a speed gain of 100% is possible in a script. The wording is a bit dubious.

Offline

#28 2009-07-21 11:58:10

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

Re: GM8 - Things that work differently than GM7

xot wrote:

Just noticed this bit of unsubstantiated claim:

The speed of games that use code has been considerably improved. A speed-up of up to 100% is sometimes possible. Also the loading time for games is often considerably improved. Also when running a stand-alone game.

Any takers?

http://www.gmlscripts.com/gm8beta2/help/new.html

Once the final release of GM8 is there I will execute (an updated) version of my perftest program.. Though it only tests the speed of the "functions" (and not the speed in which GM's logic works), a 100% speed improvement should be seen there..

Anyways, NPT claimed also a 40% improvement in speed.. (Not sure if that name stands for any credibility though tongue)..

But the claim is pretty much "empty"- it's like impossible to prove the claim is wrong.. (If at least 1 point in GM becames twice as fast it might be already true).

One thing I dislike is the absense of constants for the function: sprite_collision_mask(ind,sepmasks,bboxmode,bbleft,bbright,bbtop,bbbottom,kind,tolerance).. (for the bboxmode and kind arguments)..
Well I guess I should create a gex someday with all numbers becoming "constants" (Many newer functions, post GM5, don't have constants to fill enumerated arguments)

Offline

#29 2009-07-21 20:33:57

icuurd12b42
Member
Registered: 2008-12-11
Posts: 303

Re: GM8 - Things that work differently than GM7

Maybe the 100% speed improvement is about the model vertices now having 32000 limit... Less model splitting in the points makes it faster...
But my tank game is faster. It keeps its framerate now...

Offline

#30 2009-08-09 15:17:10

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

Re: GM8 - Things that work differently than GM7

Saw this in the bug reports, gave me a chuckle:

Mark Overmars wrote:

Once again: code actions are evil. Don't use them.

I have to say, after spending some time reading through the resolved reports, I'm impressed with how receptive Mark is being with suggestions. Seems like he and YoYo are trying hard to please users.


Abusing forum power since 1986.

Offline

#31 2009-08-10 07:48:13

flexaplex
Member
Registered: 2008-12-11
Posts: 72

Re: GM8 - Things that work differently than GM7

Xot, do you have any in-sight into what's going on at the moment? I haven't seen a response from Mark at the Mantis system for a while now.

Last edited by flexaplex (2009-08-10 07:49:03)

Offline

#32 2009-08-10 14:05:23

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

Re: GM8 - Things that work differently than GM7

Sorry, I don't have any special info, I'm just a reporter. I also noticed that there haven't been any updates in a few days, but I figured that was because it was a weekend. I don't know what the usual activity is like. I haven't paid much attention to the beta to be honest. I'm sort of dissappointed in myself for not testing more, but I'm impressed with the number of real issues being reported by others. My fear is that come the end of summer, that's going to be it for GM8. Whatever bugs are left, will not be addressed until next summer, if ever. I don't want to see a repeat of GM7 where post-release bug reports are ignored and not a single point release is made before the next major version. There is always one more bug.


Abusing forum power since 1986.

Offline

#33 2009-08-10 16:12:30

flexaplex
Member
Registered: 2008-12-11
Posts: 72

Re: GM8 - Things that work differently than GM7

Mark hasn't responded on the Mantis system for over 2 weeks. I don't know if he's just busy or decided to deal with reports without responding at all.

My fear is that come the end of summer, that's going to be it for GM8. Whatever bugs are left, will not be addressed until next summer, if ever. I don't want to see a repeat of GM7 where post-release bug reports are ignored and not a single point release is made before the next major version.

I have a fear that it will be even worse than that. I think not only will GM8 not be updated at all after the release but as I have said a while ago, I think a lot of the known bug that have been reported now will also be ignored for the final release. As I said at the gmc I think we are dealing with a very busy Mark, working alone on GM8 and without a great deal of incentive on fixing bugs since the runner will be replaced in GM9 with the C++ one currently being written.

I'm not that bothered if that is the case but it would have been nice to be informed by Mark if so. I don't really see GM8 as a big deal, I'm more looking forward to GM9.. I think that's the one that will be fun to test.

Last edited by flexaplex (2009-08-10 16:14:22)

Offline

#34 2009-08-29 11:39:04

flexaplex
Member
Registered: 2008-12-11
Posts: 72

Re: GM8 - Things that work differently than GM7

Well Mark has come back on the Mantis system again after like a month (he must indeed be a very busy man). Interestingly enough he has fixed 2 of the old bugs: that is both the bugs with room_tile_add : tile id, blend. I imagine these were both very easy to fix smile

But I'm most happy to see that the Room Creation Code error reporting issue has apparently finally been dealt with: http://gm8.yoyogames.com/view.php?id=96

He also said something interesting with response to named arguments suggestion: http://gm8.yoyogames.com/view.php?id=98

Even though it is possible it would complicate the interface. Also it is against the design of GML in which functions do not have named arguments. (I know that this is a weakness of GML but it was done this way to make things easy for beginners. We might at some moment give GML an update but not in this version of Game Maker.

I wonder if Mark will continue on Manits for a few days now, hopefully.

Last edited by flexaplex (2009-08-29 11:49:20)

Offline

#35 2009-08-29 17:07:14

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

Re: GM8 - Things that work differently than GM7

Alright, I'm glad to see some more official activity. Great news on the tile stuff, although I have never really used them myself. Really pleased to see a proper id returned. Even more pleased to see the error reporting fixed, that has to be one of biggest annoyances that most of us deal with regularly.

I too hope Mark can spend some more time on Mantis, there is such a huge back log. At a glance it looks like many issues are finally being addressed. I was really beginning to believe the GM8 was going to shoved out the door with no more fixes. It still may be. Many of the resolved reports are of the "I don't understand the report therefore I can't fix the problem" variety. Fingers crossed that there will be a third beta ... but I have serious doubts there will be one as this summer draws to a close and university duties begin to take over Mark's schedule.

Thanks for the news, flex.


Abusing forum power since 1986.

Offline

#36 2009-08-29 17:51:41

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

Re: GM8 - Things that work differently than GM7

I added functions mouse_wheel_up() and mouse_wheel_down() that return whether the mouse wheel was moved since the precious step.

Mark

Quite frankly, I'm amazed. I would have never bothered with this. Whatever, cool news which will shut up a lot of people laugh


Abusing forum power since 1986.

Offline

#37 2009-08-29 18:16:23

flexaplex
Member
Registered: 2008-12-11
Posts: 72

Re: GM8 - Things that work differently than GM7

xot wrote:

I added functions mouse_wheel_up() and mouse_wheel_down() that return whether the mouse wheel was moved since the precious step.

Mark

Quite frankly, I'm amazed. I would have never bothered with this. Whatever, cool news which will shut up a lot of people laugh

Yes I was surprised to see this also.

He's gone through quite a few more reports but nothing else interesting to report. Unfortunately he turned down a lot of script editor suggestions I made a while ago. One of the ones I would of most like to of seen is the script editor checking syntax upon closing and warning if there is an error, I'm not going to use the continuous syntax checker as I find it annoying.

Also he's decided to completely remove triple line clicking to select an entire line and replaced it with double clicking the line number which is rather annoying for me. I use triple clicking all the time so I am going to have to learn to adjust (which might take a while) and it will make editing slower for me.

Offline

#38 2009-09-04 21:07:59

flexaplex
Member
Registered: 2008-12-11
Posts: 72

Re: GM8 - Things that work differently than GM7

Mark's actually getting through quite a lot of reports. Looks like I might have been wrong when I said he would miss some bug reports out. Lots to interesting things from Mark's last report sessions. Unfortunately a lot of them are remarks that they are not fixable.

Error reporting for trigger events do not show objects in the report: (http://gm8.yoyogames.com/view.php?id=241)
Mark's response to this was:

In the system I can only report one thing and I think the trigger is more important than the object.

So it looks like it's not going to get fixed. I'm rather curious to why only one thing can be reported.. what makes triggers different to anything else or have they just not be implemented thoroughly?

Bug where persistent object instances deactivated in one room can not be reactivated in another. (http://www.gmlscripts.com/forums/viewtopic.php?id=102)
Mark said this is too difficult to solve so has just put a warning about it in the manual.

Both the other bugs with instance deactivation, in the draw and creation events. (1, 2)
Mark remarked that he didn't know what the problem was with either and that they would be too difficult to solve. So has made warnings in the manual about both instead. He said:

These problems are caused because of the following: When drawing the instances we obviously run along the list. Now when you deactivate (or activate) something, the list changes. But the drawing loop will continue running along the old list. In this way it can miss instances or treat them twice.

Even though this clearly is a bug I have no idea how to solve it efficiently. I could leave the deactivate instances in the list and check whether they are deactivated, but this destroys the whole idea of deactivating because it would no longer save much running time.

Maybe the best idea would be to completely remove the notion of deactivation. But for compatibility reasons I cannot do this. I added a comment indicating this in the documentation.

Given the nature of the bugs I am personally dubious to whether this reasoning means the bugs cannot be fixed. I think they are both caused by a mistake in choosing instances upon a changed list which could surely be corrected without slowing down normal execution. Given this information I am going to try and work out exactly how GM handles activation/deactivation, then try and work out where an error could of come into play in making these bugs occur so I can report to Mark directly why I think the bugs are happening and what could possibly be done to solve the issue.

I can understand though that something like deactivation would be a nightmare to program and it is probably a web of mess getting it to work correctly in GM. But that shouldn't be a reason for him to give up on deactivation completely, just because there are a few bugs he could not solve.

Computational function errors and crashes (http://www.gmlscripts.com/forums/viewtopic.php?id=1628):
Mark's comment to this:

In some sense. I cannot really fix it because the Dephi functions to handle this type of conversion cannot handle it. However, the game now no longer crashes and the string ERROR is returned.

This is very interesting. Normally I would expect Mark just to stick a normal error message in these cases. This now means you will now be getting "cannot compare argument errors" when using the functions which could be very confusing to someone if this functionality is unknown to them, so I hope it is properly documented in the manual. However doing this means the functions can now still be misused by user input without stopping the game due to an error report which could be useful.

Fixes:
So along with those reports there have been quite a few suggestions that have been shot down. But one suggestion has seemingly been implemented which is to have a new variable debug_mode to detect whether you are in debug mode or not: http://gm8.yoyogames.com/view.php?id=310

Also another one of the old bugs has been marked as fixed: the draw_line_width_color when length equivalent to 0 (http://www.gmlscripts.com/forums/viewtopic.php?id=98)

Last edited by flexaplex (2009-09-05 01:23:41)

Offline

#39 2009-09-05 00:20:20

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

Re: GM8 - Things that work differently than GM7

Thank you for reporting this stuff, flex. After the beta test is done whatever rationale Mark has used to dismiss any lingering bugs will probably be lost. It's nice to have a record of it.

I can't say I'm too surprised about not making any changes to the deactivation or event systems. I think he's probably painted himself into a corner by keeping legacy support going back to even GM4. It probably is difficult to meddle with the system and keep things compatible. I'm sure the bugs can be fixed with reasonable, maybe total, compatibility, but I can see it taking more effort than is worthwhile at this stage of development. I'm pleased to see he is going to make an effort to document these sorts of potential problems.

His comment about trigger errors is really peculiar. GM's error system normally gives like seven pieces of information: action number, event, object, row, column, source code, error type. What's so different about triggers versus a step event?


Abusing forum power since 1986.

Offline

#40 2009-09-05 01:39:14

flexaplex
Member
Registered: 2008-12-11
Posts: 72

Re: GM8 - Things that work differently than GM7

xot wrote:

His comment about trigger errors is really peculiar. GM's error system normally gives like seven pieces of information: action number, event, object, row, column, source code, error type. What's so different about triggers versus a step event?

I'm almost tempted to ask him, but that is not what the report system is used for so I am not going to.

Fortunately most triggers will only be executed from a specific corresponding object. I think a new 'good coding practice' which I will employ is to put the object name in the title of triggers. This will then be beneficial for both error reporting and general organisation in the game. Although saying that I doubt I am actually ever going use triggers anyway smile

Offline

Board footer

Powered by FluxBB