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

Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 04, 2014, 08:19:12 am »
Robert: are you saying that you added window alpha and that's it?
It was two functions I added to my commit containing other bugfixes, I just implemented because it is useful, and I like to add things that Studio thinks aren't cross-platform.

But the topic went into me suggesting that all Windows be managed and all window functions accept the window id. Which is basically what you want to do, create and manage multiple windows. You could basically call the old version of the functions which modify the default window or add a specific window id returned by window_create or window_get_default. It would require a hefty amount of work, but I could get it done in about a day along with macro'ing the color parameters.

Just tell Josh or Harri to merge the current pull request I have so Linux can at least build again.

Btw, I noticed that these new functions are windows only. Shouldn't we be making cross-platform for at least Linux and Mac as well?
Right, you think Cocoa and XLIB don't support transparent Windows? I wouldn't add the function if they didn't.

Which gives me another idea, I don't know if it's possible, but I wonder if Josh could make JDI parse out code that is checked by the os_type constant and make it work like a pre-processor directive.

I think Robert can add this. I think the same windows API call he added for transparency is the same that did this.
I don't understand, window_set_color() you mean? It is possible to make a combined function that accepts RGBA, but I don't think that is a good idea since it is a separate flag for transparency.

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 03, 2014, 12:51:00 pm »
Alright so you are ok if I restructure the abstract base ResNode class to work this way with the various readers and writers?

If so we'll at least have extremely responsive times working with files, and compile time will speed up anyway because LGM's current resource population is slower than just saving an EGM.

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 03, 2014, 12:25:31 pm »
I am not exactly following Josh, that would not help to improve GMX compiling times though. If we were going to do that we should do what Studio does and force all projects when loaded to auto-convert to EGM, which I don't particularly care for.

Basically, are you saying if I was working on a GMX and hit compile, the plugin would write out an EGM and the compiler would load that? And that would serve as communication buffer population?

Programming Help / Re: 2D multi-dimensional arrays
« on: February 03, 2014, 10:31:19 am »
This appears to be a compiler issue because if I run the following code.
Code: (EDL) [Select]
var myarray[1];

myarray[0] = 0;

I get this error message.
Quote from: Progress Frame
C:/ProgramData/ENIGMA/Preprocessor_Environment_Editable/IDE_EDIT_objectfunctionality.h:37:14: error: 'myarray' cannot be used as a function
     myarray(0)= 0;
mingw32-make.exe[1]: Leaving directory

Indicating that JDI for some reason parsed it out into a function call. So no it wasn't your fault at all egofree, the compiler turned your code in C++ and thought it was a function call.

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 03, 2014, 08:47:01 am »
I always wondered why couldn't it only send resources that changed?
That actually gives me an idea, if ENIGMA implemented a callback for dumping the old resources, kind of like Studio's clean assets cache option. Then LGM could control when this cache is cleared, and only clear it if you load or create a new project, and otherwise only send new resources to ENIGMA when they are added or when old ones are changed.

We could pull that off, and like I said that is probably what Studio is doing now that I think about it. Josh should give some input here.

Like create a .dat file or something inside the C:\ProgramData\ENIGMA if need be and just reload/modify that.
That would be the same as just making ENIGMA only work with EGM or something. This is only useful if we could implement a command line interface which there has been effort to do before. This is again why Studio has the advantage since it only ever works with GMX internally but import GMK or GMZ and export GMZ.

Another solution I thought could be good would just to thread the whole thing. Like if the thing is done in memory now (instead of disk), then couldn't you just make it populate several resources in parallel?
Sounds like what Josh was suggesting and telling polygonz how to add. But I was skeptical because Josh never clarified it to me, I could do it probably but I'd like an explanation and reasoning as to how that could improve the performance but I really don't see how since compiling is already threaded.

Which also brings me to the implementation of threaded loading. The reason we never threaded loading and saving projects before was because you really shouldn't be dicking around with anything resources or anything while that is occuring since it will all be undone anyway once it finishes and leaves the door wide open for a host of exceptions. Also the reasoning behind the implementation of the modal dialog.

Now most IDE's like Visual Studio or Qt or Eclipse will do the GMX suggestion and only load a file once you open it, they just load the tree like the suggestion in my OP. This goes back to what I was saying about ENIGMA's CLI as well, the reason these programs can utilize that effectively is because the respective compilers have a standard format eg. "GNU make" like how Studio only uses GMX internally.

All of that is speculation, as I don't know how LGM does that (I guess the plugin does that?) and I don't really plan to Java anytime soon.
Yes that is the plugins Job, LGM is not made for a particular purpose. Java isn't scary, don't be afraid of it, C# is just a ripoff of it, down to every single core package.

Also Harri in case you didn't realize I only tested on Sprites there with GMX, so once every resource had the abstract tree node you would essentially load a GMX even if it was several Gigabytes in less than a second.

Developing ENIGMA / Re: Optimized GMX Loading
« on: February 03, 2014, 08:01:43 am »
This morning I actually went and implemented a progress dialog so you no longer just sit there and wait but actually have some feedback. GMK and GMX are the only formats that do it right now though as the EGM reader and writer is so complex I don't think you can track its progress easily.

But I guess if the compile is slower only once, then it is not that big of a problem.
You see this is interesting, and I'll tell you why, because it gives YoYoGames a slight advantage over us. If they did this they could use GMX as their internal serialized format at all times and when it comes time to compile only save the files that were changed. Then the compiler itself would load the resources from this serialized format, which if we could do would bypass LGM populating resources one at a time, and would eliminate loading the whole project and passing it to ENIGMA.

I would like to see what Josh has to say about this.

Though I don't use gmx at all... Will this change also impact other packed formats like EGM?
I was only proposing implementing special tree nodes for GMX that override the basic ones for now. But GMK and EGM can theoretically do this, GMK would just have to move to the correct stream position in order to read only a single resource, not exactly sure about the practicality of it. But all formats in theory can do this.

Developing ENIGMA / Optimized GMX Loading
« on: February 03, 2014, 03:44:40 am »
I wanted to make part of LGM's 1.8.4 development about optimizing GMX loading and saving. Many of us have already discussed this optimization technique, and everybody is already aware. I have started by running a simple test of a way I think I can add it to LGM pretty easily.

The idea is pretty simple, you only load the resource tree when somebody opens a project and only load each resource when they open it in an editor, and only write it when they actually make changes. This can effectively bring loading times down to instant even for very big projects. The only downside is that conversion from GMX to another format will be twice as long. The reason is because loading was postponed and when it comes time to write to the new format you now have to load all resources and then write all resources.

There are still a few faults with this however, one of them being compile time. When it comes time to compile and run the game all resources need to be in memory. So this would then make the first time you hit the run button twice as long as well. This could also explain why Studio does not do something similar.

Here is an image of loading Son of Blagger with my new prototype class below. Note that I have not added the preview icon just yet.

I added the following prototype class to the GMX reader. This class is used to postpone a ResNode's resource reference to the first time that it is accessed. Testing with it on egofree's Son of Blagger brought loading time from 2,500ms to 1802ms.
Code: (java) [Select]
public static class GMXSprite extends ResNode {
private boolean loaded = false;
private String classpath = "";

public GMXSprite(String name,byte status)
super(name.substring(name.lastIndexOf("\\") + 1, name.length()),status,Sprite.class,null);
// TODO Auto-generated constructor stub
classpath = name;

public ResourceReference<? extends Resource<?,?>> getRes()
if (!loaded && status == ResNode.STATUS_SECONDARY) {
loaded = true;
Sprite spr = LGM.currentFile.resMap.getList(Sprite.class).add();
res = spr.reference;
  String fileName = new File(getUnixPath(classpath)).getName();

  String path = LGM.currentFile.getPath();
  path = path.substring(0, path.lastIndexOf('/')+1) + getUnixPath(classpath);
Document sprdoc = null;
sprdoc = documentBuilder.parse(path + "");
catch (SAXException e)
// TODO Auto-generated catch block
catch (IOException e)
// TODO Auto-generated catch block
spr.put(PSprite.ORIGIN_X, Integer.parseInt(sprdoc.getElementsByTagName("xorig").item(0).getTextContent()));
spr.put(PSprite.ORIGIN_Y, Integer.parseInt(sprdoc.getElementsByTagName("yorigin").item(0).getTextContent()));
spr.put(PSprite.SHAPE, ProjectFile.SPRITE_MASK_SHAPE[Integer.parseInt(sprdoc.getElementsByTagName("colkind").item(0).getTextContent())]);
spr.put(PSprite.SEPARATE_MASK, Integer.parseInt(sprdoc.getElementsByTagName("sepmasks").item(0).getTextContent()) < 0);
spr.put(PSprite.BB_MODE, ProjectFile.SPRITE_BB_MODE[Integer.parseInt(sprdoc.getElementsByTagName("bboxmode").item(0).getTextContent())]);
spr.put(PSprite.BB_LEFT, Integer.parseInt(sprdoc.getElementsByTagName("bbox_left").item(0).getTextContent()));
spr.put(PSprite.BB_RIGHT, Integer.parseInt(sprdoc.getElementsByTagName("bbox_right").item(0).getTextContent()));
spr.put(PSprite.BB_TOP, Integer.parseInt(sprdoc.getElementsByTagName("bbox_top").item(0).getTextContent()));
spr.put(PSprite.BB_BOTTOM, Integer.parseInt(sprdoc.getElementsByTagName("bbox_bottom").item(0).getTextContent()));
spr.put(PSprite.ALPHA_TOLERANCE, Integer.parseInt(sprdoc.getElementsByTagName("coltolerance").item(0).getTextContent()));

//TODO: Just extra shit stored in the GMX by studio
//int width = Integer.parseInt(sprdoc.getElementsByTagName("width").item(0).getTextContent());
//int height = Integer.parseInt(sprdoc.getElementsByTagName("height").item(0).getTextContent());

  // iterate and load the sprites subimages
NodeList frList = sprdoc.getElementsByTagName("frame");
  path = LGM.currentFile.getPath();
  path = path.substring(0, path.lastIndexOf('/')+1) + "/sprites/";
for (int ii = 0; ii < frList.getLength(); ii++) {
  Node fnode = frList.item(ii);
  BufferedImage img = null;
img = File(path + getUnixPath(fnode.getTextContent())));
catch (DOMException e)
// TODO Auto-generated catch block
catch (IOException e)
// TODO Auto-generated catch block

return super.getRes();


Programming Help / Re: Using external resources (loading/unloading)
« on: February 03, 2014, 12:28:31 am »
really!?!?!? I thought it was a function that did exist in GM, at least in 8.1, and I recall in early versions of GM:S...hmm.  I recall something that GM:S already uses external resource files, in my opinion it is poorly implemented.
sound_add exists in 8.1 and lower, Studio uses a new 3D positional audio engine, or basically just OpenAL, they also butchered the original implementation pretty bad, they just deprecated half of the functions too. They have never added audio_add.

Weird, and so how are you supposed to make big games then ? If I wanted to make an adventure game with tons of hi-res scenery and sprites, how would I do that without external ?  I think they use external handling only for certain things, but from what I saw it is not done well and you have no control over it.
Right, they really don't care about that, because it is primarily a 2D game engine, and all the attention is on mobile development. In fact you no longer even have access direct access to your projects working_directory, a working directory for an application is usually the path where the executable is run.

Interesting, so I don't have to use system().
The problem with those two functions however is they are unlikely to work for mobile devices and you'll probably need to check os_type to run a different command on Linux/Mac.

Nice isn't it ?
I have a conspiracy theory they broke all those extensions on purpose so people would upgrade :\

Anyway it is important to note, things like our Box2D extension for physics uses a dll, though not actually. Our extensions build the library directly inside the game executable because all of the extensions I wrote are static linked.

Programming Help / Re: Using external resources (loading/unloading)
« on: February 02, 2014, 12:48:28 pm »
Sorry I didn't get a chance to read this yet, let me write a reply.

Quote from: Darkstar2
I have been pondering on this for quite some time now.  At the current stage I don't like the way GameMaker handles resources.  It is better suited for smaller games that can load all resources at startup but can become a memory hog and problematic for those with a bit more ambition who want to make big games and use large sprites and other resources.
This is actually one of my main gripes, although they claim to be making all these new advancements, they are forgetting functions like audio_add, which does not exist, at all, well except in ENIGMA. They seem to be wanting to do away with external resources.

Quote from: Darkstar2
So in this example res_load will pass along MUSIC.PAK which is the single large file containing all game music and extract act2.mp3 from it and store it in act2_snd.
What you are suggesting is similar to Grand Theft Auto's IMG format.

Quote from: Darkstar2
don't believe this is possible in ENIGMA either due to the compiled nature,
execute_shell/execute_program is implemented in ENIGMA

I even went and documented the functions for you.

Quote from: Darkstar2
If ENIGMA could support this natively and handle all this dynamically that would be so amazing, but I understand that would require some time to get implemented right ?
It's very possible somebody just needs to take a popular ZIP API or 7ZIP's and write an extension for it. I would if I had a lot more time on my hands.

Quote from: time-killer-games
It does support DLL's I've tested this a while back and it worked.
You do realize all the cool extensions like GMOgre, 3D particles, Ultimate 3D, etc. etc. Are all still broke, right? They all need rewritten because every GM extension relied on GMAPI which is defunct with Studio.

Edit: Sorry, I thought you were talking about GM.

Quote from: time-killer-games
It would be better if we had a regular zip file and have it password protected and extracted to a well hidden temp directory at runtime with files deleted when no longer in use or when the game is closed.
Yes, but the point here is to not force this on everyone like what YYG tries to do. The better idea would be to simply implement file_temp_* functions and write a zip_* extension.

Issues Help Desk / Re: Particles not displaying properly
« on: February 02, 2014, 12:35:20 pm »
Thank you inty that will help me resolve it, I am swamped ATM with other bugs, this is on my todo list though.

General ENIGMA / LateralGM and Plugin Revisions
« on: February 02, 2014, 12:26:10 pm »
So after a few of my recent fixes and getting LGM pretty solid I have decided to move her into 1.8.4

As a part of this I backed up all copies of LateralGM and the plugin I have available and you can find them on the following Wiki page.

Proposals / Re: Request: Cursor Lock
« on: February 02, 2014, 11:10:01 am »
I can go half-way, while I am touching up these fixes to LGM I am going to make it enabled by default in Global Game Settings. But I do not want to remove the option all together, it just addresses the issue with people being too lazy or not aware that they should enable the option under certain circumstances. Well more so as you said in most cases, really games shouldn't continue running in the background.

Edit: Done, while we are the on subject nobody has fixed my version for Linux yet, it needs done, it is a very important setting.

Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 02, 2014, 10:52:04 am »
Quote from: JoshDreamland
(1) ISO RGB does not concern alpha. Maybe you meant to quote something from ISO that includes the letter "A" or specifically mentions phrases such as "alpha" or "opacity."
Actually, the point was the lack-thereof the alpha.
Note: 48-bit color is also known as deep color and implemented as 16-bits/channel.
One of such programs that can do so is 3DS Max.,topicNumber=d30e524001

Quote from: TheExDeus
This is because GM stores all colors in int's (and so does ENIGMA
And so does Java, GM used to waste the remaining 8 bits.

Quote from: JoshDreamland
Moreover, Game Maker never used ARGB.
OpenGL prefers RGBA, Direct3D prefers ARGB. I am not arguing with you, it is just important to note.
Quote from: OpenGL Wiki
Colors in OpenGL are stored in RGBA format. That is, each color has a Red, Green, Blue, and Alpha component

f we keep adding their shit ass implementations of functions, then ENIGMA will become as chaotic as GM. We either have to start ditching that useless compatibility with GM:S. Or stick with their bull only in their functions and use correct (and consistent) convention in ENIGMA functions. I wouldn't have problems with ENIGMA taking 0-1 in all functions, but that clearly isn't possible. Unless we start putting colors in structs (or classes) and then overloading drawing functions.
3 chars followed by a double is more consistent than 4 bytes? I don't think so, YYG is at least getting closer to following standards, however very poorly. I am not arguing in favor of their shit, I am simply arguing in favor of color being 4 bytes internally. Whatever wrappers or macro's people want to add for color is perfectly fine.

In fact, we can just go ahead and drop this debate and macro all the functions that accept color, people can toggle between 4 floats, 3 bytes and a float, or 4 bytes, whatever the hell they choose, and we just convert it internally to 4 bytes RGBA, which is what our engine should use always, everywhere. I'll write it up later.

They are not merged because we are clearly still talking about them. We should do this more often, than just randomly merge all the stuff you somehow deem worthy. That is why I personally only merge for bug fixes instead of new functionality. For new functions I actually try to read the code.
Then you didn't bother to read the pull request, it contains a number of fixes to outstanding bug reports including ENIGMA being able to finally syntax highlight its own functions, but that topic was buried by this one, but both were part of the same pull request.

Quote from: JoshDreamland
, as to whether we embrace a byte for alpha or a float, I am unbiased. Robert prefers bytes for the sake of cards with terrible memory bandwidths, which ENIGMA should ideally cater to as well.
Macro expansion Joshi, read above. On a side note, I just realized your name is Yoshi with a 'J'.
But also, I actually want ENIGMA's defaults to be RGBA, as in make_color_* would expand to the following...
Code: (cpp) [Select]
unsigned make_color_rgba(byte red, byte green, byte blue, byte alpha);
unsigned make_color_argb(byte alpha, byte red, byte green, byte blue);

Proposals / Re: Request: Cursor Lock
« on: February 02, 2014, 10:07:06 am »
Please for the love of god make sure you enable "Freeze form when the game loses focus" even non-GM games fail to do this. It is damn near impossible to ALT+Tab out of games, fucking pisses me off sooooooo bad.

Proposals / Re: Embed SWF?
« on: February 02, 2014, 10:03:25 am »
Yes I wanted that in my Mario topic as well because I have YouTube videos. Josh randomly added the double clicking to size up images for me already so I am sure he can figure it out.