ENIGMA Development Environment

Hope this helps TKG.
http://stackoverflow.com/questions/2908632/why-does-destroywindow-close-my-application

Howdy, and welcome to the forums!

But I'd like to ask, is modifying the source directly preferred to creating an Enigma extension?

It depends really, we try to keep a solid and stable base of functions from GM, but just about everything that some particular user would not directly need we try to throw into an extension. Simple rule of thumb is that if not everybody needs it; put it into an extension.

I guess if extensions are preferred, they'd be a template for adding them?

Yes sir, there is, just follow the other extensions in engima-dev/ENIGMASystem/SHELL/Universal_System/Extensions

Well I've got bad news, I started trying to write the extension and found out WM_TOUCH does not work with MinGW, the winuser header is all screwed up.
http://sourceforge.net/p/mingw/bugs/2236/

Ticket was just updated around the time we started discussing this. I am not sure what to do at this point.

X touch support looks pretty straight forward on the other hand.
http://who-t.blogspot.com/2011/12/multitouch-in-x-getting-events.html

I have gone ahead and outlined the Win32 extension in my pull request anyway; I believe I can just format the winuser header if I find it in the Windows SDK and redistribute it like I did for Direct3D11
https://github.com/enigma-dev/enigma-dev/pull/842

Sorlok, as far as the shader output, it would probably be better to post enigma-dev/output_log.txt because I believe we throw the errors in that file.

and you said the problem is with enigma.jar (the plugin) and not the IDE itself, these problems start to happen eventually - the longer I work in LGM,

Right exactly, that's the plugin, ENIGMA, not LateralGM. I only notice it when editing ENIGMA source engine files though, not just having LGM open or compiling multiple times, if I don't change source files I have no issues. Also I only seem to have a crash when mainly working with templates or STL because of how big the error logs are and it gets worse over time before crashing. That's an issue I'd like to work out.

Some are so easy to reproduce, just frequently save your project, eventually it will error out and the entire MFing project gets corrupted., including backups.

I literally saved Project Chaos over and over and over and over about a hundred times, and the JVM never tops 305mb RAM usage, just stays between 299 and 305.

Ok my apologies sorlok, I have run some tests and it appears your code is working fine.

WINDOWSmain.h
namespace enigma_user
{
void test_draw_clear(void* d3ddev);
void* window_device();
unsigned long long window_handle();
int sleep(int millis);
}

graphics_bridge.cpp
void* window_device() {
  return (void*)d3dmgr->device;
}

void test_draw_clear(void* d3ddev) {
  IDirect3DDevice9* dev = (IDirect3DDevice9*)d3ddev;
  dev->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_RGBA(255, 0, 0, 255), 0, 0);
}

Object Draw Event
test_draw_clear(window_device());

Works perfectly as expected and clears the background color to red. It must be an issue with the dll functions then.

IsmAvatar, the first whole part of your post I think we understood just fine, nobody is advocating for getting rid of the callbacks, no way at all.

@TheExDeus: While it's true that writing only the changes to the file could be faster than sending the whole file in memory, we need to remember a few things:
* In LGM, the file is already in memory. Sending that memory to ENIGMA does not require any effort, because it's shared memory. It's just a library function call to tell ENIGMA to actually read that memory.
* While having LGM save the file would be faster that way, you completely forgot that ENIGMA (cli) would now need to load the whole file. With library calls, the whole file is already in memory.
* The main reason for the slowdown in communicating the file to ENIGMA is because of a few limitations we had to deal with at the time which we continue to streamline. Mainly, we decided to rewrite the entire file into new slots of memory for passing to ENIGMA. That's completely unnecessary. If we just wrote the changes to memory and marked those as changes (so ENIGMA knew that those are the only parts that changed), that would be a better comparison to the individual resources written to file - and it would necessarily be faster because memory is always faster than files.

Here's where you seem to be kind of confused about our proposal though, that even Josh wants. If the project exists on disk, you don't have to load anything, the user clicks a resource and it is loaded and then they can change it in the editor, when you hit the save button all changed resources are committed to disk, and we would require you to save before changes would be reflected at runtime. This is like many other IDE's, but it would make LGM much better at working with large project files, even a native IDE should not have resources loaded that it is not concurrently working with or the user has any interest in. Does that make sense? But these changes would mean abandoning the GMK format because it is not easily expandable for this functionality, but EGM being ZIP's and GMX's being zip friendly those formats can do it.

But basically the reason we haven't done this yet is because I've wanted to make LGM very very stable with some awesome features, such as the search tree, before any GMK support is dropped. LGM in its current state is basically becoming better than GM8.1 or GM ever was as an IDE pretty much.

If I could see the game file, I could help figure out where the parsing is screwing up, our compiler is not quite yet completed so it can finicky about some things, especially the following...

if true
  // do something
else {
  // do something else
}

Which believe it or not I see quite often in GM games and it always fails to parse. If you don't feel comfortable uploading the file here you may also send it in a PM to me, I can't really tell though without looking at some code snippets.