182 replies to this topic

[icuurd12b42]

sound_play performs pretty awfully on certain machines. I'm reporting this second-hand, as it doesn't happen on any of my machines. Every single time sound_play is called, the framerate drops by anything between 10% and 50% for about a second (which I'm guessing is because that's the duration during which the sound plays), making for a very erratic experience indeed.

Meanwhile reduce the sound quality of the wav to 22kHz or less, mono if possible. Especially for sound that you play at repetition like a single bullet sound comming out of a machine gun. I had the same problem with the framerate dropping to 5fps when 5 AI and the player had a machine gun in hand.

GMFMODSimple.dll is has no trouble playing 44kHz sound bites...


Mike.Daily, You can peruse and check how the sound system is initialized in GM... if you see a way to force software mode/disable hardware mode on initialization... Harware mode is usually the cause for this, a mode no longer an emprovement on the system since today's PC are fast enough to offer better or equal performance to hardware mode with less problem (and more features). I hear the fmod people will depricate their own hardware mode of their sound engine.

[blackhawkrobbo]

Hey,

The biggest bug i've experienced so far is... GM7 and 8! I've been working on my top down shooter quite some time now, and erm, when i play the game from GM6.1 it works like a charm
30FPS
20% CPU load
60MB ram usage

however, some frieds with vista started to complain, so i thought - well, lets give GM8 a try. So i started working in GM8..
The same source, compiled in GM8 now has:

22FPS
70-90% CPU Load
132MB Ram

So im not really amused with GM8. please fix this in gm8.1 ??

cheers

[paul23]

[CUT - one only please ]

[Seven Stars Spirit]

I opened GM8, I created only a room and nothing else and then I exported an executable. And you know, the size of the .exe which contains just an empty room, is 2,22 MB !

This is not something new to everyone. But, this is (one of) the biggest "bug(s)" in GM, for my opinion. Which actually, it isn't a bug...

[Dark Matter]

[CUT - one only please ]

This is one I had forgotten about, but is really frustrating when trying to replace text. Please don't ignore it...

Edited by Dark Matter, 13 March 2011 - 10:22 PM.

[HaRRiKiRi]

I opened GM8, I created only a room and nothing else and then I exported an executable. And you know, the size of the .exe which contains just an empty room, is 2,22 MB !

This is not something new to everyone. But, this is (one of) the biggest "bug(s)" in GM, for my opinion. Which actually, it isn't a bug...

Yup, that's not a bug and thus shouldn't be here. Also 2.22 is irrelevant as when you add several objects, sprites, backgrounds and rooms it goes up to 2.24mb. So when an average game is finished its like 3mb. So yeah, its big when empty, but its small when full.

So im not really amused with GM8. please fix this in gm8.1 ??

I would also want to see your game, because by my tests (and there have been many) GM8 is faster sometimes even by a third. Script execution is faster for sure. Do you use any dll's or extensions? I think something else is slowing the game down.

[Seven Stars Spirit]

@Seven Stars Spirit: You kiddin' me right?

Compared to game making programs that export .exe's with a size of just some KB... [CUT]

So, there isn't any change to lower the size...?
I'm just (again) pointing it out. It's up to you to think if that needs to be optimized...you know.

[Seven Stars Spirit]

Feel free to go and use something else.

Okay.

[Manuel777]

All programs have a minimum size, this is probably ours - and it's going to get bigger.

Bigger? as long as it gets faster im a very happy guy.

Feel free to go and use something else.

Okay.

Oh boy..

[thatshelby]

There could be measures to get rid of it, AFAIK, but it's not something that would be done on a point release.

[~Dannyboy~]

Forgive me if this has been mentioned previously, I have read the posts and don't recall seeing it.

A bug I remember encountering is that floor(x) and ceil(x) do not work correctly for large numbers. Specifically they do not return the right value if the result does not fit in a 32 bit integer. This is rather annyoing as GM's real values are capable of holding significantly larger values. IIRC from previous discussions of this bug, the cause of this is due to the fact that Delphi's methods for these operations return a 32 bit integer. I'm sure it would be easy enough for you to create a version which worked for all double values though.

Code to duplicate:

floor(1000000000000.5) // Results in -727379968
ceil(1000000000000.5) // Results in -727379967

Work-around which can be used:

// floor(x)
return x - frac(x)

EDIT: fixed work-around, thanks Big J, but note "div" suffers from 32 bitness in the same way as builtin floor and ceil:

// floor(x)
return x - frac(x) - (x < 0)

// ceil(x)
return x - frac(x) + (x > 0)

AFAIK this does not apply to round(x). There may be other math functions which suffer from similar issues, I cannot recall any others, if anyone knows any please post them here or PM me and I'll edit this post.

Thanks Mike for concidering fixing this issue!

EDIT: I see this bug is mentioned in the list flexaplex provided, on this page.

Edited by ~Dannyboy~, 14 March 2011 - 10:46 AM.

[Big J]

Bigger? Well, that's why compression was invented.

The "work-around" you posted is not flooring, it's truncation, just like this:

return argument0 div 1;

For example, -5.5 is supposed to floor() to -6, but your work-around will return -5.

// floor(x)
return argument0 div 1 - (argument0 < 0);

// ceil(x)
return argument0 div 1 + (argument0 > 0);

thanks Big J, but note "div" suffers from 32 bitness in the same way as builtin floor and ceil:

D'oh!

// floor(x)
return argument0 - frac(argument0) - (argument0 < 0);

// ceil(x)
return argument0 - frac(argument0) + (argument0 > 0);

Edited by Big J, 14 March 2011 - 04:10 PM.

[Markolainen]

I don't like that the code editor don't remember its position and if it's maximized. If you maximize it it remembers the size but goes in a window. If you open and close windowed editors they end up a little bitr to the right and a little bit down from the last one.

[nickydude]

Perhaps a list of the bugs confirmed to be fixed could be placed in the first post?

[TheMagicNumber]

[CUT- Feature request]

• Remove bitmaps from resource file
• Adjust offsets for runner data
• Runner is now several hundred KB smaller.

Edited by TheMagicNumber, 14 March 2011 - 09:35 PM.

[Shadowrend]

[CUT - Feature request]
[CUT - again. Anything which is NOT a bug, is by definition a feature request.]

Edited by Mike.Dailly, 14 March 2011 - 08:45 PM.