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

1831
Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 04, 2014, 11:29:39 AM »
Quote
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.

Quote
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.

Quote
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.

Quote
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.
https://github.com/enigma-dev/enigma-dev/pull/635

1832
Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 04, 2014, 08:19:12 AM »
Quote
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.

Quote
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.

Quote
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.

1833
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.

1834
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?

1835
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.

1836
Developing ENIGMA / Re: Optimized GMX Loading
« on: February 03, 2014, 08:47:01 AM »
Quote
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.

Quote
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.

Quote
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.

Quote
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.

1837
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.


Quote
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.

Quote
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.

1838
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;
                        }
               
                @Override
                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;
                          LGM.currentFile.resMap.getList(Sprite.class).lastId++;
                          spr.setNode(this);
                         
                          String fileName = new File(getUnixPath(classpath)).getName();
                          spr.setName(fileName);

                          String path = LGM.currentFile.getPath();
                          path = path.substring(0, path.lastIndexOf('/')+1) + getUnixPath(classpath);
                         
                                Document sprdoc = null;
                                try
                                        {
                                        sprdoc = documentBuilder.parse(path + ".sprite.gmx");
                                        }
                                catch (SAXException e)
                                        {
                                        // TODO Auto-generated catch block
                                        e.printStackTrace();
                                        }
                                catch (IOException e)
                                        {
                                        // TODO Auto-generated catch block
                                        e.printStackTrace();
                                        }
                                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;
                                  try
                                                {
                                                img = ImageIO.read(new File(path + getUnixPath(fnode.getTextContent())));
                                                }
                                        catch (DOMException e)
                                                {
                                                // TODO Auto-generated catch block
                                                e.printStackTrace();
                                                }
                                        catch (IOException e)
                                                {
                                                // TODO Auto-generated catch block
                                                e.printStackTrace();
                                                }
                                  spr.subImages.add(img);
                                }
                        }
                       
                        return super.getRes();
                }
       
        }

1839
Programming Help / Re: Using external resources (loading/unloading)
« on: February 03, 2014, 12:28:31 AM »
Quote
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.

Quote
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.
https://en.wikipedia.org/wiki/Working_directory

Quote
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.

Quote
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.

1840
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.
http://www.gtamodding.com/index.php?title=IMG_archive

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.

http://enigma-dev.org/docs/Wiki/Execute_shell
http://enigma-dev.org/docs/Wiki/Execute_program

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.

1841
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.

1842
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.
http://enigma-dev.org/docs/Wiki/LateralGM:_Revisions

1843
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.

1844
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.
http://en.wikipedia.org/wiki/48-bit
Note: 48-bit color is also known as deep color and implemented as 16-bits/channel.
http://en.wikipedia.org/wiki/Deep_color#Deep_color_.2830.2F36.2F48-bit.29
One of such programs that can do so is 3DS Max.
http://docs.autodesk.com/3DSMAX/15/ENU/3ds-Max-Help/index.html?url=files/GUID-DEDEE7A3-8B3F-4A00-B156-E6771EE3FFEC.htm,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
http://www.opengl.org/wiki/Image_Format

Quote
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.

Quote
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: (C++) [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);

1845
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.