ENIGMA Development Environment

When that happens then of course it will not be practical to support it. Because it really isn't practical to support GL1 even now. For desktop PC's you can buy a GL3 card for 100$ and a used one for 50$ or less. There really is no reason to not get one. On laptops sadly changing GPU is usually a lot harder or even impossible. But then again laptop (especially a crappy one) is in no way meant for gaming. But if it is at most 3-4 years old then it should support GL3 just fine even with crappy intel cards. You can probably buy a 3 year old laptop for 100$ as well. So if a person like poly wants to maintain GL1 for himself then it's ok. But ENIGMA as a project shouldn't really focus on that kind of compatibility.

I don't think it's vice versa. I haven't seen a feature from GL1 which doesn't work on newer cards. That's the thing with software design and standards. It almost always have to be backwards compatible (or as much as possible). So while most of GL1 functions are obsolete, they are and will be supported. Maybe it's just in the driver level though (as it emulates fixed pipeline stuff with newer functions like shaders).

Josh, but isn't that just at the compile time? I think Fervi wants that we compile with both GL1 and GL3 and then switch at runtime. I don't believe we need to do that. Any PC (even with Intel cards as sidegame has made us aware) support GL3 in sufficient capacity. There really should be a point where compatibility is just too expensive in terms of time and effort required. I think our GL3 don't work on maybe 1% of all cards (which fervi and poly I guess are owning).

LateralGM is very old and was created as just that - total open source and free replica of GM IDE. It wasn't meant to be any different as ENIGMA wasn't even a project back then. So as LGM could only edit and save GM files then there was no reason to add something GM didn't support.
Right now some additions (like new resources) are planned and editor changed. The whole idea will probably stay the same though, as I personally think Mark Overmars did a very good job in coming up with the IDE. If it was any different then it would probably be more complicated.

And I think it's the other way around - When will ENIGMA be compatible with GM:S, as I don't think YYG will create stuff to be compatible with us. I think most of GM:S stuff is already in ENIGMA. There could be some functions not ported (and some may never be), but ENIGMA also has functions which GM:S lacks. So we are slowly diverging. You should probably make projects in one or the other. Hoping that gmk from ENIGMA will work in GM:S or vice versa seems very optimistic. The idea is that if the project is complex enough or uses special features that make it incompatible with one or the other, then it would be at least easy to port. I don't think it would take longer than a day or two to port almost any GM game to ENIGMA (if it didn't work out of the box already).

Well that's weird. But I guess this knowledge will come in handy. Could also explain why we have problems with MSAA.

While being compatible with GML 100% ??!?!?!?!? o_O

Well that part will not be GML compatible (as it doesn't even have the C++11 foreach().

Some thoughts:
1) Compile Scripts confused me a little. As I though "Compiled Scripts" and then tried to figure out why you call it like that because we already compile all scripts.
2) While it seems powerful to lets users do this, I still think we should add as much functionality ourselves as we can. Especially sprite_get_name() the like. And I don't think it would bloat the exe, as shouldn't compiler cut unused functions? I am pretty sure it doesn't do it now for some reason (probably the makefile is wrong). You could also make JDI do some size optimizations as you know what functions are used what aren't.
3) So you are basically defining a new language? I guess it will have similar syntax to EDL, but have some additional built in stuff to get information about resources? As you cannot do spr_my_sprite.name in EDL, though actually it is a very good idea. We should make all resource objects actual classes to we can get obj_enemy.bounding_box_width and such. I think we already can do obj_enemy.depth though.
4) What could be other uses for it instead of replicating these _name functions? I suspect this isn't meant to replace extensions or add the capability to code the scripts in pure C++ like Definitions.

I don't actually now if it will fix anything. It really shouldn't as it works on many machines and is just weird it doesn't work on yours. Have you also tried installing newer video drivers? And are you sure you don't have an ATI card in that PC (look at the stickers on it if it says ATI anywhere), because for some reason the manufacturer is ATI Technologies Inc. Maybe they just make the built-in card.

Try copying this https://dl.dropboxusercontent.com/u/21117924/Surfaces/GL3surface.cpp inside enigma-dev\ENIGMAsystem\SHELL\Graphics_Systems\OpenGL3 and overwriting the file there. I cleaned it up as far as consistency goes (now everything is ARB) and made surface_free() actually free texture and FBO (previously I guess it was a memory leak on the GPU... dunno how that works).

Also you should try a simpler example. It's possible that blend modes just fk's the picture up and just writes 0 alpha everywhere or something. So try something like:
surf = surface_create(128,128);
surface_set_target(surf);
draw_text(10,10,"This is text "+string(random(100)));
surface_reset_target();

This will just draw text. Nothing else.
Also try this: https://dl.dropboxusercontent.com/u/21117924/surface_test.exe
It's exactly that text drawing but I compiled it so if it still doesn't show up then the problem is even more bizzare. Also try pressing Enter while the program is running. That will delete the surface and create a new one with new text. A random number is added to see if it changed.

edit: Robert B Colton, check the first page. He posted a screenshot. _supported() returned true.

"Intel(R) HD Graphics Family" - Well for all intents and purposes you can say you don't have a graphics card at all. Those things usually will not really launch anything and the technology support is usually awful. You might have hope as it is new and maybe Intel starts actually creating cards people can use now. I for example, was certain that Intel cards created at least in the past 2 years have support for FBO's (which is a technology from 2006 (last version, originally it is even older)). Try rendering normal sprites and see if that works. Because if _is_supported() returned true, then it must be supported, as it is the only valid way to actually check for support (as far as I know).

Robert, he tried my compiled example. As it doesn't work then it's lot bigger problem.