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

2101
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.
https://github.com/enigma-dev/lgmplugin

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.

2102
Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: December 02, 2013, 03:37:32 PM »
Quote
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?

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

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

Quote
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.
http://docs.yoyogames.com

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.

2103
Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: December 02, 2013, 02:16:55 PM »
Quote
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.

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

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

2104
Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: December 01, 2013, 11:34:57 PM »
Quote
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.

Quote
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.
https://github.com/RobertBColton/enigma-dev/commit/5e71f562812588712aae58d20ed1278d4646222e

Quote
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_set_color(c_blue);
        draw_text(xx, yy, "A");
    }



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

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

2106
Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: December 01, 2013, 03:28:59 PM »
Quote
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?

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

http://enigma-dev.org/docs/Wiki/Vertex_Functions

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

https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Bridges/General/DX9Context.h
https://github.com/enigma-dev/enigma-dev/blob/master/ENIGMAsystem/SHELL/Bridges/General/GL3Context.h

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

2107
Developing ENIGMA / Re: GameMaker: Studio is EXTREMELY slow...
« on: November 30, 2013, 11:24:09 PM »
Quote
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.

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

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

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

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

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.
http://enigma-dev.org/docs/Wiki/Unimplemented#Other

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

2108
stop smokin crack poly

2109
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...
https://github.com/RobertBColton/enigma-dev/blob/master/ENIGMAsystem/SHELL/Graphics_Systems/General/GSsprite.cpp

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.

2110
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.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb206331%28v=vs.85%29.aspx

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));
draw_set_alpha(random(100)/100);

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.

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

2112
Issues Help Desk / Re: LateralGM crashing on OpenJDK on Trisquel
« on: November 28, 2013, 11:10:49 PM »
Quote
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

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

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

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

Quote
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()

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

2115
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 :(