#gemrb@irc.freenode.net logs for 15 Aug 2014 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:26:29] <-- edheldil has left IRC (Ping timeout: 260 seconds)
[01:41:54] <-- turtleman_ has left IRC (Ping timeout: 272 seconds)
[02:45:50] --> turtleman_ has joined #gemrb
[03:11:16] <-- Eli2_ has left IRC (Read error: Connection reset by peer)
[03:12:27] --> Eli2_ has joined #gemrb
[05:48:32] --> edheldil has joined #gemrb
[05:48:33] --- ChanServ gives channel operator status to edheldil
[06:47:04] <-- turtleman_ has left IRC (Ping timeout: 240 seconds)
[06:53:20] <-- Lightkey has left IRC (Ping timeout: 250 seconds)
[07:06:08] --> Lightkey has joined #gemrb
[08:09:27] --> Yoshimo has joined #gemrb
[08:09:28] <-- Yoshimo has left IRC (Changing host)
[08:09:28] --> Yoshimo has joined #gemrb
[10:30:06] <-- tomprince has left IRC (Ping timeout: 272 seconds)
[10:33:33] --> tomprince has joined #gemrb
[11:42:47] <-- Guest555 has left IRC (Ping timeout: 246 seconds)
[12:06:44] <-- edheldil has left IRC (Ping timeout: 240 seconds)
[12:23:33] <-- Yoshimo has left IRC (Quit: Yoshimo)
[16:07:52] --> turtleman_ has joined #gemrb
[16:31:39] --> brada has joined #gemrb
[16:47:35] <-- brada has left IRC (Ping timeout: 260 seconds)
[16:54:58] --> brada has joined #gemrb
[16:57:31] <-- brada has left IRC (Read error: Connection reset by peer)
[17:07:53] --> brada has joined #gemrb
[17:41:27] <brada> :/ text drawing is still slow… (tho im hopeful its a simple matter). short circuiting the font rendering with a return string.length(); gives me 1600 fps on the menu; without that i get 250.
[17:44:43] <brada> I assume some per char slowdown even tho the chars are on sheets now.
[17:46:46] <brada> something about binding -> unbinding -> binding -> etc the same texture over and over?
[17:47:35] <-- turtleman_ has left IRC (Quit: Leaving)
[17:49:29] --> edheldil has joined #gemrb
[17:49:30] --- ChanServ gives channel operator status to edheldil
[17:49:39] <fuzzie> again ideally your driver would deal with it
[17:49:48] <fuzzie> how are you short-circuiting the fps thing?
[17:53:27] --> turtleman_ has joined #gemrb
[17:54:04] <brada> you mean the fps cap?
[17:54:19] <brada> the same way beholder was. there is an ifdef atound SDL_wait
[18:04:47] <brada> cutting out the palette program doesnt change the FPS significantly either so not likely an issue with plaettes i guess
[18:06:18] <brada> it has to be a factor of the number of calls to GLBlitSprite. i dont see any other possibility.
[18:07:27] <-- edheldil has left IRC (Ping timeout: 244 seconds)
[18:23:43] <brada> im not sure, but i also think thigns would be a lot faster if we rendered to a texture as a backbffer instead of directly to screen. that way we wouldnt have to have core->RedrawAll() every frame...
[18:38:34] <brada> on the plus side, I use about 10% less CPU with opengl compared to plain SDL2, and the cursors and tooltips arent horribly broken so overall its a win i guess…
[18:41:32] <fuzzie> you have to redraw the game area anyway
[18:41:51] <fuzzie> which limits the gain from trying to cache windows
[18:42:30] <brada> fuzzie: true, but i mean with text still for some reason being expensive to draw
[18:42:42] <brada> if that problem goes away then meh i guess
[18:43:13] <fuzzie> so what are you testing here
[18:43:14] <fuzzie> bg2 menu?
[18:43:18] <fuzzie> 800x600?
[18:43:53] <fuzzie> *which* menu?
[18:45:41] <brada> jsut the main menu
[18:45:52] <brada> and yes, 800x600
[18:47:27] <fuzzie> the SoA vs ToB one?
[18:51:18] <brada> oh, its ToB
[18:51:51] <fuzzie> but yes my profile here also blames the insane number of gl calls there
[18:54:32] <fuzzie> just the overhead in repeatedly uploading a buffer for every single rect can't help
[18:55:13] <brada> so what should be done?
[18:55:21] <fuzzie> batch these draws
[18:55:41] <fuzzie> I mean, step one, don't use glViewport/glScissor for this ;)
[18:55:55] <brada> yes… so stuff over my head :p
[18:56:10] <fuzzie> it was simple to do how it was, I thought
[18:56:36] <brada> it always used scissor/viewport in every case before too
[18:56:44] <fuzzie> yes, that's not the issue
[18:56:51] <fuzzie> the problem is that the scissor/viewport needs to cover the whole draw
[18:56:59] <fuzzie> I mean, as a first step to batching it
[18:57:19] --> edheldil has joined #gemrb
[18:57:19] --- ChanServ gives channel operator status to edheldil
[18:59:01] <fuzzie> then just add an API which adds a src/dest rect to a list (the 2D backend can just immediately do the blit), and one which executes those queued draws in one single API call
[18:59:10] <fuzzie> that should be simple to call from the font side, right?
[18:59:47] <brada> i suppose.
[18:59:55] <fuzzie> so this is a 'simple' way to deal with it
[19:01:24] <fuzzie> then either do an index buffer or just duplicate the vertices and do a single glDrawArrays(GL_TRIANGLES) call
[19:04:08] <fuzzie> or alternatively just cache the windows but ugh that sounds very complicated.
[20:00:32] <-- turtleman_ has left IRC (Ping timeout: 272 seconds)
[20:06:59] <brada> I’m still curious if this text system performs better than the old on OpenGL despite this problem
[20:08:56] <-- edheldil has left IRC (Ping timeout: 250 seconds)
[21:31:08] <brada> so… GLSLProgram doesnt seem to like ES
[21:33:00] <brada> ha ha it is erasing the program source
[21:34:40] <brada> i end up with vertex shader code of nothing but newlines
[21:34:50] <fuzzie> hmm?
[21:35:06] <brada> also infinite loop
[21:36:12] <brada> maybe its not erasing it so much as that fileStream.eof check is bad?
[21:37:10] <brada> bah im confused at how this is happening
[21:37:11] <fuzzie> why only with ES though?
[21:37:46] <brada> i had it working with standard before, but now im trying to get the path to the shaders working
[21:37:49] <brada> so maybe i broke it
[21:37:54] <fuzzie> I mean, it was developed with ES
[21:38:47] <brada> indeed it looks like i broke it, but the path is correct
[21:39:28] <brada> can you not jsut reaopen a filestream like is happening here
[21:40:58] <brada> probably at least have to reset/clear it right?
[21:43:46] <fuzzie> reopening
[21:43:46] <fuzzie> ?
[21:44:17] <brada> the fstream object. it first tries to open a relative path then tries to reopen if that fails.
[21:44:19] <fuzzie> oh, lynx's changes
[21:45:26] <fuzzie> nothing checks any of the other fail bits, I thought
[21:45:55] <fuzzie> otherwise it depends on your compiler, yay?
[21:46:12] <fuzzie> but I'd assume you're using a sensible modern one
[21:46:44] <brada> clang 5 something… but yeah got the file open now
[21:46:52] <brada> but its still broken
[21:47:01] <brada> cant build shader program error
[21:47:10] <fuzzie> do you get the error?
[21:47:28] <brada> call to undeclared function ‘fwidth'
[21:47:46] <fuzzie> oh, that's just the ellipse one though
[21:50:08] <fuzzie> I assume you're using the iOS simulator
[21:50:24] <brada> yes
[21:50:33] <fuzzie> so yeah, no fwidth for you:)
[21:50:38] <brada> :(
[21:50:41] <brada> why?
[21:50:49] <fuzzie> because the simulator is terrible
[21:51:02] <fuzzie> fwidth is totally optional anyway though, so that should be fixed
[21:51:25] <fuzzie> not awake enough to try and decode what madness the ellipse shader is trying to achieve there
[21:51:42] <brada> the rect one doesnt work either
[21:51:55] <fuzzie> oh
[21:51:55] <brada> bypassing those lets it run
[21:51:59] <brada> but its sideways :(
[21:52:04] <fuzzie> what's wrong with the rect one?
[21:52:19] <brada> lemme see
[21:52:58] <brada> vec4 declaration must include a precision qualifier for type
[21:54:34] <fuzzie> ok so you can just stick a precision qualifier in the top
[21:54:36] <fuzzie> but that doesn't matter
[21:54:39] <fuzzie> sideways is cooler
[21:55:25] <fuzzie> is the whole thing sideways?
[21:57:43] <brada> graphically only
[21:57:55] <brada> but yes all the graphics
[21:59:30] <brada> the ellipses dont work anyway do they?
[21:59:36] <brada> on mac they are really messed up
[22:03:36] <fuzzie> they are here also
[22:03:55] <fuzzie> honestly the ellipse code was a stupid hack by me a long long long time ago
[22:04:02] <fuzzie> I mean, the 2D ones
[22:04:07] <fuzzie> probably we should just be using sprites anyway
[22:04:36] <brada> I fixed the fwidth thing
[22:04:49] <brada> (seemingly)
[22:05:18] <brada> #extension GL_OES_standard_derivatives : enable
[22:05:26] <brada> should be harmless to others right?
[22:07:46] <brada> and i hope precision highp float; is fine… still dont understand it he he
[22:09:05] <fuzzie> yeah
[22:10:26] <fuzzie> I mean I'm hardly an expert :)
[22:12:53] <brada> seems to not break on the mac...
[22:13:51] <brada> dont know what to do about the sideways thing
[22:13:58] <brada> oh except i should update SDL
[22:14:08] <brada> been a *long* while
[22:23:15] <brada> well no, that didnt work :p
[22:28:13] <fuzzie> I'm imagining you stepping away from a computer which just burst into flames
[22:30:52] <brada> i think im much more likely to burst into flames...
[23:22:03] <-- brada has left IRC (Quit: brada)
[23:33:13] --> brada has joined #gemrb
[23:58:33] <brada> sideways bit seems to be due to mixing sdl_renderer and opengl improperly