• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Windows GM8/GM8.1 low framerate issues on Windows 10

T

Tacchan

Guest
Hey, is anyone here still using olde GM8 or 8.1 on Windows 10? I'm unable to pass 20fps on my game that used to run at 60, and I can confirm that any other game made with those versions also suffer the same issue.
 
Last edited by a moderator:

Lukan

Gay Wizard Freak
*blows dust of GM8.1*


Seems to run fine from the IDE...
I missed where you said all of your projects are doing it...
This software hasn't been updated in years, so it must be either other software running on your PC or perhaps a windows update I haven't been hit with yet.

Have you made any significant changes to your code recently?
Specifically drawing or file handling code? These slow GM8/8.1 down tremendously if done improperly.
 
T

Tacchan

Guest
*blows dust of GM8.1*
Mmm delicious depreciation dust!


Seems to run fine from the IDE...
I missed where you said all of your projects are doing it...
This software hasn't been updated in years, so it must be either other software running on your PC or perhaps a windows update I haven't been hit with yet.
Yeah, I think this is a Windows update issue unfortunately, as it only started happening recently after taking a break from development (so, game was untouched, hardware was unchanged etc).

Came across this while looking for answers, though obviously pretty much nobody is using 8 anymore, it's something.
https://old.reddit.com/r/gamemaker/comments/eq8nh0/game_maker_881_games_with_lag/

Cheers for testing btw, I'm using Windows 10 build 1909 on my end.
 
T

Tacchan

Guest
Sorry for doublepost, can't edit because mods are sleeping.
Okay this is very strange, after extensive research on what could cause this, I came across people saying that re-connecting a previously connected controller would fix their issues, I had dismissed this at first however as alternative to pulling out my hair I gave it a go, paired my DS4 and launched a few games, and to my surprise they all performed perfectly. Odd thing is my personal project doesn't do any gamepad checks, just keyboard, yet still requires that I have my controller connected.
2D Mario fangames with controller support run at a slideshow 1-3fps when no controller is connected, while my 3d game runs ~20fps without the controller.
Very odd...
 

O.Stogden

Member
If you own Game Maker Studio 1, you can probably import a GM8.1 project file and update it to work, that should solve any compatibility issues with Windows 10. It was offered for almost nothing in a few places, such as in Humble Bundles, so don't know if you picked it up at any point.
 
T

Tacchan

Guest
If you own Game Maker Studio 1, you can probably import a GM8.1 project file and update it to work, that should solve any compatibility issues with Windows 10. It was offered for almost nothing in a few places, such as in Humble Bundles, so don't know if you picked it up at any point.
I've attempted porting to GMS1.4, but it turns out they deprecated my entire game basically lol, if I can't work around this issue of needing a gamepad connected I may have to bite the bullet and do it anyway, but jeez that's a lot of refactoring (if that's even the word).
 
T

Tacchan

Guest
Now that I understand the issue a little better it seems like this issue is pretty well known and affects a wide number of versions of GM and revolves around the old implementation of joysticks if I'm getting this right.
Again, I don't actually use any joystick code, but I'm guessing 8.1 is checking for controllers anyway? It seems to affect Studio users too, if they use legacy joystick code. Either way, it eats up CPU and destroys performance until you give it a controller.

Oddly, while it may just be because of the controllers popularity, many posts I've seen about this issue on commercial games are using a DualShock 4.

That's a shame :/ Must have been lucky with my project, I didn't need to alter a great deal.
Yeah! Though maybe I'm exaggerating a little, it'd be a tedious afternoon at least. Also last time I (re)attempted, I was getting syntax errors while importing, with the resulting gmk having missing rooms due to them having two underscores or something along those lines, oh who knows.
 

O.Stogden

Member
Could be because Dualshock 4 use DirectInput and Xbox controllers use Xinput? Might change how it handles it, but that's just a guess.

The old Joystick functions use DirectInput I think, the new gamepad functions can use both.
 
T

Tacchan

Guest
Oh, I should have mentioned that I (and presumably the vast majority of DS4 users) use a wrapper to output xinput, which actually appears to somewhat work in GM, afaik it's wonky and missing analog axis support though.

This doesn't seem to happen on a fresh W10 install that hasn't had a controller connected, however it could just be a matter of time until it'd happen there too, as I'm now seeing this problem has been around since at least 2011.
Only workaround I can think of is somehow spoofing a controller to GM just to keep it happy, regardless of there being any actual physical hardware. If only something like "joystick_debug_plugged" existed.
 

Yal

🐧 *penguin noises*
GMC Elder
Now that I understand the issue a little better it seems like this issue is pretty well known and affects a wide number of versions of GM and revolves around the old implementation of joysticks if I'm getting this right.
Again, I don't actually use any joystick code, but I'm guessing 8.1 is checking for controllers anyway? It seems to affect Studio users too, if they use legacy joystick code. Either way, it eats up CPU and destroys performance until you give it a controller.

Oddly, while it may just be because of the controllers popularity, many posts I've seen about this issue on commercial games are using a DualShock 4.



Yeah! Though maybe I'm exaggerating a little, it'd be a tedious afternoon at least. Also last time I (re)attempted, I was getting syntax errors while importing, with the resulting gmk having missing rooms due to them having two underscores or something along those lines, oh who knows.
One thing you should do before trying to import is go to Scripts --> Check Resource Names ("scripts" in the menu bar, not in the resource tree) and fix all issues that it finds (invalid names, duplicate names, names using reserved words). In GM8 it was optional to follow those rules (except invalid names wouldn't work in code, only D&D) but it's mandatory in Studio. It should get you past the "most resources are missing" step, at least.
 
T

Tacchan

Guest
One thing you should do before trying to import is go to Scripts --> Check Resource Names ("scripts" in the menu bar, not in the resource tree) and fix all issues that it finds (invalid names, duplicate names, names using reserved words). In GM8 it was optional to follow those rules (except invalid names wouldn't work in code, only D&D) but it's mandatory in Studio. It should get you past the "most resources are missing" step, at least.
Oof, the legend himself! Been following your work for years, actually learnt how to work with 3d projection and collision in GM8 with your olde fps example!
Thanks for the tip, that'd surely help a lot. I should really plan out how I want to finish this project, I'm currently designing with 30fps being default, with unlocked framerate being available for those with killer single core performance or whatever it takes to actually render at 60fps with the delphi runner - saying that alone inspires me to port to GMS for the new runner alone.

BTW have you encountered the joystick fps bug in Studio at all? I can't tell if it's really an issue in 1.4 anymore or if it only shows up when joystick_* is used?
 

Yal

🐧 *penguin noises*
GMC Elder
Oof, the legend himself! Been following your work for years, actually learnt how to work with 3d projection and collision in GM8 with your olde fps example!
Thanks for the tip, that'd surely help a lot. I should really plan out how I want to finish this project, I'm currently designing with 30fps being default, with unlocked framerate being available for those with killer single core performance or whatever it takes to actually render at 60fps with the delphi runner - saying that alone inspires me to port to GMS for the new runner alone.

BTW have you encountered the joystick fps bug in Studio at all? I can't tell if it's really an issue in 1.4 anymore or if it only shows up when joystick_* is used?
Aww, you're flattering me~ (Especially considering I didn't really get better at 3D since those days - I've been bashing my head against trying to get shaders to work for the last 5 hours in a futile attempt to make one of my old GM8 projects look good :p)

GMS1 has native support for XInput (XBOX / PS3+ gamepads), and I've never encountered any lag issues in any of my GMS1 games (that is to say, all of my games :p). I suppose those might be related, if Windows now tries force-feeding XInput into all apps and only gives them the DirectInput (old "joystick" API) raw data if they time out trying to process it.... GMS1 games having the API means they don't need to get the slower default data. Or something. I just realized the games were slower without a gamepad so my entire logic was flawed. Oh well.

The Game Maker XInput API also has a bunch of advantages over the old DirectInput API because buttons are guaranteed to always be in the same spots, so you can refer to the "left face button" or "right shoulder button" and know the button is there and comfortable to press. With the joystick API, buttons just are numbered and the joystick manufacturer has no real rules to follow for placement.

In GMS1 and onwards, you can get a lot more performance by using "vertex buffers"... it's a fairly straightforward change. First define a vertex format with the same data as the most detailed d3d_vertex_* function you wanna use, create a convenience script that adds the same data in the same order, and then it's just a big text-replace party.
Code:
///model_vertexify_ff(buffer,x,y,z,nx,ny,nz,u,v,col,alpha)
vertex_position_3d(argument0,argument1,argument2,argument3)
vertex_normal(argument0,argument4,argument5,argument6)
vertex_texcoord(argument0,argument7,argument8)
vertex_colour(argument0,argument9,argument10)
Using a single vertex buffer for the entire level, I made my 3D game get like a 50x overall performance boost... and drawing the level went from 70% to 4% resource usage. Basically, a single vertex buffer takes the same time to draw no matter how many vertices is in it.
(a "vertex buffer" is just a fancy name for a raw 3D model, btw)

There's another caveat you need to keep in mind: now you provide the primitive type (triangle list / fan, etc) when submitting the vertex buffer for drawing, so all polygons you add to the buffer needs to be the same format. (And this usually means you have to convert any triangle-fans into triangle-lists). It gets a bit involved, and I've consumed a large amount of sketch paper drawing out in what order you need to draw the vertices to create the same triangles... visualizing this stuff helps a LOT with getting the maths right.


There's a bunch of other incompabilities as well, like execute_string being gone... you can get around that by using script_execute() and putting every string into a script, unless you built the strings to execute dynamically. The order Create, Room Start and Instance Creation Code are run are different (and changes again in Studio 2). I don't remember all the stuff off the top of my head, it's probably better if you ask once you actually run into any issues than me just making this wall of text any longer with preemptive warnings :p
 
Top