GMLscripts.com

Discuss and collaborate on GML scripts
Invert

You are not logged in.

#1 Re: Game Maker Bugs » Memory leak in sprite_replace and background_replace when using PNGs » 2009-06-17 02:25:15

icuurd12b422 wrote:

Does it drop after running for a long time? It could simply be memory fragmentation.

But one thing you will notice, commentout image1's loading and load image 2... The memory climbs but not as fast

Comment out image2 and uncomment image 1 and the memory is somewhat stable after a few seconds; the memory climbs about 8 k evey 20 seconds...

That's why I indicated that PNGs of different file sizes have to be used to reproduce this bug, and why you also have to look at the peak memory use (regular memory consumption fluctuates so much that it's difficult to discern a leak). If you'd replace the image with a copy of itself you'd never notice.

#2 Re: Game Maker Bugs » Memory leak in sprite_replace and background_replace when using PNGs » 2009-06-08 17:53:21

Good catch. Then I'm guessing it also happens for sprite_replace_alpha.

#3 Re: Game Maker Bugs » median - returns wrong value when using an odd number of arguments » 2009-06-06 09:55:49

xot wrote:

Oh, so you're saying the only reason he emailed is because my bug reports stink, eh? snitch

Or unable to reproduce. whistle

I think the impetus of the exchange was probably because I gave him the clue he needed to solve the precision problem introduced in GM6. I'm not sure if it is possible to jump for joy in an email, but I think he may have.

Yes, I know - 3D initialisation in DirectX sets the FPU to single precision for reasons of optimisation. That's why it first occurred in GM6, as GM6 was the first edition with 3D routines.

You know, the bug was almost reintroduced in the C++ engine, for which I also tested the first alphas. This is probably because others took over development. Fortunately I was able to point them to an MS knowledge base about it.

#4 Game Maker Bugs » Memory leak in sprite_replace and background_replace when using PNGs » 2009-06-05 17:31:52

Smarty
Replies: 12

Brief Description:           Multiple use of sprite_replace and background_replace with PNGs leaks memory
GM Versions:                  GM7
References:                    <none>
Example File:                  http://www.forge.dds.nl/files/pngmemleak.zip
Bug Confirmed:               ---
Hardware Dependent:    No

Main Info:

Using multiple calls to background_replace and sprite_replace to replace a background or sprite resource, using PNG image files of different (!) file sizes, causes the game's memory consumption to increase.

Load the example file into Game Maker 7. Hit CTRL+ALT+DEL and bring up the Processes list. Make sure the column Peak Mem Usage is visible and run the game. You will see memory consumption rise gradually.

The issue is most likely related to the routines used to allocate and deallocate memory to process PNG images.

Workarounds:

1. Use Game Maker 6. The leak has been introduced with version 7.
2. Use BMP, GIF or JPG images instead (the issue only applies to PNG images)
3. Use sprite_delete / sprite_add and background_delete / background_add to replace images.

#5 Re: Game Maker Bugs » median - returns wrong value when using an odd number of arguments » 2009-06-05 17:12:23

xot wrote:

I exchanged several emails with Mark when I reported GM7 bugs during its beta. I thought maybe a GM user of your stature might have as well.

Not about bugs. I have usually been pretty accurate in reporting bugs - a 'bare necessity' source to reproduce, a little investigation into the scope etc. I don't think there was need for further communication in all cases because there was nothing left to ask. Fortunately I've seen all bugs that I reported fixed in subsequent versions.

I'll try and use your template when reporting bugs.

#6 Re: Game Maker Bugs » median - returns wrong value when using an odd number of arguments » 2009-05-31 04:24:33

xot wrote:

The fact that this bug exists blows my mind. Wouldn't this come up in the very first test of the function? How can something like this be missed? I guess it must be a div 2  resulting in an off-by-one index, but still, no testing? Did Mark ever give you any insight into the cause of the problem, Smarty?

No, I never got confirmation or explanation of bugs I reported, but I assume nobody does.

Strange, I remember testing in GM6.1 whether more parameters work correctly. My test must have been flawed.

xot, I sent you a message about this - why am I not allowed to create new topics in this forum? Is it supposed to be managed by a few members only? I couldn't find any topic about this.

#7 Re: Game Maker Bugs » median - returns wrong value when using an odd number of arguments » 2009-05-28 18:04:15

Agreed, but then you should be able to get a head start here by copying in the list of fixes mentioned in the GM7 help file.

#8 Re: Game Maker Bugs » median - returns wrong value when using an odd number of arguments » 2009-05-28 17:41:27

The problem with median in GM6 was that it didn't work if there were 3 parameters. I remember this because I originally submitted the bug.

By the way, what's the point of keeping track of bugs in previous versions? If it's for backtracking purposes, the help file contains a list of fixed bugs with regard to the previous version, so you'll find all of them there...

#9 Re: Community » Smilies » 2008-01-26 16:21:26

Sorry, I forgot. The only ones I remember being changed from the original IPB distribution is the wink one, as well as replacing a few we thought we didn't need with the GM5-7 icons. And then we added a large set featuring the GM D&D icons.

#10 Re: Script Alumni » turn_toward_direction - overhaul » 2008-01-25 06:07:05

xot wrote:

I usually don't go out of my way to make scripts work for unregistered users (I'd rather they register), but I think this is another good reason to make image_angle optional. I'm really not sure what happens when an unregistered user makes a call to a registered function. Does is fail to build the executable, or does it throw an error on loading, or does it fail at run-time? And what about object properties like image_angle, do they simply get ignored?

The executable builds without problem (a nag screen shows up at startup of course, just to remind everyone you've been using the freebie version).

On Game Maker 7 (and as far as I remember the previous as well) unregistered functions are considered errors. The Errors tab in the Global Game Settings decides what to do with those errors, so you can choose to abort on all errors, let the user decide this or not make them appear at all.

Two errors associated with using registered features on Game Maker 7:

[variable name]: This variable is only available in the Pro Edition.

Error in code at line [line]:
   [script snippet]
at position [pos]: This function is only available in the Pro Edition.

The error messages are different in Game Maker 6.1 but I don't have an unregistered version of that. Oddly, the line, position and script snippet are reported for function calls but not for variable declarations.

By the way, the unregistered edition alllows reading registered variables.

#11 Re: Script Alumni » turn_toward_direction - overhaul » 2008-01-25 04:08:06

Thanks Quimp, I'll correct that and implement xot's remarks.

I just thought of a few other reasons why you would not want to adjust the image angle automatically: for one, you might not be registered. hmmm (speaking of which, the gmlscripts are not marked as such). Second, the fans of rendered images would rather use a number of correctly shaded subimages for the sprite and adjust the image index to the new direction themselves.

And I guess that's why I have a tendecy towards towards (sorry, couldn't help myself). My English teacher back in those days was an apostle of British English versus American English. The latter he merely considered a contamination.

The revised script:

Expand/*
**  Usage:
**      turn_towards_instance(instance,step,imagerotate);
**
**  Arguments:
**      instance        An object or instance ID to turn to (argument0)
**      step            Step size or 'turn speed', degrees (argument1)
**      imagerotate     Whether to adjust the image angle to the direction, boolean (argument2)
**
**  Notes:
**      Use in a step event. Sprite origins should be centered for best result.
**
*/

{
    var da;
    da=point_direction(x,y,argument0.x,argument0.y)-direction;
    if abs(da)>180 da=-da;
    if abs(da)>argument1 direction+=argument1*sign(da);
    if argument2 image_angle=direction;
}

#12 Community » CSS modification suggestion » 2008-01-24 20:02:18

Smarty
Replies: 3

Take a look at this script here:

http://www.gmlscripts.com/script/string_trim

I don't know how it is for everyone else, but the third line of the script tells me that one is one, rather than L=1 (capitalised for clarity). That's an issue for me everywhere the number 1 is used as a parameter or part of an expression.

The problem seems to be the size of the Courier New font in the gml class in the CSS script. When the point size goes under 10, the lower-case L is remarkably like a one.

Can it be size 10 pretty-please?

#13 Re: Community » Smilies » 2008-01-24 19:51:07

Yes, they look terrible. Go ahead and steal ours. Call me biased, but I still like them better than most I've seen around.

If you have some reservations against looking like yet another IPB rip-off, go here:

http://www.smileygenerator.us/t/index.php

They even have generators like this one where you can be creative:

http://smileygenerator.us/t/newgen/index.php

Some of them are pretty tasteless, yet they seem to feature smilies roughly based on the IPB set and can be made to look pretty cool.

#14 Re: Script Alumni » turn_toward_direction - overhaul » 2008-01-24 05:20:11

Great initiatives deserve support. smile

I've considered making image_angle optional as well, but decided not to include it for reasons of performance.

On retrospect, checking whether or not the instance exists should probably be removed from the script. This makes Game Maker error out upon calling it when the target instance does not exist, which is probably preferable over the script not doing what it is expected to do.

#15 Script Alumni » turn_toward_direction - overhaul » 2008-01-23 13:36:49

Smarty
Replies: 8

First post on this forum. Nice place you got yourself here, xot. smile

Now I'll get my guns out. See the current turn_toward_direction(direction,turnspeed) script.

For starters, I propose we use towards in the script command name. I don't know why, it just sounds better. To me. Second, the script has an error. The variable turnspeed referenced in the script doesn't exist, it should be spd. Third, I propose an alternate version - either coexisting peacefully with the one above, or replacing it. I suggest that rather than a direction, an object or instance is used as the target. I also think the script should incorporate image_angle, because I can hardly think of circumstances where you would not want the sprite of the instance to turn visibly towards the new direction.

Here is the alternative:

Expand/*
**  Usage:
**      turn_towards_instance(instance,turnrate);
**
**  Arguments:
**      instance    An object or instance ID to turn to (argument0)
**      step          Step size or 'turn 'speed', degrees (argument1)
**
**  Notes:
**      Use in a step event. Sprite origins should be centered for best result.
**
*/

{
    if instance_exists(argument0) {
        var da;
        da=point_direction(x,y,argument0.x,argument0.y)-direction;
        if abs(da)>180 da=-da;
        if abs(da)>argument1 direction+=argument1*sign(da);
        image_angle=direction;
    }
}

A check for instance existance may be removed if one is sure the instance is always around. I also have the nagging feeling the script could be optimised even a little more, but my logic is failing me there.

Board footer

Powered by FluxBB