ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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: 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: http://enigma-dev.org/edc/games.php?game=43

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.

Developing ENIGMA / Re: Why is GameMaker: Studio so slow?
« on: November 28, 2013, 04:57:11 PM »

(which if I remember correctly was already batching everything via high-level DX magic), so that's funny.
No, this was actually my fault with not setting the index buffers to write only and not setting the new global batchers to dynamic memory usage and I had the models in the wrong pools. Don't blame Direct3D for my lack of inexperience with the API, it has enough reasons on its own of why it sucks. And it is still slower than OpenGL as well, from actual test cases I have been running with the proper memory pool set up and everything.

And that is what they can do.
A simple draw_batch_begin()/end() would suffice like every other game engine. But because of it having to be like this I am going to add draw_set_batching_enabled()

If the user knows how batching works, then he can fine tune the code for massive speed boost.
You are still completely missing the problem here, having such a system as this does not make every game faster, my Box2D example with the new system on my end as optimal as it can be now runs 1/3rd of the speed it did run at. There really is no solution to this problem.

Sslaxx, not in this particular case no, as we already have texture binding memorization in my context managers, texture atlasing can improve game performance down the road for certain games. But please don't be mislead by YoYoGames, texture atlasing is not the only thing you need to worry about, you need to worry about ALL render state changes, that includes enabling/disabling lighting, texture repetition, and any thing else that is either FFP or shader based. Texture atlasing won't become necessary until we start on mobile ports. But also, my context managers do memorize all render states and everything, this is currently what im partially working on for OpenGL 3 as it needs perfected for me to add these new matrix functions just released.

Developing ENIGMA / Re: Why is GameMaker: Studio so slow?
« on: November 28, 2013, 10:37:01 AM »
AsuMagic, it is only a particular case. You see the way graphics API's work, you want to try to batch EVERYTHING into a single vertex buffer object. For instance in ENIGMA, each d3d model is a single VBO and sometimes it has an IBO or index buffer object attached. Now, these VBO's can contain 6 different primitive types, in the following order INDEXED TRIANGLES | INDEXED POINTS | INDEXED LINES | TRIANGLES | POINTS | LINES due to me being the one who designed it. Now the issue is, if you batch a bunch of triangle primitives together, which is the filled circle, since every filled circle is a triangle fan, they keep their depth and are drawn first when the VBO actually renders to the screen. The global VBO decides to draw its contents when stride changes or other render states such as color or text changes. Anyway, it batches the circle outlines as line lists, and the circle outlines will maintain their depth with each other.

But the issue occurs when doing both filled and outlined circles, since if you draw the indexed triangles first, they keep their depth, and so does the indexed lines, but they don't keep their depths relative to each other. So in other words, all the line primitives render on top of the filled circle/triangle primitives causing the depth to be screwed. So that means the global VBO now has to render each time its primitive type changes, which drastically slows it down because it has to get run through all this overhead instead of just being sent directly to the GPU and rendered. But anyway, this is why 8.1 is faster with this test case because it didn't do any batching with any overhead and sent everything directly to the GPU after interpretation.

Sorry if it doesn't make much sense but it is a rather complex graphics issue :(

Developing ENIGMA / Re: Why is GameMaker: Studio so slow?
« on: November 28, 2013, 10:10:40 AM »
Yes, but you are missing the point entirely, I explained why ENIGMA has this same issue as well. This is actually why I've been stuck the past couple days unable to finish my improvements to D3D and OGL3, as I am unsure exactly what to do. I am trying to think if I can come up with a solution that makes ENIGMA faster in all scenario's.

Developing ENIGMA / Why is GameMaker: Studio so slow?
« on: November 28, 2013, 09:57:27 AM »

So while working on the global batchers to get the context managers finished for OGL3 and D3D so I can add the new matrix functions for Harri, I decided to do a little test.
I ran into a particular issue with an auto-magic global batching system, and that is when you are constantly changing the stride or primitive type of a global batcher. I was disappointed in how much slower it caused my Box2D physics example to run as it draws a lot circles and rectangles with outlines, so I decided to test if Studio also has this issue. Sure enough it does, you can run the two examples below by simply making an empty project with 1 object whose draw event is the code below, sticking that object in a room and hitting run in either ENIGMA or Studio.

The first example demonstrates the batching problem that no batching system can really resolve, this also ran at 183fps in Game Maker 8.1 because it just drew the primitives instantly without any overhead.
minFPS, maxFPS, avgFPS
41, 52, 48
Code: (EDL) [Select]
    room_speed = 1000;
    draw_text(0, 0, "FPS: " + string(fps));
    repeat (500) {
        var xx, yy;
        xx = random(room_width);
        yy = 50 + random(room_height);
        draw_circle(xx, yy, 10, false);
        draw_circle(xx, yy, 10, true);

This demonstration shows that global batching does help when not constantly switching stride and primitive type as this example ran 3 times slower 8.1
minFPS, maxFPS, avgFPS
60, 583, 524
Code: (EDL) [Select]
    room_speed = 1000;
    draw_text(0, 0, "FPS: " + string(fps));
    repeat (500) {
        var xx, yy;
        xx = random(room_width);
        yy = 50 + random(room_height);
        draw_text(xx, yy, "wtf");

I am really at a loss for what to do here as I am historically in favor of users learning to do the batching themselves so they can fine tune it to perfection, I do not like trying to auto-magically make games faster. But then again I suppose it is not that big of an issue since I can always add the ability to disable global batching later on anyway, and well OpenGL 1.1 we had no plans of ever adding global batching to, so it's perfect. But anyway, moving forward, ENIGMA will have this same issue with drawing shape outlines in Direct3D and OpenGL 3 and I will later add an option if there is a lot of need for it, and OpenGL 1.1 will never have this issue, since it expects you to do shit yourself.

Nah it's my fault, I was trying to make DirectX default on Windows but I don't have the time to maintain the systems, I have reverted it to OpenGL1.1 and OpenAL being the default systems in my latest commit yet to be pulled.

I've had issues with events disappearing from an object, too - related
Nope that would be completely the IDE, sounds like a new issue. You can report the issue to LGM's tracker below and it will be resolved when someone gets a chance.

Our plugin is what the IDE uses to communicate with ENIGMA, you can use LGM on its own without ENIGMA since it is the only program which can edit GMK/GMX for Linux and Mac.

At any rate, that output log offered me nothing useful, nothing went wrong in that, look for the file output_log.txt and http://www.pastebin.com that for me.