GL3 changes from immediate to retained mode

[TheExDeus]

Million works fine. 1.2mill and over broke on my machine.

Also, why is Rober's git commits showing in the future? It showed me it is 7 of august and all my newer commits are behind him in 6th. Is it because his clock is wrong or something? Because I have problems with 1 hour offsets in almost every program while system time is correct. Cannot figure that shit out.

[Josh @ Dreamland]

It may be, or it may be a timezone thing. I'm not certain. I know GitHub has had problems with time zones in the past, but I'm not sure as to why.

Anyway, 1.2 million instances seems like relatively few to be giving you such severe problems. How much memory is ENIGMA using before the collapse? If it's using like 2GB, then I have good news and bad news. The good news is, that's the maximum addressable space for a 32-bit program (which all ENIGMA games are on Windows). The bad news is that 1.2 million objects are using 2GB of RAM. What the fuck?

If it's not using 2GB of memory, then I have good news and bad news. The bad news is, something's terribly wrong with ENIGMA's instance system (which cheesewad has been hinting at in his other topic). The good news is, it's not using that much RAM.

Let me know which scenario we're looking at.

[Goombert]

Also, why is Rober's git commits showing in the future?

I live Pennsylvania, today is August 9th 2013 at 8:51 P.M.

[TheExDeus]

Let me know which scenario we're looking at.

Right now I cannot test on my home PC (on which the original number was based), but on my laptop I get about 960mb of ram filled with 1mil. objects. If I do drawing (especially GL3 which has batching) I get up to 1.1gig. With 1.2mil. it takes about 1.15gig and with drawing it goes up to 1.4gb. But my previous test also used a simple logic as well which could increase the size. Also, I don't think it crashes only when going pass the 2gb mark as reallocation can fail way before that.

So basically right now 1 instance takes quite an amount. On VBO side (which also takes like 300mb with 1.2mil. quads) I could just set an upper limit and then make it draw before batching is done. Normally you wouldn't draw 1mil. things on the screen at once and even if you do, then normally you wouldn't be able to batch all of them. The same with instances though. So while it would be nice to show an error or something (at least in debug), I don't think any real change is needed.

I live Pennsylvania, today is August 9th 2013 at 8:51 P.M.

If only the ordering is changed, then I am alright (although it still could be pain in the ass when needing to revert). I just feared for one minute that the changes are also done in reverse and that would fubar everything.

[Josh @ Dreamland]

Pause. Are you storing the batching info in each instance?

[TheExDeus]

No, I store it in a global VBO. I don't do anything with instances at all. It's the drawing functions which just populate the global vector and then are rendered.

[Josh @ Dreamland]

Then how's that memory usage getting so big? You don't use one giant fixed size, do you?

[TheExDeus]

If you are talking about 1.15gb, then it is without drawing. That size is just instances, so VBO isn't the problem. The VBO takes 250mb for 1.2mil. sprites which is ok considering it takes 4 vertices per sprite and 8 attributes per vertex (all of them float), as well as 6 indices per sprites (int's).
And no, it is not fixed size. It grows depending on what you draw (every time it's too small and has to resize, I resize it so it fits 5 more sprites), but I don't downsize it right now (which doesn't matter in the batching tests).