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: Optimized GMX Loading
« on: February 04, 2014, 09:36:38 PM »

The first part I decided to go ahead and do is moving all the glyph and font metric shit out of the plugin and into LateralGM. This is for several reasons, but the base reason is GMX requires a texture stored with every font as well as the glyph metrics in the properties file. This will also make it easier to simply pass an EGM to the compiler by dumping the glyph metric information into the EGM. I guess this is why GM also dumps it to the GMX.

Now we can add proper support for multiple character ranged fonts. This however leaves me with some questions for Josh.

1) The current approach I made was to store the ranges and glyphs into a data Eef writer alongside the properties file. They look like this.
Code: (YAML) [Select]
  - [32, 127]
   - [32, 127]
   - [32, 127]
  - [132, 0, 0, 12, 12, 0]
   - [133, 12, 0, 12, 12, 0]
Now, currently I do not statically type out the parameter order for each property array, and because of ISO not guaranteeing parameter order if this would be an issue with YAML and Java? Also because the following occurs with all GMX projects exported by LGM.
Code: (XML) [Select]
   <glyph character="113" h="18" offset="1" shift="9" w="7" x="123" y="22"/>
    <glyph character="87" h="15" offset="0" shift="15" w="15" x="19" y="2"/>
Notice h is before offset and shift and not after w?

2) To make it possible for EGM to just be passed to the compiler, I will also need to store the texture into the EGM. I can do two things, I can tack it onto the end of glyph/ranges data file as just pure binary preceded by a 4 byte size header and just make that part of the data file illegible when opened in say notepad. The other option is to store a second data file, eg. "font_0.tex" and add a property to the range/glyph data file that tells us what format it is in, kind of like I did with shaders where I had two data files. Which do you like better?

3) So you like the simple way of sub-classing ResNode in order to accomplish responsive file editing? And also, do you think it is worth it to try and implement this behavior for GMK as well, or only EGM and GMX?

Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 04, 2014, 09:29:52 PM »
That should mean it can represent everything from 0 to 8192 fine.
That sounds ok when you first think about it but you have to leave a margin of error as a result of division and or other operators.
It looks like Wikipedia has some info on it.

Yes, with the floats being the metric system. Seeing how it's the primary data type in graphics, I don't see why fight with that.
Actually no it wouldn't be floats or pixels, but DPCI.

Floating point precision is only necessary in vector graphics, not raster graphics. And being that both Direct3D and OpenGL are 3D rendering API's, that explains why, also why graphics card manufacturers would decide to optimize for floats and vector based graphics.

0-255 is a weird approach if you ask me.
Yes but 0 to 255 is faster and more optimal since that is what 100% of API's use internally, not to mention 0 to 255 for only alpha is inconsistent with all other RGB functions already taking 255. The problem was Mark Overmars decided to go half way in between and do alpha as a float which is inconsistent with true 48bit color. I'd be fine with it if it was all 0 to 255 or all 0-1 with the option to switch to 0 to 255 to prevent casting. DirectX provides macros for 0-1 for each RGBA component, but those are also turned into 0 to 255 internally.
Here are all their definitions in d3d9types.h
Code: (C++) [Select]
#define D3DCOLOR_ARGB(a,r,g,b)       ((D3DCOLOR)((((a)&0xff)<<24)|(((r)&0xff)<<16)|(((g)&0xff)<<8)|((b)&0xff)))
#define D3DCOLOR_COLORVALUE(r,g,b,a) D3DCOLOR_RGBA((DWORD)((r)*255.f),(DWORD)((g)*255.f),(DWORD)((b)*255.f),(DWORD)((a)*255.f))
#define D3DCOLOR_RGBA(r,g,b,a)       D3DCOLOR_ARGB(a,r,g,b)
#define D3DCOLOR_XRGB(r,g,b)         D3DCOLOR_ARGB(0xff,r,g,b)
#define D3DCOLOR_XYUV(y,u,v)         D3DCOLOR_ARGB(0xFF,y,u,v)
#define D3DCOLOR_AYUV(a,y,u,v)       D3DCOLOR_ARGB(a,y,u,v)
Overmars going halfway in between also makes it difficult to write a single macro to do this.

Direct3D's float spec is here.

it always has, and always will, likewise for the alpha arguments in draw_sprite_ext(), draw_sprite_general(), draw_sprite_stretched_ext() and many other functions they all use 0-1 alpha arguments. So there's really no reason why a window alpha function should be dealt with any different IMHO.
You are missing the point, I can macro them to take whatever parameters you want. You could basically change 1 line and have all functions do 0-255, or switch them all to 0-1. Then people can choose which versions they want.

Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 04, 2014, 11:29:39 AM »
For example, texture coordinates don't need to be 32bit floats either, 16bit should be fine. So both x and y could be packed into one value and halve the size.
Texture paging is going to give us massive textures, potentially 8,192x8,192, I am afraid that would drastically reduce the accuracy. I hate floats, it's like an English system vs Metric system kind of thing.

Well, make it take alpha as 0-1 and I will merge it. As the only consensus was that I and Josh think it should be 0-1 and that you think it should be 255. Later it can be changed. But now for convention it should be 0-1. I personally didn't ever argue that internal representation needs to be changed somewhere. I just said that almost every function we have takes alpha as 0-1. So it only makes sense to stick with that.
I am not going to address just the one function I am going to make a separate commit where I address all color functions with new macros and types. It is going to be extensive work and I'd appreciate if it could be ambiguated from my current commit.

It will probably be forgotten later.
This is where general headers come into play, if a system does not implement all window functions in the general header, it is incomplete. Same concept applies to graphics and other sub systems. I have coded and committed them regardless of testing, I have done a lot of XLIB changes from Windows, sometimes they're winners sometimes they aren't, but I mostly do it negligently to get back at cheeseboy, since he's on that operating system and he never complies with my requests.

I did read. And the fact that is was in the same pull request is the reason why I didn't merge it. I cannot merge only half of the pull request as far as I know. So the reason bug fixes aren't pulled is because they also include functions we didn't want to pull in the current state.
I've completely removed the function, so you can go ahead and merge now.

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.