Jump to content


Member Since 12 Aug 2005
Offline Last Active Oct 02 2015 06:23 PM

Topics I've Started

Converting GLSL ES to HLSL 9

30 September 2015 - 07:06 PM

Just a general question: are there any tutorials / articles on converting shaders between GLSL and HLSL (information particular to GM:Studio isn't necessary although that'd be nice)?


I've Googled and found a few, but the information wasn't enough to enable me to convert my shaders between the two without problems. This one is a good guide that I found though: https://alastaira.wo...ders-to-cghlsl/-- but it isn't complete, there are other differences besides those mentioned there.


The reason I'm asking is because I currently use GLSL ES shaders, which seem to take a long time to compile (and they are compiled each time you run the game, leading to a loading screen of about 20 seconds just for compiling the shaders). I want to test if porting those shaders to HLSL 9, considering that the game is Windows-only anyway, may lead to a faster load time for the game, but I'm not familiar enough with shaders to convert GLSL to HLSL myself, so I was wondering if there are any good guides to doing so besides the one I linked above.

string() only goes up to 2147483647, returns blank if the number is higher

20 September 2015 - 03:48 AM

the string() function seems to only return accurate values up to 2147483647, if you give it a number higher than that it returns a blank string. is there a way around this? why is it that variables can go higher than that, but string() can't return a value higher than that? i know that 2147483647 was the old limit for variables, but it's not the current limit, so, why the limit in the string() function?


this is for game maker studio.

shaders cause the game to take a long time on splash screen (20 seconds)

08 August 2015 - 04:20 PM

my game was spending an abnormally long amount of time starting up, it used to be instant, but eventually became 20 seconds during the course of my game's development. i tried creating a test file, a copy of the game, where i'd remove each part of the game individually to try to figure out what the game was doing during that splash screen startup, and it turns out the only thing that made a difference was whether the game had shaders or not. when i deleted the shaders, the game started up instantly.


so basically, is there a way to reduce the shader compilation time? couldn't game maker pre-compile the shaders rather than compile them each time the game is run? why is it necessary that shaders be compiled each time the game is run, rather than only once, when the game itself is compiled and a project file is created?


this is for windows, and this happens both for normal windows and for the windows YYC. i use about 6 shaders, but they are fairly complicated ones. when i delete the shaders and replace them with dummy passthrough shaders, the game's startup time (time spent on the splash screen) is instant. when i use the shaders i wrote, the game's startup time (time spent on the splash screen) is 20 seconds.


i have also just reported this as a bug, but i'd like to see if anyone here has any solutions, or if anyone else has experienced something similar.

problem with new gm studio and sound files

08 August 2015 - 03:12 PM

in the new v1.4.1629, there seems to be a big problem with how the game stores sound files that i've encountered in several different ways.


first, once you run a game once, if you go to the 'sounds' folder on the sidebar, they will all point to the wrong location: somewhere in the temp directory rather than where the game actually stores the sounds. those sounds are unplayable with the play button because their location seems to be stored wrong.


second, if you export a project to a new location after the above has happened, the sound files are not saved when exporting; they'll be gone. when you run the game, the game will still run, but all the sounds will be automatically replaced with the windows "ding" sound. the compile form will mention that the sounds were not found and that they were being replaced with the windows ding sound.


also, even when you just load up a game project file normally, the directory locations are wrong, they have a double \\ in their directory structure rather than a single \. for instance, the correct location might be:


C:\Users\rinkuhero\Desktop\idefense speedtest\idefense.gmx\sound\audio\sound_bo.wav


but it will be listed as:


C:\Users\rinkuhero\Desktop\idefense speedtest\idefense.gmx\\sound\audio\sound_bo.wav


that double backslash doesn't seem, alone, to cause problems, but once you run the game once, the entire directory where a sound is stored will be listed incorrectly, and point to the temp directory instead

dragging included files from one folder to another breaks the game

08 August 2015 - 02:03 PM

in the latest version of gm studio, v1.4.1629, if you go to included files, and have several folders, and drag a file from one folder to another, instead of actually moving it to that folder in the actual directory structure that the game uses to store those files, it instead creates a new folder in that folder with the same name as the file that you just moved, an empty one. e.g. if i drag a file called "circuit1.pef" from a directory called "custom" to a directory called "achievements", it deletes the file circuit1.pef from "custom", and creates a new empty directory in "achievements" called "circuit1.pef"


this, in effect, causes that file to disappear, since the actual data for that file is gone, instead you get just a folder with that file's name instead. this seems somewhat inconsistent in that it works for some files but not others, though. i suspect it may have to do with the extension type perhaps? not sure yet. but in any case try dragging included files around in nested directories and most of the time it breaks it and the files disappear, sometimes the file is moved correctly, sometimes the file is moved into a directory with the same name as that file, sometimes a directory with that file's name is created but no file is moved, etc. etc., it just seems very broken.