ok lol. That wound up being a long discussion just to result in toggling a boolean

My system defaults to 64-bit, yes.  I'm on Windows 7 after all.  Why does it matter?  Nothing else I've ever run has specified 32-bit OR 64-bit.

EDIT: Tried the older installer, and it actually compiled stuff, but I was still getting errors in compile, and the compileEGMf one too.

Errors are probably normal. But what errors were they?

The fact that it compiles is making me question Robert's stuff now though.

Ah so can you upload the game, then we can see if it happens for anybody else.

malkierian were you originally using 64 bit Java though? You might need to fully un-install it if you were.

I hope Robert's pre-compiled objects aren't to blame...

Maybe try a previous install Zip:
http://www.mediafire.com/download/od18j361y6mpppo/ENIGMA+Zip+Installer.exe

In regards to the original question, I think it could make sense to turn the particles extension on by default. Should we do that?

Yes turn it on as default anyway. I'm not actually too fussed where it is really, you're right that it works now maybe don't want to screw with it and there's more pressing things to do than move that around.

I think I remember Josh saying though that extensions don't affect the resulting game binary. You're probably right about the loading time though, but I'm thinking it's not gonna be a huge speed gain :p

Yes they did, somebody called Wishdream on the irc. I didn't know what it was causing it so I told him to wait for Josh but he never came back.

It was probably the same problem, he said cc1plus was spammed like 20 times in the task manager and I initially figured it was MinGW screwing it. But in the IRC he said he also tried it on 3 different systems and they all had the same issue, the only thing apparently common was that they were all Win 7. I'm not sure on the validity of his testing though, but the specs of the systems he gave me were:

AMD Athlon(tm) 64 X2 Dual Core 4800+ 2.50GHz CPU, 1GB RAM 64-bit Win 7 OS, AMD Radeon HD 6670 1GB GFX Card, Realtek HD Audio
Win 7 32-bit 2GB RAM laptop
Win 7 64-bit 2GB RAM Laptop

Although thinking about it now, I'm considering whether it was the game size doing it and if he was then just testing the same game. SuperRiderTH do other games or a blank room work correctly for you?

Hang on didn't somebody else post that memory problem with cc1plus. I'm trying to remember what happened there.

But I'm not sure I'm actually seeing any benefit to having the particles in an extension. I thought extensions were just so people could disable systems that use instance local variables and thus save memory, or for disabling a system that might get in the way. I'm not sure how particles fit into that.

The fact that they are GL dependent means they should be contained in the graphics folder though. They fit with the other graphics files, plenty of them are very large as well. In the case where other particle systems are to be written then they should be in the API selection not extensions. Doing this you can then add a <none> option.

Actually I don't think they should be an extension at all. They seem like a typical set of OpenGL functions.

Should the particles extension not be on by default?

Well a while ago Josh reluctantly agreed to allow me to add this in to ENIGMA after a lot of persuading and I've only just re-remembered and got round to it.

What I've done is add a map as a 'fallback' for when you reference an instance variable that's not declared in the object struct. This means you can for example now work with this code:

Code Select Expand

//(in say obj_0):

obj_1.foo = 5;
obj_1.buffer = 99;
show_message(string(obj_1.foo));

In ENIGMA if you don't use the variable foo anywhere in the object obj_1 then the variable will not have been declared. So in ENIGMA when you try to reference the foo variable for an obj_1 instance, there is no object member variable to access. Before ENIGMA was just assigning to a dummy variable, so that code would have shown 99 (as that was the last variable referenced). But with my change it will now add a map of the value 5 to "foo" local to the obj_1 instance, so you can reference to it properly as you would with any normal variable. Like I said this is like a fallback backup for when people don't declare variables in an object like they should do and it's obviously a lot less efficient so you should still always try to declare your variables properly.

You will find that this will improve the compatibility with Game Maker games quite a lot, I was constantly running into this incompatibility with games I tested. But I've not exactly tested much, so I'm posting here in case anybody can see any problems this winds up causing.

Also that fullscreen bug I mentioned before, looks like this:

http://i.imgur.com/h1CIBcV.png

Yeah my bad. Somehow forgot that glew is for windows. Anyway, it's possible to re-implement for windows then.

And I checked, I have everything, including "enable desktop composition" turned on.

OK. But possibly it's being disabled by your driver when you run the application?