The truth about "Obsolete GMStudio functions

[time-killer-games]

That ignorant fucker NakedPaulToast posted a topic over at the GMC that strikes me as rediculously hilarious. Here's what it says (assuming he got this information from YYG) please note I added the text in bold...

The functions removed are not obsolete, (almost all of them!) YYG called them "obsolete" with false reasoning (lying), the real reasons these function are taken out because they are temporarily not present but they will be added back overtime or re-implimented with all the same features but different function names, which is a pain in the ass for people who plan to port their older GM 8.1 and below projects. Notice how NakedPaulToast uses YYG's words. How these functions "are not compatible" with all platforms is bullshit hogwash. YYG decided they were way too anxious to make truck loads of money so they release Studio even though it was not only bug ridden, it's a work in progress. The fact is YYG didn't want to admit that which is very silly.

With today's GM:Studio update the manual has documented all kinds of functions that have been removed and considered obsolete.

This has obvious relevance to current Studio and HTML5 users, but is also important to GM8.1 (or earlier) and GM4Mac users.

GM Windows and Mac users, if you ever plan to move to Studio (HTML5, Windows c++ runner, Mac c++ runner, iOS, Android Symbian, and any future export) then you should stop using them now. Even if you don't plan on moving to Studio, but do plan on moving to GM:9, it's probably a good idea to stop using them and consider them deprecated, as they have a high probability of not being supported beyond GM:8.1 and GM4Mac:7.

You should also be aware that not all of the functions associated with their respective categories have been removed. For example Particles, particles are still supported but only some of the particle functions have been removed. The documentation has also documented some of the broad reasons that these functions have been removed. Including:
Not conducive to multiple platforms
Usage requires taking control of device
Require code to be created dynamically
Block the execution of the runner
Horribly slow or poorly implemented
Not compatible with newer methods of doing things

If your current project does use any of the above, and you not plan on porting it to a future version of GameMaker, continue using it.



Obsolete Functions:
Spoiler


Triggers
I have no side about the registry functions, but I'm very positive they should work on windows, Mac, and Linux.
Registry Functions
registry_exists
registry_exists_ext
registry_read_real
registry_read_real_ext
registry_read_string
registry_read_string_ext
registry_set_root
registry_write_real
registry_write_real_ext
registry_write_string
registry_write_string_ext

CD functions work just fine on windows Mac and Ubuntu I don't know who the hell they thought they were kidding. window_* functions aren't "obsolete" even though those only work on windows Mac and Linux. It's because in a nutshell YYG were too lazy to bother with writing these functions per platform, it's only a matter of time these functions will somehow become "unobsolete" which makes no fucking sense but they are already doing this with other functions which at a time were "obsolete but aren't anymore.
CD Functions
cd_close_door
cd_init
cd_length
cd_number
cd_open_door
cd_pause
cd_paused
cd_play
cd_playing
cd_position
cd_present
cd_resume
cd_set_position
cd_set_track_position
cd_stop
cd_track
cd_track_length
cd_track_position
MCI_command

I already heard from a few people over at the YYG sandbox these functions are going to be back soon: (Windows, Mac, Linux)
Display Functions
display_set_all
display_set_colordepth
display_set_frequency
display_set_size
display_test_all
screen_refresh
screen_wait_vsync
set_automatic_draw
set_synchronization

the splash functions in specific becoming "obsolete" YYG has no excuse for. show_info is just a ditch text document viewer (RTF is a very universal format not just the desktop platforms even html5, android, iOS and (yes) everything else supports this, likewise for video playback (splash_show_video) they implemented ffmpeg for audio the fact they could just as easily add video support with ffmpeg it's drum they haven't done this yet. and embedding webpages via splash_show_web() can be done on all platforms (rather easily, too) Android and iOS for example have a built-in WebView UI control and it comes directly in the ADK and XCode kits. Needless to say you can also view plain text on all platforms.
Splash Functions
load_info
show_info
splash_set_adapt
splash_set_border
splash_set_caption
splash_set_close_button
splash_set_color
splash_set_cursor
splash_set_fullscreen
splash_set_interrupt
splash_set_main
splash_set_position
splash_set_scale
splash_set_size
splash_set_stop_key
splash_set_stop_mouse
splash_set_top
splash_show_image
splash_show_text
splash_show_video
splash_show_web


If particles didn't work then why can you find thousands of apps on Google play, the AppStore, etc all use advanced particle systems (both 2D and 3D) but GMStudio can't hardly implement just primitive 2D particles, let alone 3D
Particle Functions
part_attractor_clear
part_attractor_create
part_attractor_destroy
part_attractor_destroy_all
part_attractor_exists
part_attractor_force
part_attractor_position
part_changer_clear
part_changer_create
part_changer_destroy
part_changer_destroy_all
part_changer_exists
part_changer_kind
part_changer_region
part_changer_types
part_deflector_clear
part_deflector_create
part_deflector_destroy
part_deflector_destroy_all
part_deflector_exists
part_deflector_friction
part_deflector_kind
part_deflector_region
part_destroyer_clear
part_destroyer_create
part_destroyer_destroy
part_destroyer_destroy_all
part_destroyer_exists
part_destroyer_region

I don't really need to explain this, I've done research you can manipulate sound in realtime on all the platorms except html5 (though in html5 volume CAN be adjusted.
Sound Functions
se_chorus
se_compressor
se_echo
se_equalizer
se_flanger
se_gargle
se_none
se_reverb
sound_3d_set_sound_cone
sound_3d_set_sound_distance
sound_3d_set_sound_position
sound_3d_set_sound_velocity
sound_background_tempo
sound_discard
sound_effect_chorus
sound_effect_compressor
sound_effect_echo
sound_effect_equalizer
sound_effect_flanger
sound_effect_gargle
sound_effect_reverb
sound_effect_set
sound_get_preload
sound_restore
sound_set_search_directory

They already re-implemented these with different function names (see the "networking tutorial) also some ignorant faggot at the GMC said YYG got rid of the mplay functions because they had bugs and didn't always work how they should've. So why not fix the bugs instead of renaming the functions and argument count changes? That just leaves all the more work for porting old projects for no reason.
mPlay Functions
mplay_connect_status
mplay_data_mode
mplay_data_read
mplay_data_write
mplay_end
mplay_init_ipx
mplay_init_modem
mplay_init_serial
mplay_init_tcpip
mplay_ipaddress
mplay_message_clear
mplay_message_count
mplay_message_id
mplay_message_name
mplay_message_player
mplay_message_receive
mplay_message_send
mplay_message_send_guaranteed
mplay_message_value
mplay_player_find
mplay_player_id
mplay_player_name
mplay_session_create
mplay_session_end
mplay_session_find
mplay_session_join
mplay_session_mode
mplay_session_name
mplay_session_status

all of these should work on Windows Mac and Ubuntu
Message Functions
text_type
button_type
input_type
caption_health
caption_lives
caption_score
get_color
get_directory
get_directory_alt
get_open_filename
get_save_filename
highscore_set_background
highscore_set_border
highscore_set_colors
highscore_set_font
highscore_set_strings
highscore_show
highscore_show_ext
message_alpha
message_background
message_button
message_button_font
message_caption
message_input_color
message_input_font
message_mouse_color
message_position
message_size
message_text_charset
message_text_font
show_health
show_lives
show_menu
show_menu_pos
show_message_ext
show_score

these (along w/ the misc functions) are the only ones I'm actually glad they got rid of they have better things to worry about implimenting
Dynamic Functions
execute_string
object_add
object_delete
object_event_add
object_event_clear
room_set_code
script_get_text
variable_global_array_get
variable_global_array_set
variable_global_array2_get
variable_global_array2_set
variable_global_exists
variable_global_get
variable_global_set
variable_local_array_get
variable_local_array_set
variable_local_array2_get
variable_local_array2_set
variable_local_exists
variable_local_get
variable_local_set

It can be done, on all platforms, but because of YYG being lazy we have to write our own transitions with surfaces and shaders.
Transition Functions
transition_define
transition_exists
transition_kind
transition_steps

Miscellaneous Functions
discard_include_file
error_last
error_occurred
export_include_file
export_include_file_location
gamemaker_pro
gamemaker_registered
gamemaker_version
secure_mode
set_application_title
set_program_priority
sleep - this function my be a little pointless buy FYI it can easily be implemented without any work involved really.

And lastly, game_save and game_load used to be obsolete but it isn't anymore because they finished writing it for every platform (except for the YYC ATM) and screen_redraw / screen_refresh would be no sweat for YYG  to re implement so IDK why they haven't yet they are not entirely useless. With screen_redraw/refresh you can make high quality ray tracing which I find to be rather cool (see the ENIGMA examples/games page.)

I find it entirely stupid that YYG nearly incapable of being honest over such silly concepts. If they are being lazy or anxious to share their half eaten (by bugs) software and make thousands a month selling it they could at least admit it instead of calling everything the haven't completed yet obsolete.

[Goombert]

Four things.

One, those functions are deprecated if you try to use them Studio will usually error out the ass.

Two, this basically sounds to me like they just don't know what the fuck they are doing, because we implemented a lot of that shit to other platforms. What the fuck does taking control of a device even mean? Any sort of device managers Studio should already be in control of, otherwise how the fuck does it have retina functions and shit. This honestly sounds like 100% laziness to me.

Three, I would make it practice to never buy anything off of them ever, not just Game Maker, but any software they ever come up with.

Four, they are probably watching our site and noticing how it's catching up and doesn't deprecate these features which leads me to think this is why they are trying to recant earlier statements.

[TheExDeus]

I know YYG bashing is very popular here. But I, as a rational person, see the reasoning for most of these changes.

I have no side about the registry functions, but I'm very positive they should work on windows, Mac, and Linux.

"Registry" itself actually is only on windows. Mac and Linux has some kind of equivalent, but that does require additional work (as there is no POSIX functions or something like that for registry). More importantly though, those functions are useless. They are "obsolete" - it doesn't mean "we can't implement them", but it means "nobody uses them" and "if you need to use them, you are doing something wrong". No game in the past 5 years has used registry to store information. It was popular many years ago, but now it is considered wrong. GM itself used registry to store things like safe mode and even highscores. That could of been the stupidest decision they made, but removing them was probably the smartest. Besides, registry functions also pose security risk. So while it can be an extension, it shouldn't be inside GM. So I understand their rational.

CD functions work just fine on windows Mac and Ubuntu I don't know who the hell they thought they were kidding.

Again, it's not about whether they work or not. It's whether a game making software should have them and how used are they. I can personally tell you that I haven't seen a single project using those functions (and I have used GM since 2002)... cd_open_door()... seriously, who the hell even uses cd roms anymore? My last two desktops PC's didn't even have cd roms.

I already heard from a few people over at the YYG sandbox these functions are going to be back soon: (Windows, Mac, Linux)

These are not multi-platform (as far as I know you cannot change things like frequency or resolution on an Android device). But I am sure they will be back for desktops, as these are quite basic functions and a game might use them.

the splash functions in specific becoming "obsolete" YYG has no excuse for.

Same excuse as for cd_ and registry_. Adding them were a mistake in the first place. Again, they are rarely used and the only time show_info() were used was for examples (which I guess is the only reason they were implemented). In a game of any kind these functions should never be used. They are very limited in the way they can be configured and so 100% of the time they look like shit. The only thing they encourage are low quality games. And there is no cross-platform way to implement them. This means additional work for every new platform for 0 gain. So again, very smart on their part.
And while video playback seems like a cool feature - it was also NEVER used. So I guess they could leave that one function or just let someone make an extension for that. The rest though, were obsolete.

If particles didn't work then why can you find thousands of apps on Google play, the AppStore, etc all use advanced particle systems (both 2D and 3D) but GMStudio can't hardly implement just primitive 2D particles, let alone 3D

1) This was also probably because they were rarely used and most people implemented their own particle system (I have done that numerous times in GM and ENIGMA). 2) They removed just the physics part - attractors and deflectors - this is probably because they now use Box2D physics as their underlying physics engine. So they will either reimplement them via that system or will allow the programers to use it on their own. So again, quite smart. No need for several physics engines.

I don't really need to explain this

But you should. Most of them were not used.

They already re-implemented these with different function names (see the "networking tutorial) also some ignorant faggot at the GMC said YYG got rid of the mplay functions because they had bugs and didn't always work how they should've. So why not fix the bugs instead of renaming the functions and argument count changes? That just leaves all the more work for porting old projects for no reason.

They were bad, but not because of implementation, but because they used microsofts mplay (they are called that for a reason). That is why no one used them and everyone just used 69LL. Then they wanted to implement them properly so they can use buffers and other stuff. They couldn't do that without breaking mplay, so they made a new system. They could of made a wrapper for mplay (like I suggested some time ago for ENIGMA), but I guess there is no sense to have two multiplayer systems (especially if one is wrapper for the other). So while they could support mplay, I don't think it's very useful to support very old and rarely used stuff. After all - GM is not about porting games. It's about making them.

all of these should work on Windows Mac and Ubuntu

That's not the point.

these (along w/ the misc functions) are the only ones I'm actually glad they got rid of they have better things to worry about implimenting

And for me it's just the contrary as from all that list of functions these are the only ones I ever used. I get why they removed stuff like execute_code, but I did like variable_local_exists() which I used to make modular instances. But no biggy, there is usually better ways to do this. execute_code() did allow making very powerful dialog systems though as well as variable_local_set and _get.

It can be done, on all platforms, but because of YYG being lazy we have to write our own transitions with surfaces and shaders.

Again, never used.

Miscellaneous Functions

Here some functions were useful. For example, I liked error_last as I used it for a console (so it just doesn't crash on a trivial error, but outputs the error in an in-game console), but that did require "crash on errors" turned off. Which is not really possible in C++. So I get their decision.

So in short - you should figure out what obsolete means.
adjective: obsolete  -  no longer produced or used; out of date.
By this logic 90% of their obsolete functions truly are obsolete. Only few can be blamed on laziness or other factors.

[Goombert]

I agree with both of you.

Mac and Linux has some kind of equivalent, but that does require additional work (as there is no POSIX functions or something like that for registry)

Java preferences and Qt use the registry on Windows and ini files on Linux and Mac, LateralGM itself uses the registry.

Again, it's not about whether they work or not. It's whether a game making software should have them and how used are they

For 800$ Stupido should have all the features of a regular programming language, and maybe wipe your ass for you when you get off the toilet a couple of times. Also, while I do not agree with cd functions since you should really just load the stuff from the disk drive yourself, external resources are a must. Studio really fucked up by sandboxing the working directory.

These are not multi-platform (as far as I know you cannot change things like frequency or resolution on an Android device).

Right, and steam functions, and Windows 8 functions and some touch screen functions aren't cross-platform either, so why are Windows 8 catered functions considered cross-platform conducive but old Win32 stuff like setting the fuck window cursor isn't?
http://bugs.yoyogames.com/view.php?id=12775
They literally just removed the setting of the window cursor.

Same excuse as for cd_ and registry_. Adding them were a mistake in the first place

There should also at least be drive_ functions to obtain disk space and other storage information, again it should have all the capabilities of a full programming language for such an expensive cost. And don't forget Harri I also complained about point size and shit to you before because it wasn't in Direct3D, but I have since changed my thinking.

So they will either reimplement them via that system or will allow the programers to use it on their own.

No, their particle effects are GPU accelerated now, probably only one of the things I agree that they did right.

got rid of the mplay functions because they had bugs and didn't always work

Mplay is another one I agree with Harri on, mplay was horrible it was built around DirectPlay, which is really really old DOS shit and COM interfaces, the API is so fucking bad I wasn't even able to make sense of it to implement in ENIGMA. It was soooo fucking bad that Game Maker was like the only program that ever even utilized it as their is like 0 documentation on the internet and no tutorials or anything to even try to understand DirectPlay.

but I did like variable_local_exists() which I used to make modular instances

Fucking gross, I don't agree with either of you on that, that is essentially storing a map of all variables with an extra fucking variable, that is soooooo unbelievably horrible.

By this logic 90% of their obsolete functions truly are obsolete.

It really doesn't matter, had they programmed their engine properly in the first place it wouldn't be an issue as shit could just be abstract and it could be left up to their end users which systems to use, eg. what ENIGMA does. Case in point.

Also another dumbfuck thing they removed, message_box functions that let you texture the message box dialogs, because without that they look like shit, and like the programmer did a lazy job and just used the plain Win32 api.

Game Maker can make good Windows games too you guys, people need to quit being so mesmerized by this 2D and mobile crap, I don't even fuck have a phone, I play SimCity and RTS games and shit.

[TheExDeus]

Java preferences and Qt use the registry on Windows and ini files on Linux and Mac, LateralGM itself uses the registry.

Well I didn't say nothing used registry. But the less a program uses it the better. And games (which GM is meant for) shouldn't ever use registry (only for installations and such of course). So the fact that LGM uses registry for some reason isn't the best thing in the world. We should probably switch to ini's.

For 800$ Stupido should have all the features of a regular programming language, and maybe wipe your ass for you when you get off the toilet a couple of times. Also, while I do not agree with cd functions since you should really just load the stuff from the disk drive yourself, external resources are a must. Studio really fucked up by sandboxing the working directory.

They could make a 5k$ product that can only do show_message() and you shouldn't care. They are making a gamemaking software. They try to make stuff that can be used in games and remove stuff that cannot be used/are rarely used/or just shouldn't be used. I don't know what external resources are you mentioning, but if you mean export_include_file, then it was a nice feature, but again, self-extracing exe's are not the best way to make something. I do still think GM allows you to load external resources though.

steam functions, and Windows 8 functions and some touch screen functions aren't cross-platform

And you know what they all have in common? THEY ARE USED IN GAMES. The quote you made was me talking about hardware functions. And I already said that they will probably be implemented back for desktops, as changing resolution is something desktop games usually allow to do. On the other hand I can understand why they are going to be removed from non-desktop (including HTML5) implementations.

They literally just removed the setting of the window cursor.

That ticket is about specific cursors. Not all of them. I am not sure why they removed exactly those ones though. Of course they also were not used in games, but I can't think of another specific reason.

should have all the capabilities of a full programming language for such an expensive cost

But I don't think making such a software is their goal. They don't consider GM:S a full programming language. They consider it a tool for making a specific type of software - games. For example, I just googled "unity get disk space" and it seems Unity doesn't have this (at least easily useable) either. It can only do that on Windows and only when NET 4.0 is installed. So clearly bigger players like Unity also don't have capabilities of a "full programming language". I am not saying ENIGMA should go this route though, as I personally use ENIGMA just for the contrary - programs and simulations. I actually don't really make games in it. But it makes sense they are not having functions like that.

No, their particle effects are GPU accelerated now, probably only one of the things I agree that they did right.

Is that the physics part accelerated? If so, then it also explains why the removed deflectors and attractors, as it is a lot harder to make CUDA/OpenCL programs that use optional n number of things (as least working at great speed the same time). So it's probably because of this.

mplay was horrible

I remember making 2 games using mplay. Both of them could only be played trough LAN. That thing basically didn't even support internet.

Fucking gross, I don't agree with either of you on that, that is essentially storing a map of all variables with an extra fucking variable, that is soooooo unbelievably horrible.

I am not saying that they were pretty. But I do remember using that method in million different projects. Now in ENIGMA I do things differently, but it means that porting is a little harder. But this is not something I will lose sleep over. Good riddance.

It really doesn't matter, had they programmed their engine properly in the first place it wouldn't be an issue as shit could just be abstract and it could be left up to their end users which systems to use, eg. what ENIGMA does. Case in point.

But most of the things they removed, they couldn't abstract them. We cannot abstract them either. Things like CD_ functions are very specific to the device. Same with window cursors and so on. So most of the stuff they removed were either not used, not portable or not worth the trouble (basically the same as the first point - not used). And we don't do anything better or more than they do. Registry functions only work on windows and ini functions require an extension to be used on non-windows platform. So case in point - their decision is mostly a correct one. But that doesn't mean we should do the same, as we have different uses and goals (more general purpose than GM).

message_box functions that let you texture the message box dialogs

And again, nobody should ever use that function. That is only used for debugging. And the reason for removal of course is that this also cannot be easily ported. No need to create separate code for every platform for a feature no one should ever use.

Game Maker can make good Windows games too you guys

I know it can. But good windows game can also be 2D. I personally enjoy 2D games when done right and I think that is what GM excels at.

[time-killer-games]

I see where you're coming from Harri with most of what you said, but I'm fully aware the window_* functions don't work on android iOS, etc the point I was getting at is even though it doesn't work on mobile devices, it DOES work on the desktop platforms which includes Windows Xp/Vista/7/8, Mac OS X Ubuntu, HTML5 and YYC. Though not all platforms support it, more than half of them do. Well, when it comes to window_set_cursor() function and the cr_* constants thanks to Robert for the heads up is no longer a compelling argument on my part, but hey, most of the other window_* functions are still there at least and they only work on desktop platforms.

Robert also made a good point about the exclusive Windows 8 - only functions, please note, are these really cross - platform? Nope. Since they were added recently, clearly whether a function is completely cross-platform isn't really even applying to their reasoning in removing functions.

The splash stuff - This is where I strongly disagree. WebView controls are impossible to do in GML without using an extension, so without such a web function, platforms that don't currently support extensions won't be able to do something so simple as to open an embedded webpage, it will have to be opened in the default browser, which is stupid because I could writing a portion of my game in raw HTML, embed it in my game, everything would be how it's supposed to be, but when opened in the browser, the local (or online depending on the case scenerio) url can then be exposed and the HTML source could be viewed. I know the HTML could be obfuscated  but that's not my point here, my point is, any game developer who uses GMS should have the capability to choose whether a url will opened in a browser or a web view control for the end user/gamer. I don't care what reason they have behind it they should at least have that option and choose it how they see best fits. Windows 8 and below, Mac, Android, Tizen, and even HTML5 (using the <iframe> tag) all could have a WebView control applied directly from each platform's specific APIs. To implement this it would require YYG to write like 50 lines which would make their product better to a small extent with no regrets. Compared to all the lines of code YYG wrote into game maker, 50 of 'em is very quick, easy, it would be no skin off their backs if they actually did this and it would benefit them and their customers.

Videos, there are a ton of programs I use for rendering high quality videos, SweetHome3D (MOV), Bryce (AVI), etc. they can't output raw animation frames. So if you honestly think videos shouldn't be supported I really don't understand that. Compressed videos (vs) Lossless Quality PNG sprites - which has a bigger file size? Also if I converted the video visuals into a PNG sprite and the audio into an MP3 sound, playing the animation in sync with the audio would be a nightmare and would vary every time you play it, IE a character moves his mouth talking and the actual audio plays lagging behind or vise versa, etc The lack of video support is the dummest of their mistakes. And there's zero excuse why they can't implement it with not just the fact they already have ffmpeg integrated in the engine, but video playback is literally fully capable to run on all devices they currently target. This includes almost all popular formats such as MP4, M4V, MOV, AVI, WMV, FLV, 3GP, and much more.

[Goombert]

Well I didn't say nothing used registry. But the less a program uses it the better.

Well I am sorry Harri, but you are simply wrong this was the entire purpose of the registry.
http://en.wikipedia.org/wiki/Windows_Registry
" With the introduction of Windows 95 and Windows NT, its use was extended to tidy up the profusion of per-program INI files that had previously been used to store configuration settings for Windows programs."

They could make a 5k$ product that can only do show_message() and you shouldn't care.

Unity3D's free version can do all that they do and more and do it better, because they have the power of a full programming language.

The quote you made was me talking about hardware functions.

Again, the Windows registry is not a hardware feature, and neither are disk and storage functions for audio and media playback, what if somebody wanted to create a really really cool media player that was half media player and half video game or something? With Unity3D you have that power, with BlitzBasic you have that power and cross-platform. Another thing I just added that they had removed was video playback support using DirectShow, later I intend to add the functions so video's can be rendered to Direct3D surfaces using the COM interface.

They consider it a tool for making a specific type of software - games.

Again, that is what Unity3D and BlitzBasic are meant for, yet people use them to create all kinds of other applications. Same with Qt being mainly a cross-platform GUI framework, and people use it to make games.

Is that the physics part accelerated?

No, Box2D is not hardware accelerated which makes it nice for mobile and shit. Which is also why I've written a Bullet extension which can be used for hardware accelerated 2D and 3D physics. I may do one more collision system which doesn't handle physics but does 2D and 3D collision detection as an alternative to BBox and Precise since cheeseboy and others have been requesting it.

That thing basically didn't even support internet.

As I said before I have no intention of even bothering to make that DirectPlay networking system work, the code is a clusterfuck and it was a very very poor API by Microsoft.
http://en.wikipedia.org/wiki/DirectPlay

and ini functions require an extension to be used on non-windows platform.

http://en.wikipedia.org/wiki/INI_file
"Linux and Unix systems also use a similar file format for system configuration. In addition, platform-agnostic software may use this file format for configuration. It is human-readable and simple to parse, so it is a usable format for configuration files that do not require much greater complexity."
You are almost as bad as Josh, can we please stop all the hate on INI files? YAML is 1000x more shittier and does not leave room for mistakes either, eg. indentation.

And again, nobody should ever use that function. That is only used for debugging.

Texturing a message dialog to make it look pretty, is for debugging?

And the reason for removal of course is that this also cannot be easily ported.

*ahem* They can be ported, you can texture XLIB dialog and Mac dialogs, if Windows can do it, what would make you think Linux wouldn't be capable of it?

Things like CD_ functions are very specific to the device.

Yes, but here is the thing, they already had the code for all of it written, so throw all that code into a prepackaged extension, then nobody would fucking complain. And just tell people the extensions are unlikely to be continuously developed unless needed.

I personally enjoy 2D games when done right and I think that is what GM excels at.

Right, but that does not mean you need to break its legs off like Nvidia does to their Linux drivers to make them as shitty as they are on Windows.
http://www.tomshardware.com/news/nvidia-linux-basemosaic-ubuntu-parity,24519.html

Also as for the Windows cursor functions not being used, I see them being used quite a bit, and TKG specifically asked for that function when it broke, those were pretty well used.

most of the other window_* functions are still there at least and they only work on desktop platforms.

Nononon what are you talking about? That is not what I said at all, those are very usable functions.

Also, TKG, everything else you said I 100% agree with.