Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Goombert

812
Issues Help Desk / Re: Bad C++ generation
« on: October 04, 2014, 09:28:48 AM »
Sorlok, I'll be honest, I was more interested in overloading var for array so we can test array lengths and also to return arrays of pixel data from background functions, like background_getpixels is what I wanted to do. Studio added some of these functions which I'd also like to have. It is much easier for heightmaps and stuff, and the old way of drawing to the screen then draw_getpixel one at a time was soooooooo slow. But currently regular arrays don't even work in the parser, and to overload var we'd also have to overload std::array which I tried and failed at.

813
Proposals / Re: Extended Binary
« on: October 04, 2014, 09:02:20 AM »
Howdy, and welcome to the forums!

Quote from: TheStolenBattenberg
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.

Quote from: TheStolenBattenberg
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

814
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 08:53:17 AM »
Quote from: Harri
That is weird. Can you run in Debug mode and see if it outputs anything to console?
I believe it might be because that game uses screen_refresh() to read the heightmap data from the background/sprite. Sorlok, are you testing on Compiz?

Quote from: Harri
Performance gain is basically because of reduced GL function calls, in Project Mario they went from 5215 per frame, to 3222. Almost 40% reduction. But sadly it doesn't mean much, as some calls are very fast, others are not. Optimizing for the slow ones is the way to go from now.

I can tell you, I think some of the slow down is VBO's used for sprite/background batching. I believe vertex arrays are a lot faster for dynamic draw. But this is in regards to regular consumer hardware, I don't have a graphics card as good as yours Harri, so in some cases (like sprite batching) software vertex processing is just optimized a lot more I guess.

815
Programming Help / Re: Windows 8 touch support
« on: October 04, 2014, 02:20:55 AM »
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

816
General ENIGMA / Re: ENIGMA's Engine Code - License Comparison
« on: October 04, 2014, 02:18:42 AM »
Right I understand Rez, and I agree. Now, don't everybody freak out, but what about Creative Commons? I know I know, but still it is a choice.

817
Developing ENIGMA / Re: Massive GL3.3 changes.... again
« on: October 04, 2014, 12:06:09 AM »
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.

818
General ENIGMA / Re: Lateral GM question
« on: October 04, 2014, 12:04:54 AM »
Alrighty, but yeah lots of bug fixes have been made, and I can't fix things without knowing about them... so how else will they ever get fixed? etc etc

819
General ENIGMA / Re: Lateral GM question
« on: October 03, 2014, 11:43:27 PM »
Quote from: Darkstar2
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.

Quote from: Darkstar2
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.

820
Programming Help / Re: [Solved] Adding a new function
« on: October 03, 2014, 11:30:39 PM »
Oh boy sorlok, I haven't really worked with dll's that much so I don't know how to reproduce and test what he's testing. In fact I don't think I've ever written a dll before, except changes to the compiler which make compileEGMf, but other than that I've never made my own dll's before. Additionally Josh would be the best person to talk about variant, I don't think I would be able to fully understand the implications.

821
Programming Help / Re: [Solved] Adding a new function
« on: October 03, 2014, 11:07:46 PM »
Ok my apologies sorlok, I have run some tests and it appears your code is working fine.

WINDOWSmain.h
Code: (C++) [Select]
namespace enigma_user
{
void test_draw_clear(void* d3ddev);
void* window_device();
unsigned long long window_handle();
int sleep(int millis);
}

graphics_bridge.cpp
Code: (C++) [Select]
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
Code: (EDL) [Select]
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.

822
Developing ENIGMA / Re: Unstable master?
« on: October 03, 2014, 10:53:24 PM »
No actually, it would increase performance for games that scale up because currently we resize the backbuffer and the game gets rendered at a higher resolution. GM always keeps application_surface the same size as the region and then scales it, so when you set the game fullscreen the resolution doesn't increase it just scales, ENIGMA does increase the resolution.

823
General ENIGMA / Re: Lateral GM question
« on: October 03, 2014, 10:51:13 PM »
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.

Quote from: ismAvatar
@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.

824
General ENIGMA / Re: ENIGMA's Engine Code - License Comparison
« on: October 03, 2014, 10:44:14 PM »
Rezolyze, I really like your topic, it is very informative and this is the best way to approach a license change. I really like this topic, I am thinking about setting it pinned somewhere but I don't know the best place for it. Additionally the information you've provided also helps me because I do not know that much about the various licensing options myself, though I have no problem understanding legal jargon.

I think personally my choice is the BSD license and MPL second. But my primary concern is that I have stated in the past and will reiterate that I do believe users should retain the rights to even sell extensions that would implement things like video functions, other graphics libraries, etc, etc. I just do not want fixes for anything in /SHELL being commercialized, I think this is primarily our biggest concern.

825
Issues Help Desk / Re: Bad C++ generation
« on: October 03, 2014, 10:39:00 PM »
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...

Code: (GML) [Select]
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.