182 replies to this topic

[Smarty]

One that immediately pops to mind:

If you use image_xscale (and possibly image_yscale, not tested) to mirror a sprite, then the bounding box of that sprite changes size, possibly because it isn't mirrored properly. This causes collision detections to be off.

See the bug report:

http://bugs.yoyogame...view.php?id=244

This bug was of considerable impact on us when writing the Game Maker's Companion - as a workaround we had to mirror sprites in the sprite editor to be able to properly use bounding box collisions, not to mention change the project code accordingly. It also increased the sizes of the EXEs significantly.

Addition: It worked fine in GM7, probably the introduction of alternative bounding box shapes broke it.

Edited by Smarty, 07 March 2011 - 11:29 PM.

[Big J]

Hey Mike, what about complaints like Game Maker's file extension/association? Using ".gmk" for every single Game Maker version only causes trouble. Game Maker 7 should have used ".gm7", Game Maker 8 should have used ".gm8", GM9 should be ".gm9", etc. I keep old versions of Game Maker, and when I work on old projects, I don't want them automatically ported to the latest Game Maker. Once you save your project with the new version, you can never go backwards to old version. That is very bad, especially when trying to help people with their projects. I have projects that only run correctly in GM7, and having them open in GM8 when double clicked, just because that is the last version I ran, is bad. If I want to port a GM project to a later version, I can do that on purpose, I don't need it done for me semi-behind my back.

Edited by Big J, 08 March 2011 - 01:40 AM.

[Docopoper]

[CUT - no feature requests]

Edit: :-|

Edited by Docopoper, 09 March 2011 - 12:03 AM.

[sabriath]

[CUT - no feature requests/discussions]

The biggest bug I can think of is the execute code window modal...which has already been said. You say that you are "yet to look to see if I can "undo" that design"...but it's as simple as turning the modal of the window to NULL rather than the UI which causes the freeze. The only possible problem I can foresee is that if the user deletes the object before closing the window, than the window has no "target" to save the edition, which you would have to do a check to see if the object exists (and the event it targets) before actually doing any saving. You could further add to the 'onunload' of the object to close any forms related to it automatically.

[pqp239]

I looked at all the posts and I haven't seen anyone mention this. When you use draw_text the last column of pixels of the drawn text is cut off, which I find very annoying.

[TheMagicNumber]

Not really a bug, but "An unexpected error occurred" is really annoying when developing DLLs. This should give information about the error. This could also be useful if there is a crash in Game Maker itself and you guys need to know why and where.

There is also the incorrect location in some errors. For example, you might get an error in a trigger and you don't even use triggers.

+1 above post for all text rendering bugs!

Edited by TheMagicNumber, 08 March 2011 - 02:31 AM.

[IceMetalPunk]

Well, since my bug was one that's already been fixed since GM8.0, I hope I get another chance?

I think the following syntax should be removed:

str = "string value" * N;

Where "N" is a numerical value. Right now, that does the same thing as this:

str = string_repeat("string value", N);

Not only is it unnecessary, but I've never seen such syntax for that purpose anywhere else, so allowing it encourages bad habits. I'm not sure if this is a bug based on how GM works internally or if it was a design choice. Either way, it's not good to keep around.

-IMP

[Big J]

Well, since my bug was one that's already been fixed since GM8.0, I hope I get another chance?

I think the following syntax should be removed:

str = "string value" * N;

Where "N" is a numerical value. Right now, that does the same thing as this:

str = string_repeat("string value", N);

Not only is it unnecessary, but I've never seen such syntax for that purpose anywhere else, so allowing it encourages bad habits. I'm not sure if this is a bug based on how GM works internally or if it was a design choice. Either way, it's not good to keep around.

-IMP

Are you imagining a non-existent problem? When I tried that, I got

___________________________________________
EXECUTION ERROR in creation code of room room0
Error in code at line 2:
str = "string value" * N;
^
at position 25: Wrong type of arguments to *.

That error show up in both GM7 and GM8. Seems to me that the incorrect syntax you talk about is already not allowed.

Edited by Big J, 08 March 2011 - 04:06 AM.

[IceMetalPunk]

@Big J: Are you sure? I know for a fact I've seen people use that syntax in password obscuration codes. Something like this:

covered_pass = "*" * string_length(password);

And I distinctly remember it working...

-IMP

[amd42]

@Big J: Are you sure? I know for a fact I've seen people use that syntax in password obscuration codes:

Yeah, it works, I've used it too. And unless it's an interpreter bug, I don't see any reason to remove it - it's quicker than typing out "string_repeat", and it works.

Edit: It turns out you have to put the number first; I forgot about that because I haven't used that feature much and only learned about it through a friend. But it's not that big of a deal, I could care less if it's "fixed".

As for my bug, if an extension package has a DLL in it, the user must run GM as an administrator to install it due to permissions Windows sets on Program Files. It caused a ton of problems with my extension and forced me to make a separate DLL version of it.

Maybe you could fix this by copying to %appdata% or a similar user-owned directory.

Edited by amd42, 08 March 2011 - 04:58 AM.

[Desert Dog]

And I distinctly remember it working...

Aaand I tried it now, and it doesn't work. (Same error as Big J) Edit: Really amd? I have to try it again...

I hope I don't sound rude, but Mike already has a ton of 'bug' reports already. He's looking for immediate, actual bugs that users run into, and have issues with... vague reports such as this, with the two examples you gave clearly not tested aren't helping anyone, and avoiding these sorts of reports is probably why he started this topic.

(Regardless, I'd hardly call this a bug... please don't think of this topic as a wish-list.)

We all want the bugs to get fixed, the best way to help is by spending as much time being as clear as possible about the bugs, and what causes them. Any time saved for Mike means more bugs fixed faster for us.

I don't mean to sound angry at all. I have lots of wishes, too, but this isn't the place to put them.

Edited by Desert Dog, 08 March 2011 - 04:43 AM.

[GameGeisha]

Not only is it unnecessary, but I've never seen such syntax for that purpose anywhere else, so allowing it encourages bad habits.

You can most certainly use that syntax in Python. But I will have to stick to my policy about "undocumented" features. Either put it in the manual or get rid of it.

Also, this syntax is not commutative. The number has to come first. This is an example from my tests:

//Error: Wrong arguments to *
show_message("*" * 3);
//OK: ***
show_message(3 * "*");

Had a look a the surface bug... I think its a remnant from GM7, when the surface is grabbed it checks to see if ALL alpha is 0, if it is... it makes it 255. This helps newbies who don't know much about alpha, and as it's historical can't be changed...

This reflects a significant issue in GM, not a physical bug but a conceptual one: designing advanced features with too much focus on accessibility to novice users who don't know what they're doing, so much as to decrease the usability of the advanced features as a whole.

Surface handling is not novice territory, there no need to make it too accessible as to cripple it with "intuitive" side effects.


Now, back on topic, my biggest issue with GM so far is its historic problem with NVidia video cards. My newest laptop has an NVidia card and several games from YoYo that use surfaces and/or transparent sprites experience serious graphics problems (e.g. this game produces garbled HUDs). I played the same games using an older machine with an ATI card and everything was fine. NVidia video cards are quite common, and it would be great to have a fix or at least a known work-around setting that can be provided to players/developers who use these cards.

GameGeisha

Edit: Grammatical glitches.

Edited by GameGeisha, 08 March 2011 - 04:55 AM.

[Shadow Link]

Other bug I saw:
When you "search" for an empty string (in the script editor) gamemaker gives an access violation.

I wasn't able to replicate this bug right now, but I just want to add that I have indeed had Game Maker crash in the past before due to this bug. It happened when I did a search/replace, and was completely unexpected so I lost a good chunk of work, however it was only scrap work for a random code test so nothing important was lost. Since then, I've been a little hesitant to use search/replace so a fix here would be much appreciated

[BlueMoonProductions]

There's a big bug in GM's 3D rendering of transparant triangles.
I made a small example: http://updo.nl/file/8a66877a.gmk
Rotate the camera with the arrow keys and zoom with the scroll weel.
There are three triangles:
-a big one, this is the furthest one, and it is drawn first.
-a small one, this one is drawn 2nd, and it is transparant(alpha = .2).
-a medium one, this one is drawn last, and it is NOT transparant.

Now WHY do I see the big triangle through the small one, while the medium triangle is between them?
If I would first draw the big triangle, then the medium triangle, then the small triangle, everything would work.
But if you draw something transparant, and after that, draw something else behind it, it is not being rendered.

I'm profiting of this in my current game, however, I prefer to see it fixed.

[Razon]

For the replace and many other minor IDE glitches or errors, I had reported what they were and how to reproduce them in this bug report http://bugs.yoyogame...view.php?id=544.

As for the glitch that I want fixed most, it relates to the wrong sprite frame being drawn. There's more than 2 different glitches that can cause this to happen, the first always occurs under common circumstances, and the other only occurs when there's high precision variables involved. Will see about putting some info together for it again, lost all the examples and discussion from my initial report on the matter when they shut the GM8 beta tracker down awhile back- in which it was said that it wasn't going to be fixed for that release.

Edited by Razon, 08 March 2011 - 07:55 AM.

[desolatorXT]

[CUT - No feature requests]

Edited by Mike.Dailly, 08 March 2011 - 08:02 AM.

[kburkhart84]

distance_to_point(x,y) Returns the distance of the bounding box of the current instance to (x,y). (If the instance does not have a sprite or mask, the result of the function is undefined.)
distance_to_object(obj) Returns the distance of the instance to the nearest instance of object obj. (If the instance or object does not have a sprite or mask, the result of the function is undefined.)

This is from the documentation. I call this a bug, though it is a documented bug. The first function should theoretically not need a sprite in any case, unless the documentation is wrong, because it supposedly references the bounding box, and an x/y coordinate. The second should be able to use the actual x/y of the objects, and in fact, should really be that way, since the object center is "where" things are. I'm not going to request extra functions for "sprite-to-sprite" distances since this is the wrong section for that, but generic distance functions such as these seem to me they shouldn't depend on a "graphic", rather actual positions, but maybe that is just me.

[DirtyUnicorn]

The "Execute Code" starts with its boundarys of the screen.
So when i write code, i cant see the errors coming up, and writing lots of lines it goes off screen. Really annoying. Its probably an easy fix, its really just annoying having to re-size every time i start a new .gmk, and get coding.