The pull request has now been merged and reviewed by Josh, not only does this improve ENIGMA by adding the game end event and fix other bugs, it fixes a regression in the Room End event. The new Portable ZIP is available for download.
http://enigma-dev.org/docs/Wiki/Install:Windows

Actually we support BMP and PNG for both saving and loading. At any rate, you can always modify the engine, very easily too, unlike GM, because you have the entire source code and can just edit the files instantly without any hacking.

No I've already talked with Dailly, they are going to be changing a lot, drag and drop will be overhauled, I'm certain it will be pretty unfamiliar from the traditional GM IDE.

Well, Darkstar2, the good old days is a logical fallacy, that said, I still agree with you. In one of my classes for school we just learned about the cohort effect, which is why it is also a very bad idea to make correlations about the development of people of different ages when studied concurrently.

Anyway, I still play SimCity 2000 from time to time in my DOSBox. You can not convince me this game was not phenomenal for its time, and is not still the same today.

https://www.youtube.com/watch?v=KgW3hDuQqGU

Do you have high hopes for GameMaker's new IDE ?  It will be C# based right ? Do you think it will offer much improvements ?  Some say it will suck just as much dick, some say it will be better/faster.  Wasn't this alleged new IDE due in christmas 2013 or Q1-2014 ?

It was supposed to be released in that time frame, and it's going to be worse. Look at their debugger, they went and copy and pasted icons off some free icon website, or well it looks like that anyway. I have no faith in them, I do however have faith that Mark Overmars would make a good IDE.

All they did was crap up everything he made.

I use AIDA64, and it also says 16384x16384.
(but there is 1D,2D,3D, etc.) numbers can vary 65535, 2048, 16384, etc.  You will find all the info on just about everything hardware using that tool.

This is actually where I am kind of stumped with texture atlasing, I don't know if Studio places any limit on the number of textures per page or not.

I guess the only workaround for using such large games in ENIGMA is an advanced developer by using external resources and keeping the LGM IDE compact, only using the resources as needed.  This is what nearly all commercial games do.  Currently GMS deprecated certain functions to allow this, luckily in ENIGMA they still exist, all that remains is for me to write my single file encrypted resources I can extract files from direct to memory or to disk. 

You should probably do that anyway, having external resources makes your game modifiable by the end user, and that is a very very positive thing. SimCity 4 came out in 2001, yet it is still very VERY popular today because of the sheer amount of modifications for it, it even has an entire development community built around it.
http://www.simtropolis.com/

They could have prevented the lag with optimization and allowed dynamic resource allocation as needed instead of preloading everything to the IDE.  Why the HELL would one need to preload anything after all you are testing your game back and forth.  Should be optional, preload and after a certain limit go dynamic handling.  But of course that requires more coding ! so I guess that part is left up to the developer.
No biggie, I think I am capable of doing so.

That's what I just said above, currently I can't make LGM do that, because it does not have a guaranteed format, and the ENIGMA plugin needs to write the resources out to the EGM format anyway. Josh does not like the idea of making the CLI for ENIGMA natively handle GMX, and I kind of do not either. But basically, we can, in the future, optimize LGM specifically for the format that is loaded, so if you load GMK's they will always be loaded all at once, but GMX will be optimized and not lag as much, and so will EGM. Potentially, but none of us have the time to overhaul the system this much.

I agree with everything Harri said above, video games do cater to the lowest denominator, and it's bullshit, this is part of why PC gaming is dying. Dumbing down SimCity with SimCity: Societies and SimCity 2013 and sandboxing shit, is exactly how they pissed off their fan base and ruined the franchise.

You don't see many new strategy games anymore these days either. It's all bullshit, the PC gaming platform is in decline. iOS/iPhone/Mobile/Android have not only changed the landscape of the video game industry, they are fucking destroying it with their crappy bird games.

Yes if you overflow VRAM new resources will be pooled in system RAM. At any rate, that isn't what I was talking about, regardless of how much RAM you have, most graphics cards limit the size of textures, some really old shitty cards may be 1024x1024, average is 2048x2048, and I think mine is 5096x5096, and if you have a card like Harri or Josh or Cheeseboy it would be even higher.
https://www.google.com/#q=texture+size+limit

If you want to support tablets, you should go no higher than 2048^2, which is what Tegra 3 supports (iPad3/Tegra 4 supports 4096^2). If iPad, Nexus, or Galaxy Tab are possible candidates, don't go over 2048^2.

http://www.gamedev.net/topic/646362-expected-maximum-texture-size/

But also yes, the IDE lags, but so does Studio's IDE with big projects. I've compared opening big games such as TKG's in Studio and it runs just about as badly as LGM, the editors just don't lag nearly as much, it's written in Delphi.NET currently. But they use an optimization that we can not, since LGM works with all formats. They convert all projects to GMX when imported, this means, they only load the tree nodes and the first subimage of sprites to iconify the tree nodes when you open the game. Then as you click each resource they will load it into memory, and when you close the editor free that up. LGM does not have the currently capability of doing that, if we did our IDE would be inextricably faster than theirs.

This broke whenever I updated the inheritance model, I forgot about the fact I inlined subchecks, this is why draw is the only event broken because it is performed manually. I will ask Josh what to do.

I have sent a pull request here fixing it.
https://github.com/enigma-dev/enigma-dev/pull/729

No large sprites are fine currently, they will lag the IDE, but they are usable as long as they are smaller than or equal to what your video card supports. It's just something wrong with the fucking plugin font population that is causing it to shit out. Large games are less likely to run perfectly out of the box however because as the size of the game increases, the number of chances of it using something ENIGMA has not finished or is buggy increases as well.

This is a separate issue unrelated to the out of memory ones. This issue is the font texture page not being big enough to handle the font size or some shit. It however should not be failing in the plugin, it should be failing in ENIGMA's graphics system. At any rate, we need texture atlasing to allow us bigger texture combinations.

Let's see I reproduced it with 32-127 character range, so 127-32=95, so sqrt(95)= roughly 9.7 * 90px per character = roughly 877.2 pixel wide font texture.

Again, the plugin should still not be failing, I'll investigate when I have time.

Well it's good to know we don't have this issue in ENIGMA. Nice find.  Thanks for the fix.

You mean, we don't have them anymore. I would also appreciate if you could download the Portable ZIP and double check there is no font blurriness for you in both OpenGL 1 and Direct3D 9.
http://enigma-dev.org/docs/Wiki/Install:Windows

And yes this does affect sprites/backgrounds and everything else drawn orthographically, it means there should not be any half-pixel alignment issues, you should never get blurriness from drawing a sprite or text or anything at fractional pixels, for instance x=1.5670 and or y = 2.3568

BTW, as I recall GM always used DX9, right ?  Does GMS still use DX9 ?

GM does not use just DirectX anymore, it uses Googles' Almost Native Graphics Layer Engine, also known as ANGLE. Which is also used by the Qt Framework, Firefox, and Chrome.
https://code.google.com/p/angleproject/

That's how they allow HLSL shaders in games on Linux, theoretically of course, I have not proven it. We decided to just stick with basic Direct3D and OpenGL since it is both lighter weight and well, nobody really gives a fuck about Direct3D because it is not cross-platform.

No you're still not listening, it happens with assigned fonts as well, that picture from Studio is with an assigned font. Sprites will do the same in Studio as well. After my changes yesterday you should not have this problem in ENIGMA

Make a blank font and leave the default settings then add this draw code to a new object, place it in a room, and run it.

Code (GML) Select Expand


draw_set_font(font0);
draw_text(0, 0, "Hello, world!");
draw_text(1.5,20.5, "Hello, world!");


In Studio you get the image above, in ENIGMA, everything is good.


See? Because we half pixel aligned the projections like vector graphics should be, you will not ever have this issue with ENIGMA as of the changes yesterday.

What? No I think you are not understanding, the top "Hello, world!" was drawn at a half-pixel and is visibly blurry, the bottom one is not.

On a funny side note, the latest version of Studio 1.3.1344 just released also has buggy pixel alignment.