graphics refactor 3

[vieiraa]

You should change the variable name __pad in resources/shaders/basic.frag. I'm getting this error when trying to launch any app: Shader compile error: 0(12) : error C7528: OpenGL reserves names containing '__' (double underscore).

[wheybags]

@vieiraa ah thanks, will fix

[grantramsay]

@wheybags I like what you've done, but the latest commit takes ~60 seconds to load and GUI graphics are broken on my mac. I had similar issues earlier when using lots of graphics memory. This might come right after you order the textures by size, but it'll still be a long loading time.. Are you sure this is the right approach?

[wheybags]

This branch is WIP, I won't merge it until the issues are fixed. I'm pretty sure this approach will work out in the end, as I said before, factorio uses this approach, and there is much more data to load there. As for the broken graphics, is there any chance you could do a capture with apitrace and email me a dump of your sprite atlas? It looks like the loading code is messing up somehow. (I guess it could be the gui shader too). My email is wheybags@wheybags.com. To get a dump, start the program through apitrace + get in game, then quit. Apitrace will load a big list of gl calls, just go to one of the frames, and find a glDrawArraysInstanced call, and double click it. It will then load for a while, and after you'll be able to inspect the GL state at that point, including bound textures.

[wheybags]

New rect packing algo is waaay better:

[grantramsay]

@wheybags - all good, I understand it's wip. I emailed you the apitrace.

Some additional debug, rendering works well if I:

• reduce requiredTextureLayers from 3 to 2
• only load half the monsters so it fits in two layers (atlas texture layer occupancy 98.9%, 82.1%) Then increasing requiredTextureLayers back to 3 breaks the GUI stuff again

[grantramsay]

It looks like the atlas texture gets messed up a little when there's 3 layers: 2 layers:

3 layers:

edit: I've followed through the API trace to one of the first atlas additions that draws in the wrong place and I didn't spot anything different in the calls:

[wheybags]

Hmm, if the calls are the same but the results are different, it seems like it might be a driver bug. Also, btw, I don't have access to the google drive link you sent me :p

I have local work almost ready that switches to using separate textures for atlases, which should work around this. It also sorts the draws by what texture they're using so we can get maximal batching efficiency even when we have a whole bunch of atlas textures. I'm using the z-buffer to make sure the perceived draw order is correct.

Out of curiosity, what model is your mac / what osx version is it running? It might be worth making a minimal repro and submitting a bug report, if we can rule out a bug in freeablo.

[wheybags]

@grantramsay merged this for now, as I expect it to work for you, but do let me know if it isn't working right!

[grantramsay]

@wheybags yep this works all good for me, although loading time is ~75 seconds. I think way back you mentioned creating the atlas as a pre-build step, is that still a possibility? A tiny issue is the sprites are trimmed a little tight for the current hover/highlight method (e.g. hover over Farnham).

Out of curiosity, what model is your mac / what osx version is it running?

[wheybags]

Damn, I was hoping the multithreading might take care of that, it takes ~7 seconds on my machine :( I will add in atlas caching asap then.

I think I know what the problem is with highlighting, we just need to extend the square we draw by one pixel. I presume you mean that the outline is missing at his extremeties (eg, on top of his head)?

[grantramsay]

7 seconds! Sounds like I need a new laptop 😂 Yep, just the outline pixels around edge of sprite textures I've been busy with work lately, haven't had much time for this project

[vieiraa]

Seems more like a system problem. I was able to reproduce this in a virtual machine. It took ~40s to load.