Jump to content


Member Since 21 Jan 2004
Offline Last Active Private

Topics I've Started

Dual Monitor Setup

19 August 2013 - 09:32 AM

Hi everyone,


Does anyone have any experience with setting up GM for a dual monitor? So far, stretching GM over two monitors seems possible, but it's not really ideal. I'd be very pleased though to be able to have multiple windows open, say an object on one screen and the code or a room on another but I haven't been able to get that to work.


I figure with the new IDE in the works perhaps this could be included. I think it very much fits with GM:S's identity now as a serious software kit and I know Mike is a big quadruple monitor fan hehe. Hope to hear everyone's thoughts on this. 



GM Studio in 2013

02 February 2013 - 05:59 PM

For most people who follow GMS closely, there's not a lot of new information. Still, should be a fun read for anyone:


Main points
- LLVM coming soon (and shaders, not mentioned)
- Linux coming soon
- GMS is at a position where moving into new platforms is relatively quick
- Sales are pretty decent, and quite rapidly growing. They have a position on Steam.
- Big ambitions to rival Unity, but stay loyal to 2d development

Nothing really new, but the article definitely reaffirms the core belief that YYG was more than great for Gamemaker, and that the future is limited by our potential as game developers, rather than the limits of GM as a tool. Our future is in our hands, and that's a very pleasing thought. I'm excited for the future!

Keep it up, and feel free to reintroduce the blog to give us insights like this more often. A journalist middleman should only be for external communication, not comms with your current userbase :whistle:

GM:S vs GM8.1 performance revisited

05 January 2013 - 04:18 AM

One of the reasons I decided to port a project of a few thousand lines of code and hundreds of assets from GM8.1 to GM:S was a performance gain. I did a bit of research before making the purchase, and even later when I actually considered the port, and I came across a few commonly mentioned advantages of GM:S.

Numbers like 2 to 3 times as fast were mentioned numerous times, by different people. These people reported such numbers both from isolated tests of limited basic functions, as well as performance of actual game projects that were identical between GM8 and Studio. Reasons mentioned were an improved and rewritten GM and a C++ runner. Smarty already explained that the C++ runner itself doesn't necessarily do anything inherently to performance, even well before Studio was ever conceived as an idea. Still, the tests got me excited and I went through porting my project.

I rewrote a number of small bits to my game that use now obselete functions, as well as a number of larger elements of the game; in particular, I lost the fmod DLL (instantly crashes, not reliable, no mac port possible) and many great visual effects (distortion, bloom, blurring, etc), as well as a great performance-booster by allowing to skip drawing frames (fps control through manual screen_redraw()).

It worked well, after quite a few long hours going through the manual, rewriting many parts and finding several bugs and annoyances in Studio that I've reported (one has been fixed), I was done. I now had the identical game, but lacking sound, advanced visual effects and frame skipping. Once I finally got a build that ran without any errors, I immediately turned off the fps-cap to see the speed I'd gained and to my surprise, my game ran at ~200 fps in Studio, versus the 230 I got on GM8.1, despite having essentially turned off a few potentially intensive features. Moreover, using the manual screen redraw in GM8.1, now obselete, I could go from 60 to 30 frames per second, and boost my 'fps' (or cycles) from 230 to ~400 in GM 8.1, a possibility I lost in Studio until I'd go through every single draw event and edit them.

Very disappointed. I then ran a few tests initializing a few thousand arrays and datastructures, as well as drawing thousands of sprites. In each case, Gm 8.1 beat Studio by considerable margins of about 20-30%, quite to the contrary of anything I'd read so far.

Still, Studio has my interest as it's development is continuous, its a supported software, and I'm glad for the ability to enter the Mac marketplace. But how important will Mac be, really, for a commercial success. And is it worth the loss of customers on lower-end Windows machines, who couldn't smoothly run the game in Studio, but might just be able to in my GM 8.1 build, particularly when frame-skipping? I'm not so sure anymore.

I'd be very happy to receive some thoughts on this by other users of Studio and GM8.1. I'm feeling more and more that GM Studio for non-mobile platforms has very little advantages over GM 8.1, but that the reverse is less true, GM 8.1 has a few interesting advantages. I'm disappointed by the great shift of focus to mobile, as I have yet to see more than a few mobile games that really capture the essence of what make games interesting for me, storytelling, artistic opportunities, depth, thought provocation, immersion, a rich sound and visual experience. Mobile games can be monetized to great effect these days, the time to market and investments are low and the market for casual gamers is huge. I understand the decision. Too bad. It's a shame Studio in 2013 has improved very little on the solid foundation that GM already had back in 2008-2009 for the Windows platform, and indeed sacrifised some nice windows-only functionality to create an easy to use tool with universal cross-platform functions. One can always go back to GM8.1, but it's not supported, not updated, and it's years old, I was excited for an upgrade in Studio that wasn't all what I had hoped it to be.

EDIT -- Got work from staff that a pretty big update is planned with several speed and feature improvements. Will have to wait patiently! Pretty excited though, should be a big step forward for games on PC from what we had since 2008-2009 and before. Still curious to hear other people's thoughts.

Hope to hear some thoughts on performance of Studio. Any other comments and comparisons are also most welcome, always eager to learn. Best wishes,

Measuring memory usage

18 October 2012 - 02:00 AM

Hey all, thanks for your time.

I'm currently adding a number of post-processing effects to my game which are entirely optional and utilize screen-size surfaces. In order to develop for both high- and low-end computers, I want to turn off the effects when they affect performance too much. I can quite easily keep track of the strain on the CPU due to these effects, and turn them off if FPS is low.

However, memory is a different issue. Therefore, I want to get a sense of the memory the surface uses, and find ways to optimize my game. There are essentially two key values to determine a texture's memory usage: color depth and texture size.

For example: Color depth is rumoured to have an affect on memory. From the manual: "32-bit color gives nicer looking images but will take more memory and processing time. If you want your game to run will on most older machines set the color depth to 16-bit. Otherwise use 32-bit or don't change it." And this makes sense. 8 bits (1 byte) can represent 256 values. Each pixel supposedly has an R, G, B and alpha channel. Therefore, four 256 value-channel makes 32 bit, and four 128 value-channels makes 16 bits. The difference is of course a factor of 2 in terms of the memory used by each pixel of a texture.

Secondly, texture size is of course the amount of pixels which need either the 16 or 32 bits to store the color. A 16 x 16 texture would have 256 pixels, which on a 32-bit system (default) needs 1024 bytes, or 1kb of memory.

So far so good! Lastly, the way GM is rumoured to handle textures is as follows: Any texture loaded into memory needs to be saved on a texture that's 2^n size. That means a 16x16 texture is stored as is. But a 16x20 texture is stored as 16x32, as 20 isn't a 2^n, while 32 is. (2^5=32).

As such, optimization of my game is about:
1 reducing texture size, primarily focusing on not creating waste. (e.g., 10 textures of 1100x1100 are stored as 2048x2048, wasting ~80 megabytes of memory.)
2 allowing players to choose 16-bits, if they prefer smooth-gameplay over more colors. This cuts memory in half.

This has been the motto for a while. But when I just now ran some tests, the ideas don't hold up! They make sense, it's been somewhat common knowledge to all GM users who know about memory and textures, but I get very varying results.

Firstly, I ran the following script to measure the amount of memory that goes into my ~512mb card:
t = 1; w = 512; h = 512;
surf = surface_create(w,h)
while(surface_exists(surf)){surf = surface_create(w,h)t+=1}
Where t is prompted, which holds the amount of time a given surface can be loaded into memory.

Some strange results:
1 Virtually no difference is observed between 16 and 32 bit surfaces being loaded into memory. I get 887 surfaces on 16-bits, and 883 surfaces on 32-bits. Less than half a percent difference. Additionally, these results come from loading a 512x512 surface (512^2/(4*1024^2 = 1mb). As such, it'd appear my 512mb card can hold 883mb. (or less for the 16-bits.)
2 A 32-bit 512x256 surface works as expected. 1766 surfaces, twice as many as the 512x512. (But now on 16-bits, it's 1773, less)
3 However, according to commonly held ideas, a 512x260 surface would be stored as a 512x512. Rather than 883 surfaces however, it stores 1172. Quite a bit more than the 512x512 surface, but also a lot less than the 512x256 surface. Either way, it's neither of both, and the amount of loadable surfaces is not in proportion with the amount of pixels.

I'm running these tests with a bunch of things open. I can repeatedly store about 880mb of differently sized surfaces. It is as if I'm forgetting to divide my 2 somewhere. 440mb free memory on my 512mb videocard sounds quite plausible.

So my questions. Who can enlighten me about the way GM stores textures? Apparently the 2^n factor is not strictly upheld. And color-depth seems to have no effect at all on memory usage.

Some thoughts: perhaps surfaces have no option to be loaded as 16-bit like e.g. sprites and backgrounds.

Best wishes and thanks in advance.