ENIGMA Development Environment

Yes I am glad you found that I thought the problem was much much bigger. Important to note however that display reset is actually occurring 2x and I have fixed it in my pull request also. It will also error and crash if you have surfaces,

True, I have tried with project mario and it mentioned lost devices / cannot reset !  So that means that with the next merge display resetting and lost devices will be a thing of the past.

BTW, are you going to include view fixing with those fixes (someone had posted views not working correctly in DX9, not displaying rather.....).

In case some of you missed it, whilst I was working on the last fix for font and scrolling glitches / testing, I announced that I had an idea for fixing the DX9 engine that cleared the display if you switched from window to full screen or full screen to window, or resize window, lose focus, etc.... I worked yesterday on a demo along with a custom made script that I coded to demonstrate the fix that solved the problem of the display not being reset and lost under the conditions mentioned above.

I was going to share this script and demo here but decided to check with Robert first just to be on the safe side and get his constructive feedback on what I had done, even though on my end it was working great. I wanted to know if there were maybe an alternative.

So basically to make a long story short, he acknowledged it was a good fix (in practice) and that I had found the problem, and basically came inside his trousers

So anyhow, to my surprise, he got back to me, saying that a light bulb went off inside his head, and managed to replace several lines of code I had written to a 5 byte fix LOL all this long DX9 was messed up over what was a 5 byte fix.......  So anyhow, Robert (who initially did not believe me and thought I was lying !!!) decided to include this fix with some other general fixes that are not yet merged,
basically the depth buffer (ZENABLE) was set to true, and that is what was causing the display to vanish in thin air never to come back.  I had made a script to automatically  detect the conditions that causes display to clear and restore it.

But thanks to Robert now, my script won't be needed, so it's pointless to upload it.  But since he wants to include this fix with other general fixes, I thought I'd share the display reset part of the fix since it is final and functional.

Until the general fixes get merged, here is the raw file (DX9screen.cpp) just copy that over your existing one, you will now be able to use DX9 and this will fix display reset issues - fully tested and works. (for lost devices / reset issues on surfaces, etc) you will have to wait for future fixes he is working on because I have never used surfaces and mangled with that aspect yet.


** UPDATE: These fixes are now merged, make sure you have the recent version.

I've almost finished the undo/redo. By default the UndoManager of Java has a limit of 100 undo. It seems fine for me. What about adding a new setting in the 'Game Settings' which allows the user to change this limit ?

Very good idea indeed.  or an option to disable it completely.  What I'm afraid of is that this could make LGM more unstable and crash faster (memory related) etc.  Though it would be a good addon to LGM along with CLI.

You wouldn't use the CLI to create the files, it's expected that the project will be created in an IDE. The command line will compile it.

So the IDE would simply call the CLI which will work directly on the file instead of the IDE passing its memory to the compiler, got it, that's how it should be done anyway,

But yes it's possible to edit your resources outside the IDE using text editors and image editors, you can very easily open a sprite or background from a GMX and modify the resources, and you can open the object files and change the code and other properties.

Agreed, but you still need an IDE to create that GMX, GMK, EGM or whatever .... That is my point, how would you otherwise build entirely from command line.  I think I might actually do straight building from CLI for my upcoming dynamic / external resource handling library, I won't need sprites or placing stuff in room.  With this new library I want to build, that will allow working on massive projects multi gigabytes in size even, and keeping the IDE un cluttered with only the code.

The faster compiling through IDE -> CLI is a much welcomed feature although on my system things compile quite fast - that might benefit those with slower HDDs ? systems ?
and if the only con is having to save changes before compiling, that is really not a con because this is how it's done in studio

Judging your comments indicates you didn't even bother to read my post. Currently LGM loads your entire project into memory as one giant ass binary and then uses JNA to send that memory to the compiler, which requires changing endianess and is extremely slow as hell. The IDE could use the CLI interface and just pass the file to it to compile, is the whole point of this. To speed up the IDE, not make it slower.

#1) I did read your post, what caught my attention is you mentioning that one could create an entire project without an IDE, which is was hard for me to digest.

#2) using the CLI through the IDE means having to save each time a change is made.
This increases the likelihood of LGM crashing.  As I get cannot  create new thread and many errors when saving too frequently in LGM, and yes even with empty projects that have no sprites or any resources loaded.
So this would mean each time you want to run your game you would have to save changes. But what if you DON'T want to save changes and only save them if the result of your test is productive, you would have to "undo" the changes yourself and re-save, OR you would have to save to a different file.
Personally I could live with that if the pros outweigh the cons, that's how it works in studio anyway, if it means it makes LGM more stable it would be good, which won't be the case since the stability issues are regardless of project size as I've proven many times

Regarding the building an entire project without an IDE particularly large one that part I am not convinced at all unless you have an amazing photographic memory and can visualise a virutal room editor and automatically figure out all the X/ Y's and object properties mentally ! lol.

Of silly me, of course it has to do so for the alpha channel

So long as it is not converting sounds to crap quality as was done in earlier version of crapmaker.

TKG, which project are we talking about? Is it a project you've sent me? I can try building it.

Darkstar2, were these usually experienced on Windows? You have to report them when you get them, I never get anything remotely like that.

I only use Windows Robert, I am a windoze person
So yes it's all in windoze
It's JAVA the main fuck !
I'm starting to hate JAVA now now I know I will never touch this shit.
What LGM needs is a straight to ASM port 

Because the JVM limits a single thread to 1gb RAM on Windows and apparently 2.6gb's on Linux.

With 64bit Java I don't think there's a cap.

Won't make a bloody difference.  Like I said I work with tiny projects and it gives me out of memory crap, so I'm sure that my spriteless project and 1 object 3 lines of code don't take 1 GB lol.