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

There should be a automatic auto completion system ( I mean the auto completion window appears 0.5 seconds after instead of having to use the shortcut ).
Yes definitely.

Some functions like these will not be supported.

"Global and local variable access by string lookup is likely to remain deprecated as they were essentially storing a map where every variable was accompanied by a second string variable. They were horrible for performance. "

You can see my words right on that Wiki page. I do not like these functions and they were bad programming habits. Josh has a plan that he might be able to readd them without using a map. Also, execute_string() is possible with Clang/LLVM which ENIGMA can and does currently work with on Linux, however, again, I hate that function.

- Undo function in the 'graphical' editors, especially in the rooms editor.
Yes definitely, when I get a chance.
- Adding the new functions of GM Studio, like array_length_2d.
That is a compiler feature, probably have to wait a while for that one, though when the new compiler is finished you'll be able to use the C++ STL containers. Which are much better at dynamically allocating memory.
- Improving the rooms editor (c.f
Yes definitely, in the future

It'd be nice to see Tiled support added in to the room editor, maybe?
Yes definitely, this however is an IDE suggestion not an ENIGMA suggestion, LateralGM and ENIGMA are two separate projects that can be used independently of one another.

*LGM replacement in C++
Not my fault you all too lazy to help with new LGM.
*Full DirectX functionality to the level OpenGL is at
It is as of my latest graphics commits, you just need to add tiles using standard primitive_* functions so they are batched and included from General for all graphics systems.

Do you think that's fixable though?
Yes definitely, the current IDE and plugin are Java based which makes them extremely slow when handling big games, we need to work on the new C++ LGM rewrite.

1.UTF-8 Support via FreeType

I'll never understand microsoft
They're out to make money, them having a Unix compatible file system does not help them in any way.

Tips, Tutorials, Examples / Hacking Windows Executables
« on: December 04, 2013, 05:09:28 PM »
This is just a tutorial for anyone who may be interested. You can use a special tool to modify executable files and changes things such as the copyright and change any Windows forms around.

Hacking the icon, description, and copyright information.

Step 1
Download and install Resource Hacker from the link below, if you do not already have it, which is the program we are going to use to do this. Scroll down the page at the link below if you can't see the setup, its there, just scroll down a bit.
Step 2
Open Resource Hacker from Start->All Programs and hit File->Open then navigate to and open the executable you want to modify. You can also just right click it in Windows Explorer and select "Open In Resource Hacker" it installs an option there by default, for me it does anyway.
Step 3
Make your changes to the exe, set the icon, and the copyright info, modify dialogues, etc.
Step 4
Save your changes to the exe, and it should automatically create a backup copy of the old executable.

Ideas and Design / Website Issue Tracker Sucks
« on: December 04, 2013, 04:54:17 PM »
The website tracker is a disgrace. It files all bug reports to the ENIGMA tracker and everyone who comes here ends up filing LateralGM and Plugin issues there, which is a serious problem considering there will eventually be multiple IDE's.

I have already begun to accommodate this by moving the plugin to its own repository and moving all your old bug reports there.

Not only does the site tracker look like shit, it parses in BBCode since it is simply an extension of our forum which makes it incompatible with Git MarkDown cuasing the real issue tracker on GitHub to look like shit too.

My opinion is we should simply get the fuck rid of it and replace it with an embedded Wiki page that links people to the proper GitHub repository trackers and explain to them where a certain issue should be reported and how we would like them to report. Currently nobody even takes the time to add test cases or even thoroughly describe their problems, people literally need to be lead around by the fucking hand, and our site tracker isn't helping.

Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: December 02, 2013, 03:37:32 PM »
But yes, anyway, you can still pack that in a way you could still put in vector<float>.
Yes but only using unions, as I said, you can't pack into a float like you can an integer for an RGB/RGBA color value because of IEEE, if you try it may work but it might not on other hardware because IEEE is not always followed and I guess ISO don't have a say?

Just without one if statement (i%2),
Oh yes, definitely, knock yourself out if you can make it faster :P

You shouldn't waste much time on it as it's already working quite fast.
Right yes, I am going to stop now, I just wanted it all perfected and so we can throw out the old GLES code and get it all working properly again.

I guess I will write a simple class for that later if you don't plan to and then we will finally be able to use shaders with the rendering.
Yes, just make sure you do the gm_Matrices or whatever stupid constant they use, check their manual for the matrix shits to make sure it matches up.

Also, we have some side effects now, such as OpenGL3 not being quite as prepared for the batching, and I've been working with Direct3D longer which has caused it to be more stable. Nevertheless, much better performance and lower RAM usage. Part of the issues are just the OpenGL 3 context manager not flushing on state changes, didn't add them all to it.

Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: December 02, 2013, 02:16:55 PM »
pack them just fine inside a float
No that was in fact why it wasn't working for me, I already knew you couldn't pack inside a float from when working on binary buffers, Josh clarified for me, IEEE does not guarantee any byte paste the first byte for floats. Which is where the union comes into play and I was finally able to resolve it now. But as for Direct3D, Direct3D not only expects it, but you have to use this for D3DCOLOR, as it is essentially a DWORD or long unsigned int. FVF requires D3DCOLOR.

But previously it was also converted into 1 draw call.
But without automatic indexing, unless we want to duplicate the code to do the same thing, which would be rather verbose as the rest of mesh class overhead is not even a pinch on the arm.

As you are using draw_vertex_texture() which doesn't add indices manually, and this means that you are doing that second loop to push back indices.
Right, that is faster, what you think manually adding them and increasing the memory copy's 10 fold is faster? Not only do you have the added memory copy's but you also have the compiler going through more function symbols, only to have the same end result. Where as the mesh class, simply reserves the memory, and generates those indices automatically, all in one go.

At any rate, this is all theory, unless something is presented that actually gives better performance all around for games, I am generally uninterested. The graphics code is much faster than all Game Maker versions, very easy to add new drawing functions, and faster than what we had before, and of course, no more immediate mode. So we got everything perfect, this system is optimal enough, let's just move on to fixing bugs with OpenGL3 batching and get the FFP into shaders and stuff now so we can get GLES working again, alrighty?

Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: December 01, 2013, 11:34:57 PM »
That what the attributes (or previously glColorPointer (which you still use)) are for.
Oh I see, but yah people say glColorPointer is for vertex arrays but I use it anyway because it is easier than using the damn attribute functions. All it does is tell OpenGL the offset and stride, Direct3D is a lot nice with this.

I doubt that is much slower
As I said, it is much slower, I went and decided to finally figure it out, and Josh complained to me about trying to do it as well saying to just pass as four floats. But what neither of you guessed is that OpenGL and Direct3D's FFP both expect only a 4 byte color (see D3DDECLUSAGE_COLOR). The only reason I was using floats before was because I could not figure out how to store all the vertex data into single vectors, and with a little help after nagging Josh to listen to me, he helped me get it working with unions.

It gave a 30fps speed boost in the text batching call from yesterday, and a 30fps boost in the Studio cubes demo now as well, with OpenGL 3 being fastest and peeking at 300fps.

I have added it to the following pull request where you can view the changes made.

a vector works a lot better.
No it doesn't when you are drawing lots and lots of sprites, this allows it to get even faster than the 5000 sprites calls at 30fps we had before for Direct3D and OpenGL3

In fact the following code, with the added overhead of it being a text drawing function, renders at 100fps for me, so its clearly necessary for very large batches to be run through my mesh class and be converted to a single draw call, just not for small/frequent batch flushes.
Code: (EDL) [Select]
    room_speed = 1000;
    draw_text(0, 0, "FPS: " + string(fps));
    repeat (5000) {
        var xx, yy;
        xx = random(room_width);
        yy = 50 + random(room_height);
        draw_text(xx, yy, "A");

And if I add the following code it still stays in the range of 60fps.
Code: (EDL) [Select]
So if we continue to properly think out the solutions to these things, we will continue to have them beat in every single scenario.

General ENIGMA / Canthelp/Default font
« on: December 01, 2013, 04:17:42 PM »
A while ago you wanted to add libtiff or whatever to generate a default font, I just ran across the fact of font_add.

Code: (C++) [Select]
int font_add(string name, int size, bool bold, bool italic, unsigned char first, unsigned char last)
  int res = enigma::font_new(first, last-first);
  enigma::font *fnt = enigma::fontstructarray[res];
  fnt->name = name;
  fnt->fontsize = size;
  fnt->bold = bold;
  fnt->italic = italic;
  fnt->glyphstart = first;
  fnt->glyphcount = last-first;
  return res;
That is the current implementation of font_add, I don't know if that even works or not, but I doubt it, because nothing is rendering the glyphs. A test should be done to see if this function works or not, and if it does not you can freely add libtiff to generate a default font, though the IDE should still render the fonts and place inside the GMX/EGM for later usage, I am only talking of for this function and for a default font.

Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: December 01, 2013, 03:28:59 PM »
It doesn't. It does the same thing - adds default color.
Right, so it adds default color, if the VBO does not specify color, without knowing if the VBO specifies color? Wtf harri?

Store were exactly? You can store them in float arrays just fine (this was done previously in my batching)
Yes, but you have no idea how much slower that is, which is why I find it funny we still kick Game Maker's ass at speed. But, you can simply merge those four bytes into a single float which would be MUCH faster, but I tried and tried and I could not get the alpha to work :\ which is why I temporarily just went with 4 floats. But for Direct3D this has to be done for the vertex functions they just added.

I guess I'll try. But only for GL3 of course.
Right, again, Direct3D is more stable with the batching because I have thoroughly tested it, and it was designed around the fact that Direct3D does not memorize render states and texture bindings AT ALL. Meaning you have to cache them and restore them on BeginScene(), which is actually kind of nice because this gives all the other possibilities I was raving about. OpenGL is going to be kind of wierd with this concept though because, OpenGL is not very OOP, just look at the difference between the two files so far.

But how will vertex_arrays be faster than VBO?
Heh, that depends on the situation, as far as batching we already know buffering is faster, eg. 575fps in Direct3D with 500 draw_text calls. But a vertex array is faster if you do a bunch of circles then circle outlines repetitively in the case I mentioned in the other topic. So when you want to draw a bunch of outlined stuff like that example or in my Box2D example, you would want to disable the batching so that it goes directly into a Vertex Array and then straight to the GPU without ANY of the overhead from the mesh classes. Because the mesh classes as optimal as they are, are REALLY slow for something very very small, which happens in the case of the circle example where batch flushes are frequent. The mesh classes are slow because they have to manipulate the contents and automatically generate the index buffer as well as perform a lot of memory copying around to interleave the vertex data.

At any rate, in all 3 graphics systems when batching is disabled we can simply use vertex arrays for all of the systems Direct3D, OpenGL3 and 1. But I also have another idea where we could automatically detect if the user is making frequent batch flushes and disable the batching for them. For instance, on begin scene we increment flushes by 1 and then in end scene decrement it by 1, if flushes ever becomes larger than say 5 consecutive flushes, we disable global batching, and if it becomes less than 5 consecutive flushes we re-enable batching.

Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: November 30, 2013, 11:24:09 PM »
So I agree that it shouldn't be done.
Right, but you can set flags for dynamic buffers and stuff, which does give serious performance boosts. And for OpenGL you simply want to BufferSubData if the formerly allocated BufferData data store region is still big enough to fit the new vertex data, otherwise you have to call BufferData so a new data store is allocated.

Yes, but how will you know if vertex has color or not?
I don't know that is what I was wondering, how the hell does the FFP know? GL_COLOR or whatever was a shader constant back in the old immediate mode shit.

So when using the default color the vertex buffer itself won't grow, although the vector in ram will.
Yes I changed my mind already Harri, why? Because then each time you change the drawing color you would have to flush the global batcher, so I guess doing it per vertex is the best solution. But then, the only problem is, what about models that didn't have color values added? They would already be buffered with the set drawing color from when they were created.

I was thinking on the lines of a custom attribute with the smallest type size that would basically work as a boolean.
This is another issue I/we have yet to resolve, nobody has come up with a fix to me storing color as 4 separate floats, I also love the fact that despite that we kick Studio's ass on that cubes demonstration. But anyway, somebody told me it don't matter anyway as the uhm color data would end up as 4 floats down the line anyway, but I don't believe that. I did attempt to merge the RGBA ints together into a single float, but I remember Direct3D being a piece of shit with anything past Red, probably because of its FFP shaders, which I had to use a damn custom vertex declaration which took me forever to figure out in order to avoid the FVF shit.

This is a bad idea.
No, not at all. When you disable batching OpenGL 1 would use immediate mode calls, and OpenGL3 and Direct3D would use vertex arrays. This would allow the data to be sent directly to the GPU without any overhead, which would speed up games such as my Box2D example and the draw circles test that was faster in 8.1 than Studio over in the other topic. You forget my model classes have to do rather intensive batching in order to get everything in the same primitive type, which is fine for models, but not for deferred rendering.

At any rate, I decided to let polygonz merge what I currently have.

You read correctly, 2/3rds of graphics systems are gone and all standard drawing and sprites/backgrounds are located in Graphics_System/General and all utilize draw_primtive_* functions which are themselves batched. So now Direct3D is pretty much as capable as the other graphics systems, and since I have been working on it with batching for some time is currently the most stable. So there are a few glitches now but the kinks just need worked out, OpenGL3 is pretty much a copy and paste effort over into GLES now and cheeseboy is going to attempt fixing Android, I'll probably help.

Also, now that you have these context managers in place Harri, you are free to replace the FFP with shaders as well as add the matrix functions you wanted. Studio also added matrix functions now as well and we will need to mimick their version. They are added at the link below.

I would link you the damn interim documentation they had since these functions were just added, but the fuckers have their website down.

stop smokin crack poly

Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: November 30, 2013, 12:08:08 PM »
Oh I see. Anyway, no, you can't just do that Harri, once its buffered its buffered, you can't modify the contents, I am talking about checking the shader if a vertex doesn't have a color then give it the set drawing color. The would solve everything, just have the default drawing color white, and everybody already knows enough to reset the color to white after they change it to draw something, so it would be super fast. I don't see any problem with that solution? But uhm, passing the set drawing color makes the vertex buffer substantially larger, when they all get the same color anyway, you could squeeze a lot more FPS out by not even passing it, which is why I am dropping our current solution too.

At any rate Harri, I now have Direct3D drawing everything just about except curves and stuff. I am starting to delete about 2/3rds of the graphics systems since all draw_sprite/background/standard draw now use draw_vertex_* functions which are batched automatically. The onlything that will be different between the systems is the model struct, the general folder now has source files as well as headers, like the following...

So now we can get GLES working again, and it will be extremely easy to maintain graphics functions. And if in the case I posted yesterday where you want a lot of outlined shapes, we simply add draw_set_batching_enabled(false); and then the draw_primitive_* functions will simply switch over to using software vertex processing or immediate mode for instance.

Anyway, when I fix OpenGL3 and 1 now we can replace the entire FFP with shaders and then get GLES working, and then cheeseboy is going to try to get Android working again.

Developing ENIGMA / GameMaker: Studio is EXTREMELY slow...
« on: November 30, 2013, 10:34:50 AM »

Well, I figured out how they are handling draw_set_color()

Harri, you were wrong, they are not adding it to each vertex if one is not passed. They are halting the ENTIRE graphics pipeline, and adding the currently set drawing color. I am amazed at their stupidity, the only thing I can think of is that Micro$hit gave them this idea, see the following article.

I tested this by simply doing the following before that model is drawn in the above screenshot.
Code: (EDL) [Select]
draw_set_color(choose(c_green, c_red, c_blue));

Which sure enough proved that the entire graphics pipeline was haulted in order to update the color vertices, this is only possible on a model without colors added to each vertex already, which is why when I originally tested this I couldn't get any results, I had to go and remove the color and alpha from their AddCube() script. I also tested with the built in block and other shapes to get these same results.

So anyway, I am going to scrap what were doing by adding it per-vertex, and sure as HELL not doing what they are doing. I am going to change the default drawing color to white and alpha to 1.0, then handle it all in the shader, it's the most optimal solution.

Proposals / Re: New Export Options
« on: November 30, 2013, 09:13:17 AM »
We already got shit working on Chromebook, that's what the damn ARM announcement was.

Issues Help Desk / Re: LateralGM crashing on OpenJDK on Trisquel
« on: November 28, 2013, 11:10:49 PM »
Unknown function or script `get_string'
That was a pretty simple bug, on Linux widget systems are not enabled by default. You need to download GTK, and then set it under Build->Settings "API" tab.

I don't know what went wrong with the second one.

Try this game:

Issues Help Desk / Re: LateralGM crashing on OpenJDK on Trisquel
« on: November 28, 2013, 07:17:27 PM »
Have you tried compiling a different game other than that one? For instance, please try some from the EDC, it could be specifically related to that game and could be an issue with something completely different.