#gemrb@irc.freenode.net logs for 9 Apr 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:23:06] --- ermo is now known as ermo^
[00:30:46] --- ermo^ is now known as ermo
[00:31:18] --> brada has joined #gemrb
[00:32:35] --- ermo is now known as ermo^
[01:23:35] <-- edheldil has left IRC (Ping timeout: 255 seconds)
[01:25:40] --> jun has joined #gemrb
[01:26:38] <jun> running gemrb 0.7.2 build from April 7 (github)
[01:27:00] <jun> I'm BG2 Book of Kaza quest
[01:27:28] <jun> but when we reach the looted tomb, Korgan doesn't update the quest log with the next part of the quest
[01:27:42] <jun> workarounds?
[01:27:43] <tomprince> 0.7.2 is fairly old.
[01:27:50] <tomprince> I'd try a new build.
[01:28:07] <jun> I'm using gemrb-git from AUR (arch linux)
[01:28:10] <tomprince> Well, not necesairly old, but there's been a bunch of work since.
[01:30:21] <jun> maybe I misstated the version number...
[01:30:36] <jun> I downloaded newest version from git://github.com/gemrb/gemrb.git
[01:31:02] <jun> two days ago... so should be build 20130407
[01:31:20] <jun> 0.7.2 was the version of the original version I installed from the AUR
[01:33:59] <tomprince> In that case it might be a real bug.
[01:34:13] <tomprince> I'm not sure what the preferred tracker is. I think the wiki, or here.
[01:37:11] <jun> should I make a new entry on the wiki? Do you have a URL for BG2-specific bugs?
[01:38:56] <jun> perhaps this URL? http://www.gemrb.org/wiki/doku.php?id=developers:bugs:soa_playthrough_bugs
[01:43:43] <jun> looking through /usr/share/doc/gemrb/en/CheatKeys.txt for a way to trigger the script, but don't see anything I could use
[02:20:12] <-- jun has left IRC (Quit: Page closed)
[02:51:01] --> jun has joined #gemrb
[02:51:33] <jun> same person from earlier, running build 20130407 from github...
[02:52:14] <jun> BG2: verified that quest in Southern Dungeons for Korgan (book of Kaza) doesn't fire
[02:52:36] <jun> but Edwin's quest for the Nether Scroll works properly in the Southern Dungeons area
[03:05:21] <jun> When I went to Pimlico's estate in the Temple District however, the animation script for pimlico's death played properly.
[03:05:34] <jun> However Korgan dialogue script didn't fire again.
[03:06:38] <jun> I get the CLI error message: [GameScript/ERROR]: Actionoverride failed for object:
[03:07:08] <jun> [GameScript/DEBUG]: Object: korpimg1
[03:21:36] <jun> Finally, if you head back to the slum district above the Copper Coronet, the final showdown with the people who have the Book of Kaza takes place
[03:21:53] <jun> again, no Korgan dialogue scripts fire
[03:22:05] <jun> but you can still kill the enemies and get the Book of Kaza
[03:22:19] <jun> however, no quest experience is awarded
[03:22:29] <jun> and the quest isn't removed from your quest log
[03:26:08] <jun> CORRECTION-- the Book of Kaza quest is removed from the 'active quests' log, but is not added to the 'Done Quests' log
[03:26:39] <jun> hope everyone sees this bug report in the IRC archives for #gemrb
[03:27:40] <-- jun has left IRC (Quit: Page closed)
[05:05:19] <-- brada has left IRC (Quit: brada)
[07:04:34] --> WingedHussar has joined #gemrb
[07:14:35] --> edheldil has joined #gemrb
[07:14:35] --- ChanServ gives channel operator status to edheldil
[07:15:50] --> lynxlynxlynx has joined #gemrb
[07:15:50] <-- lynxlynxlynx has left IRC (Changing host)
[07:15:50] --> lynxlynxlynx has joined #gemrb
[07:15:50] --- ChanServ gives channel operator status to lynxlynxlynx
[07:39:20] <-- edheldil has left IRC (Ping timeout: 255 seconds)
[07:52:45] --> edheldil has joined #gemrb
[07:52:45] --- ChanServ gives channel operator status to edheldil
[09:14:00] <-- edheldil has left IRC (Ping timeout: 264 seconds)
[10:17:15] --- ermo^ is now known as ermo
[10:51:54] --- ermo is now known as ermo^
[10:59:45] <-- GoGi has left IRC (Ping timeout: 240 seconds)
[11:01:53] --> GoGi has joined #gemrb
[12:58:54] --> Seniorita has joined #gemrb
[14:13:24] --> brada has joined #gemrb
[14:15:46] <brada> psch: any time to try a new android build?
[14:16:09] <psch> i was building just now
[14:16:21] <psch> but somehow my computer is running less stable since i migrated to systemd
[14:16:25] <psch> soo, i'm building again
[14:16:42] <psch> maybe 15 minutes or so until i can test
[14:25:31] <brada> i will be disapointed by anything less than a 2x performance boost :D
[14:25:48] <brada> (I actually have no idea what boost, if any, to expect)
[14:31:57] <psch> F/libc (13875): jni/src/main/gemrb/plugins/SDLVideo/SDL20Video.cpp:296: virtual int GemRB::SDL20VideoDriver::SwapBuffers(): assertion "pitch == backBuf->pitch" failed
[14:32:23] <psch> happens after the intro videos
[14:32:27] <psch> can't report any fps :/
[14:32:34] <brada> yeah i know
[14:33:07] <brada> let me get you a log statement to add before that assert
[14:33:22] <brada> dow you have a build env that doesnt have to rebuild everything yet?
[14:33:57] <psch> yeah
[14:34:02] <psch> im only rebuilding sdl and freetype
[14:34:22] <psch> i could probably pull freetype out somehow, but i'm not sure how
[14:34:33] <psch> in any case, that's how it is in the repo
[14:36:16] <brada> you shouldnt need to rebuild anything but gemrb ideally
[14:40:00] <psch> yes, i know
[14:40:49] <fuzzie> that assert seems bad :P
[14:41:22] <brada> why?
[14:41:26] <brada> psch: http://paste.debian.net/248481/
[14:41:31] <Seniorita> debian Pastezone
[14:41:33] <fuzzie> because you can't just assume the pitch is the same
[14:41:42] <brada> why?
[14:41:43] <fuzzie> backBuf is a rgbsurface so you'll always get a pitch equal to width
[14:41:49] <brada> i mean obviously you are right
[14:41:51] <brada> but why?
[14:41:53] <fuzzie> while the texture is a texture
[14:41:58] <fuzzie> so the pitch is out of your control
[14:42:29] <brada> but the transfer format is diffrent then the texture format
[14:44:06] <brada> it psch comes back and says they are the same format then yes ill just have to rewrite that to account for pitch diffrential
[14:44:08] <fuzzie> .. yes?
[14:44:22] <fuzzie> i mean, i guess i should ask: why do you think they should be the same?
[14:44:31] <brada> the sam pitch?
[14:44:33] <brada> nothing
[14:44:39] <brada> but that memcpy assumes it
[14:44:49] <brada> and if they are diffrent then i wanted to know
[14:45:27] <fuzzie> well, you might well hit some 16bpp/32bpp difference instead
[14:45:41] <fuzzie> just seems like there's no guarantee that the pitch is the same, so it's a bad idea anyway
[14:45:41] <brada> could be
[14:45:47] <brada> yeah im aware
[14:45:56] <fuzzie> we hit this before somewhere
[14:45:59] <brada> but i would rather assert and fail then corrupt things
[14:46:11] <fuzzie> i mean, someone memcpy()ing in video code rather than copying line by line
[14:46:25] <psch> I/GemRB (14140): [SDL2/]: texFmt:SDL_PIXELFORMAT_ARGB8888, backBufFmt:SDL_PIXELFORMAT_RGB565
[14:46:30] <psch> this is what you wanted right?
[14:46:40] <brada> so yes like fuzzie said
[14:46:44] <brada> 32 -> 16
[14:47:04] <wjp> and even with the same format the pitches may be different
[14:47:13] <brada> so the transfer format is always ARGB8888 it seems
[14:47:19] <brada> wjp: i am aware
[14:47:38] <brada> i do in fact know what pitch is
[14:47:47] <brada> like i ssaid its only there because that code assumes it
[14:47:58] <brada> i was hoping to get performance feedback before finishing it
[14:48:01] <fuzzie> well we're confused as to why you'd memcpy() the whole thing rather than just doing it sensibly :-)
[14:48:16] <brada> because i dont actually know it will be faster
[14:48:35] <fuzzie> strange how SDL gives you an 8888 texture though
[14:48:41] <fuzzie> that seems pretty ba
[14:48:42] <fuzzie> d
[14:48:47] <brada> like i said thats not the texture format
[14:48:51] <fuzzie> it is really though
[14:48:54] <brada> that is the transfer format
[14:48:57] <brada> no its no
[14:48:58] <brada> not
[14:49:02] <brada> read the sdl docs
[14:49:07] <fuzzie> well, if it isn't equal to the texture format, that is very dumb.
[14:49:22] <fuzzie> and I can't find anything at all in the sdl docs about it.
[14:49:29] <wjp> one conversion for the price of two?
[14:50:00] <brada> fuzzie: http://wiki.libsdl.org/moin.fcg/SDL_QueryTexture
[14:50:05] <Seniorita> SDL_QueryTexture - SDL Wiki
[14:50:11] <fuzzie> brada: yes, where's the docs?
[14:50:25] <brada> that is the sdl docs, no?
[14:50:50] <fuzzie> well
[14:50:58] <fuzzie> for me there's nothing useful under 'Remarks'
[14:51:07] <brada> the format variable
[14:51:09] <fuzzie> and nothing contradicting my point otherwise.
[14:51:20] <brada> a pointer filled in with the raw format of the texture; the actual format may differ, but pixel transfers will use this format
[14:51:23] <fuzzie> yes
[14:51:29] <fuzzie> i.e. it's the texture format.
[14:51:38] <brada> ?
[14:51:48] <fuzzie> what there says that it's not the texture format?
[14:52:54] <brada> the part that takes me several times reading it to see what it is saying
[14:53:02] <fuzzie> i mean, it's just not very informative
[14:53:10] <wjp> "raw format" vs "actual format" is not the clearest terminology
[14:53:14] <brada> right
[14:53:17] <brada> confused me
[14:55:38] <fuzzie> so the opengles2 backend accepts any 8888 format, and callocs an internal buffer for STREAMING mode
[14:55:46] <brada> what i want to know is how i can clearly ask for a different pixel format in SDL_CreateTexture and still get something diffrent from the query
[14:56:17] <brada> so openfles2 doesnt accept 16bit?
[14:56:28] <fuzzie> while opengles rejects everything except SDL_PIXELFORMAT_ABGR8888
[14:56:34] <fuzzie> and does the same buffer thing
[14:57:10] <brada> that doesnt make much sense because android didnt require the same pixel format defines that ios did
[14:57:24] <fuzzie> sorry, that is just backends.
[14:57:43] <fuzzie> the SDL_CreateTexture call doesn't pass your format on unchanged.
[14:57:51] <fuzzie> it does GetClosestSupportedFormat on it.
[14:57:52] <brada> i believe you
[14:58:26] <fuzzie> well i'm just reading the code :-)
[14:58:33] <brada> but before yesterday ios had to have defines in SpriteRenderer.inl to convert to ABGR8888
[14:58:43] <brada> android never did
[14:58:47] <brada> so?
[14:58:54] <fuzzie> well I don't know which is which
[14:59:05] <fuzzie> i mean, which backend SDL uses for which platforms
[14:59:16] <brada> both use opengles2
[14:59:22] <brada> well ios does
[14:59:34] <brada> i assumed android did too
[14:59:43] <fuzzie> SDL_CreateTexture stores the *real* texture in texture->native.
[15:00:32] <fuzzie> and allocates yet another buffer in that case. nice.
[15:01:27] <fuzzie> but that means that can't be your problem here
[15:01:44] <fuzzie> because SDL_QueryTexture gives 8888 to psch, right?
[15:01:51] <brada> yes
[15:02:01] <fuzzie> but this is really dumb code. :/
[15:02:38] <fuzzie> so, ok, it is very dumb, and you do indeed get multiple conversions.
[15:02:53] <brada> in SDL i assume?
[15:03:11] <fuzzie> yes
[15:04:12] <brada> I was hoping to avoid multiple conversions :(
[15:04:13] <fuzzie> in the non-8888 case, every time you call SDL_UnlockTexture, SDL will call SDL_ConvertPixels to convert.
[15:05:00] <fuzzie> SDL_PIXELFORMAT_ARGB8888 is the only format supported by opengl backend, SDL_PIXELFORMAT_ABGR8888 is the only format supported by opengles backend.
[15:05:30] <brada> heh thanks for pointing out SDL_ConvertPixels to me tho
[15:05:31] <fuzzie> how do you tell that the format changes in SwapBuffers?
[15:05:43] <brada> i have been doing that myself manually all this time
[15:06:06] <brada> fuzzie: because i do a query after creating the texture and output the format
[15:06:18] <brada> then do another query on the same tex and the format is magically diffrent
[15:06:22] <fuzzie> the SDL code doesn't seem to change the format :/
[15:06:31] <fuzzie> so, that's really weird
[15:06:34] <brada> yes
[15:06:36] <brada> yes it is
[15:06:46] <fuzzie> but I guess you should force 32bpp for SDL2 if you're going to do this
[15:06:53] <brada> probably
[15:06:58] <brada> sounds like it
[15:08:55] <brada> wow could my complex YUV vidoe rendering code really be replaced by a call to SDL_ConvertPixels?
[15:09:08] <fuzzie> can't you just make a YUV texture?
[15:09:12] <brada> i do
[15:09:18] <brada> oh
[15:09:19] <brada> der
[15:09:39] <fuzzie> It looks (at a glance) like SDL accelerates the YUV textures using shaders, so that is better.
[15:09:46] <brada> yeah
[15:10:53] <brada> it is the rgb video code that i am converting
[15:11:36] <fuzzie> aha :)
[15:11:46] <fuzzie> then yes, nice lazy SDL_ConvertPixels sounds sensible
[15:12:39] <brada> im hardly concerned with that atm, however.
[15:14:16] <fuzzie> so what does SDL_GetWindowPixelFormat return?
[15:14:27] <brada> so in summary: force SDL_PIXELFORMAT_ARGB8888 in sdl2
[15:14:41] <brada> and do a sensible pitch conversion
[15:14:52] <brada> and hope that its faster :p
[15:15:04] <brada> fuzzie: is that right?
[15:15:17] <fuzzie> no idea
[15:15:43] <fuzzie> sounds like what I'd try though. the extra hit of forcing 32bpp seems potentially bad.
[15:15:43] <brada> i dont believe you :p
[15:16:01] <brada> but seems like thats what we end up with anyway
[15:16:06] <brada> no?
[15:16:13] <fuzzie> I have no idea!
[15:16:15] <fuzzie> I assume so.
[15:16:27] <fuzzie> which is why I'm wondering what SDL_GetWindowPixelFormat returns on android.
[15:17:28] <brada> rgb565 i thought
[15:17:37] <brada> we went though this a bit ago
[15:17:52] <brada> which makes me sad...
[15:17:54] <brada> actually
[15:18:08] <brada> nevermind
[15:18:25] <brada> yes SDL_PIXELFORMAT_RGB565
[15:18:45] <fuzzie> that is just weird then
[15:18:46] <brada> that is the format of psch's backbuff
[15:19:04] <brada> which is apparently another case of the query texture changing formats...
[15:19:14] <brada> if i can read my own code correctly
[15:19:49] <fuzzie> oh right, the patch you pasted above is in SwapBuffers
[15:19:50] <fuzzie> ugh
[15:20:22] <brada> yes
[15:20:39] <brada> and backbuf is created with the format from the query call in createDisplay
[15:20:44] <brada> so wtf fuzzie!?!?
[15:21:38] <fuzzie> i really don't see anything changing format..
[15:21:41] <fuzzie> so weird
[15:23:23] <brada> I know its not locking/unlocking that does it
[15:23:27] <brada> so rendering?
[15:23:32] <fuzzie> maybe rendercopy?
[15:23:32] <fuzzie> right
[15:24:08] <fuzzie> SDL_RenderCopy only passes texture->native onward anyway though
[15:24:29] <wjp> maybe unrelated, but how does initMovieScreen's change of screenTexture get cancelled?
[15:25:02] <fuzzie> oh, that might be it :P
[15:25:42] <brada> the texture is destroyed and recreated
[15:25:55] <brada> line 98
[15:26:21] <fuzzie> that's in CreateDisplay though
[15:26:29] <brada> oh
[15:26:33] <wjp> that only gets called once
[15:26:36] <fuzzie> InitMovieScreen comes after, and it overwrites your screen with SDL_PIXELFORMAT_ARGB8888, which would explain your bug
[15:26:47] <brada> ha ha
[15:26:48] <fuzzie> also explain why psch gets an 8888 surface
[15:26:54] <brada> yeah
[15:27:01] <brada> hmmm
[15:27:05] <fuzzie> but still, SDL will *fake* the 565 surface so it's still a bad idea
[15:27:26] <fuzzie> i mean, s/surface/texture/
[15:27:28] <fuzzie> wjp: nicely spotted :)
[15:27:30] <brada> yes
[15:27:33] <brada> thanks wjp
[15:29:11] <brada> psch: what happens if you disable movies?
[15:30:04] <brada> we dont get told when movies are done either it seems
[15:30:11] <brada> so how am i supposed to do this?
[15:30:45] <fuzzie> just make a new texture?
[15:31:25] <brada> and keep the video one around forever
[15:31:31] <fuzzie> well also add a function :P
[15:31:36] <brada> yeah
[15:31:42] <brada> trying to figure out how
[15:32:10] <fuzzie> just DestroyMovieScreen() in Video?
[15:32:26] <brada> yeah
[15:32:42] <psch> SkipIntroMovies=1 let's me get into the game just fine
[15:32:51] <brada> cool
[15:33:09] <brada> fps?
[15:34:09] <psch> around 20 ingame with 870x500, around 27 on 640x480
[15:34:22] <brada> vs how many before
[15:34:48] <brada> and what are the formats in you log now?
[15:34:51] <psch> iirc it was 18 on 870x500 before, don't remember 640x480
[15:34:58] <brada> which are probably slowing you down a bit :p
[15:34:58] <psch> I/GemRB (14817): [SDL2/]: texFmt:SDL_PIXELFORMAT_RGB565, backBufFmt:SDL_PIXELFORMAT_RGB565
[15:35:08] <psch> yeah, the log prints probably are
[15:35:37] <fuzzie> android logging is pretty fast, for horrible reasons
[15:35:51] <fuzzie> also you should try it in 32bpp mode
[15:35:59] <brada> good point
[15:37:14] <psch> setting Bpp=32 in my config gives me the same fps and log output
[15:37:29] <brada> yeah cuz it has no effect
[15:37:31] <psch> that might be because we're ignoring that somehow
[15:37:32] <psch> yeah
[15:37:37] <brada> we take the format from the window
[15:38:14] <brada> i should do it another way
[15:38:16] <fuzzie> well, I assume my theory is correct and you get a really pointless conversion in there
[15:38:36] <fuzzie> but 18fps to 20fps seems improved anyway?
[15:39:01] <brada> how many fps if you revert that logging patch?
[15:39:33] <fuzzie> do we log to a file as well?
[15:39:38] <brada> yes
[15:39:54] <fuzzie> native android logging is in-kernel, so not so bad performance hit, but a file is maybe more annoying :)
[15:40:02] <brada> right
[15:41:13] <psch> still around 27 on 640x480
[16:03:28] <psch> no change for 870x500 either
[16:06:02] <brada> we can probably squeeze 1 or 2 more fps out of it
[16:06:55] <brada> i need to implement a better way to determine the format to use
[16:12:21] <fuzzie> or maybe just get sdl upstream to support 565.
[16:13:49] <brada> does ogles2 support that then?
[16:13:54] <fuzzie> yes
[16:13:59] <fuzzie> everything supports that
[16:14:10] <fuzzie> it's almost always the native format on mobile
[16:14:19] <brada> i wonder why nobody (as far as i can tell) has brought that up
[16:14:26] <brada> i follow sdl development pretty close
[16:14:47] <fuzzie> http://hg.libsdl.org/SDL/rev/307ccc9c135e sabotaged it
[16:14:51] <Seniorita> SDL: changeset 5156:307ccc9c135e
[16:15:03] <fuzzie> for "a nice speed boost", which is an interesting way to say "making it much slower"
[16:15:20] <edheldil_> later ...
[16:15:43] <brada> hmmm
[16:15:46] <fuzzie> but that's from before the ogles2 renderer even existed, as you can see
[16:15:48] <-- Drakkar has left IRC (Ping timeout: 264 seconds)
[16:16:48] <brada> i think what he is saying is that the formats the renderers suppor now are actually native to the renderer
[16:16:55] <brada> which gives a speed boost
[16:16:57] <fuzzie> that's not true, though
[16:17:09] <brada> how do you know
[16:17:16] <fuzzie> because you can see the code right there? :P
[16:17:18] <brada> we arent checking what the renderer supports
[16:17:37] <fuzzie> previously the direct3d, opengl and opengles backends were all just passing it onto the relevant API
[16:19:29] <fuzzie> and certainly for opengles there's no chance of that being faster. neither for direct3d/opengl for the other 32bpp modes at least.
[16:19:41] <fuzzie> honestly I expect it was mostly about software mode.
[16:20:31] --> Drakkar has joined #gemrb
[16:20:45] <fuzzie> but SDL_ConvertPixels is almost always going to be slower than the driver code anyway, so I really don't get it.
[16:21:42] <brada> file a bug report :D
[16:22:08] <fuzzie> shan't
[16:22:19] <brada> how come
[16:22:34] <fuzzie> because the bugtracker is full of broken unfixed stuff
[16:22:59] <fuzzie> posting to the mailing list asking *why* it happened seems like it'd be a much more productive approach
[16:23:12] <brada> oh well do that
[16:23:47] <brada> i just want you to articulate what you are saying to them rather than me try to regurgitate it :D
[16:59:16] --> edheldil has joined #gemrb
[16:59:16] --- ChanServ gives channel operator status to edheldil
[17:05:26] <-- edheldil has left IRC (Ping timeout: 245 seconds)
[17:09:55] <brada> psch: wanna try both 16bpp and 32 with that?
[17:10:28] <brada> probably apply that log patch too
[17:13:22] <psch> sure
[17:18:14] <gembot> build #537 of cmake clang++ is complete: Failure [4failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/537 blamelist: Brad Allred <bradallred@me.com>
[17:19:10] <psch> im getting ~26fps on 32bpp 870x500, but the colors are off, no fps change for 16bpp
[17:19:14] <psch> i.e. still around 20
[17:19:31] <brada> yeah i know about the colors
[17:19:41] <brada> jsut looking for fps here
[17:20:07] <brada> what about 640x480?
[17:20:12] <brada> can you finally break 30?
[17:21:09] <brada> btw to temporarily fix the colors you can probably add || ANDROID to that #if at the top of SpriteRenderer.inl
[17:21:18] <brada> probably is a better way
[17:21:30] <psch> close to 30, yeah, not over though
[17:21:33] <brada> such as killing that #if and selecting a format with more parameters
[17:21:37] <psch> hovering around 28.3 to 29.0
[17:21:43] <brada> but significantly better tho right?
[17:22:17] <psch> yeah
[17:22:18] <brada> what about compared to pelyas?
[17:22:20] <gembot> build #537 of cmake g++-4.2 is complete: Failure [4failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.2/builds/537 blamelist: Brad Allred <bradallred@me.com>
[17:26:16] <gembot> build #537 of cmake g++-4.4 is complete: Failure [4failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4/builds/537 blamelist: Brad Allred <bradallred@me.com>
[17:26:33] <psch> don't have a working compile around anymore, i can test the market version though
[17:27:04] <psch> otherwise i'd have to put some time into getting it to compile again - i think i was messing quite a bit with it to build it against HEAD sdl2
[17:28:41] <brada> you can build it against sdl2
[17:28:45] <brada> nor do i want you too
[17:28:47] <brada> to
[17:29:00] <lynxlynxlynx> brada: you could use break instead of goto for doneFormat there
[17:29:02] <brada> im interested in comparing performace so the market build will be fine
[17:29:08] <lynxlynxlynx> *sdl1
[17:29:08] <brada> lynx: how?
[17:29:17] <brada> c++ doesnt support multiple breaks
[17:29:24] <brada> ie break 2
[17:29:44] <brada> single break will break from switch only
[17:29:48] <lynxlynxlynx> oh, it's the same keyword hah
[17:30:02] <lynxlynxlynx> even sh can handle that
[17:30:18] <brada> seems to be limited to scripting languages as far as ive seen it
[17:30:38] <lynxlynxlynx> could be it's fixed in c0+
[17:30:42] <brada> perhapps
[17:30:54] <lynxlynxlynx> anyway, you could use an if statement instead here just as nicely
[17:30:59] <brada> sure
[17:31:28] <brada> probably should find out how min test got broken
[17:31:39] <brada> it was working not too long ago
[17:31:47] <brada> but our buildbot has been gone for so long :p
[17:33:00] <lynxlynxlynx> it's the same error i get
[17:33:18] <brada> sure I jsut dont know what changes have been done that would affect it
[17:33:43] <brada> nothing with fonts has changes since it last worked afict
[17:33:50] <lynxlynxlynx> yeah, the ttf stuff was a while ago
[17:34:21] <brada> ah
[17:34:29] <brada> the fonts.2da didnt get updated
[17:34:54] <brada> but the tests were working since that ttf stuff
[17:35:02] <brada> or buildbot never reported them broken
[17:35:21] <gembot> build #521 of cmake g++-4.5 is complete: Failure [4failed minimal test] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5/builds/521 blamelist: Brad Allred <bradallred@me.com>
[17:35:51] <psch> market build doesn't look good with the game data i have right now, but it's a few fps faster, hovering around 30.2 or so fps
[17:36:18] <lynxlynxlynx> i see the bug actually
[17:36:26] <psch> wrt "doesn't look good", im getting a 640x480 box in the middle surrounded by black, i guess that's widescreen at 870x500 versus 640x480 in the .cfg
[17:36:38] <psch> disregard that, i have 870x500 in my cfg
[17:36:54] <psch> well, rendering problems with pelya dont really matter i suppose
[17:37:06] <lynxlynxlynx> when you changed the config handling and added a nice linux default for the custom ttf path, you didn't change this check on init that only checks if that path is set
[17:41:21] <brada> ah
[17:42:22] <brada> pash: yeah considering with pelyas you have to go 16bpp to get 30 fps and you get near that with 32bpp with sdl 2 i think we call that a win
[17:42:28] <brada> PSCH RATHER :D
[17:43:53] <lynxlynxlynx> http://sprunge.us/JajT?diff
[17:44:37] <brada> if it works ship it!
[17:44:39] <brada> :D
[17:44:41] <brada> thanks
[17:44:45] <lynxlynxlynx> i see you did something else
[17:45:31] <brada> no
[17:45:45] <brada> that was just updating the fonts.2da that is apparently no necissary
[17:46:04] <lynxlynxlynx> still, i'm retrying
[17:46:39] <gembot> build #538 of cmake clang++ is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20clang%2B%2B/builds/538
[17:47:42] <lynxlynxlynx> yeah, your change is enough
[17:50:10] <brada> cool
[17:50:42] <gembot> build #538 of cmake g++-4.2 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.2/builds/538
[17:53:53] <brada> fuzzie: so considering faster performance with 32bpp should we force that?
[17:54:14] <brada> and in fact force a specific format
[17:54:22] <brada> like rgba8888
[17:55:22] <gembot> build #538 of cmake g++-4.4 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.4/builds/538
[17:56:38] <brada> psch: what does the log output as the formats?
[17:57:21] <gembot> build #381 of nmake-msvc++10 is complete: Failure [4failed minimal test] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B10/builds/381 blamelist: Brad Allred <bradallred@me.com>
[18:00:34] <psch> I/GemRB (21692): [SDL2/]: texFmt:SDL_PIXELFORMAT_ABGR8888, backBufFmt:SDL_PIXELFORMAT_BGR888
[18:00:37] <psch> that's 32bpp
[18:03:28] <brada> so you also get ABGR. meaning my fix above will work for your colors
[18:04:33] <gembot> build #522 of cmake g++-4.5 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/cmake%20g%2B%2B-4.5/builds/522
[18:05:08] <psch> sounds good
[18:06:47] <brada> fuzzie/wjp: i have a dilemma
[18:07:12] <brada> looks like for sdl2 android needs the same settings in SpriteRenderer.inl as iOS
[18:07:39] <brada> obviously taht will break the pelya build
[18:08:40] <wjp> what is the pelya build?
[18:09:26] <brada> the sdl 1.2 build we dont do ourselves
[18:09:37] <brada> but it has a usefull configuration interface
[18:09:41] <brada> which we lack
[18:09:53] <brada> unless psch added something im unaware of
[18:10:55] --> Yoshimo has joined #gemrb
[18:12:08] <wjp> hm, make it SDL version dependent? Unhardcode it and turn it into a run-time selectable template?
[18:13:55] <brada> second sounds better
[18:14:14] <brada> not sure how to go about that :D
[18:14:40] <brada> we could also force an RGB format texture
[18:14:46] <brada> but that raises 2 things
[18:14:56] <brada> 1. will performance be impaired
[18:15:15] <brada> and 2. we then need to do a more sensible pixel copy ;)
[18:23:57] <brada> that ought to serve for now
[18:24:06] <brada> but i still prefer this to be dynamic
[18:24:29] <brada> then again getting a proper sdl2/ogl renderer would be better
[18:24:50] <brada> psch: does that fix the colors?
[18:25:50] <brada> might need that commit too
[18:31:07] <brada> you can rever that logging change for more performance too assuming your colors afre fixed
[18:36:33] <brada> psch: btw we hard cap fps at 30
[18:36:46] <brada> so i fluctuate between 29-30 on all my devices anyway
[18:37:04] <brada> so you will never be able to break 30 not that it matters
[18:38:27] <brada> 26 fps 32bpp at 870x500 on android isnt bad imo
[18:38:36] <brada> question is was that jsut on the menu?
[18:38:53] <brada> or does it get pretty much the same ingame too?
[18:55:38] --- ermo^ is now known as ermo
[19:05:32] <fuzzie> brada: well also the pelya build doesn't have broken stuff like forcing slow 32bpp modes :/
[19:06:05] <brada> well fps is comparable on this at 32bpp to his at 16
[19:06:14] <fuzzie> that's going to be hw-specific though
[19:06:14] <brada> so not a huge deal
[19:06:41] <brada> true
[19:06:52] <brada> but until sdl lets us use 16bpp
[19:06:55] <fuzzie> but i mean i don't care
[19:07:01] <fuzzie> you know my opinion of all sdl on android :P
[19:07:06] <brada> yes
[19:07:17] <brada> tho this affects more than android :/
[19:07:22] <fuzzie> and if i had the patience i'd really just write a native android backend
[19:07:32] <fuzzie> since it would be way less work than dealing with all this broken SDL stuff at this point
[19:07:58] <gembot> build #382 of nmake-msvc++10 is complete: Success [3build successful] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B10/builds/382
[19:08:21] <fuzzie> i suspect that really a native iOS backend might be easier on your side too
[19:08:30] <fuzzie> but, alas, both would depend on us writing at least some opengl support..
[19:08:52] <brada> well ios gets 30 fps anyway
[19:09:04] <brada> tho thats not a reason not to make a better one :D
[19:09:07] <fuzzie> yeah, but I care about battery life :)
[19:09:16] <brada> exactly
[19:09:17] <fuzzie> and I assume it chews through cpu to manage that
[19:09:21] <fuzzie> anyway sorry I'm just rambling
[19:09:24] <brada> no doubt
[19:09:28] <fuzzie> I don't even manage to keep iOS/android backends working for simpler projects.
[19:09:37] <fuzzie> terrible timesinks.
[19:09:52] <fuzzie> and SDL2 backend is more than we'd hoped for.
[19:09:57] <brada> thats what sdl was supposed to be for i thought :D
[19:10:18] <fuzzie> yeah, well, I don't know about SDL on iOS
[19:10:30] <fuzzie> but you don't really make it sound too much better :)
[19:10:38] <brada> its not
[19:11:00] <brada> it forces a bgr texture format too
[19:11:01] <fuzzie> i should ask about the 16bpp thing though.
[19:11:24] <brada> please do
[19:12:41] <fuzzie> and, well, swapping bytes is at least not too bad performance-wise :)
[19:12:54] <brada> no
[19:13:12] <fuzzie> but your changes are all working fine now, right?
[19:13:17] <brada> yes
[19:13:19] <fuzzie> so, victory for you
[19:13:22] <fuzzie> very nice :)
[19:13:27] <brada> havend heard from psch
[19:13:35] <brada> but on ios :p
[19:14:46] <brada> but probably ought to rewrite the format selection to jsut hardcode the 32bpp bgr format that ios and android seem to be locked to
[19:15:05] <brada> worry about other platforms after we have a more proper renderer
[19:15:11] <brada> which i WILL do at some point
[19:15:25] <brada> but first still need to rewrite iOS config interface
[19:15:33] <brada> and polish the mac one
[19:18:51] --> edheldil has joined #gemrb
[19:18:51] --- ChanServ gives channel operator status to edheldil
[19:19:35] <brada> fuzzie: ryan from SDL actually posted some code on opengl textures as palettes recently
[19:29:52] <psch> sorry, i got distracted for a bit
[19:29:59] <psch> the fps i reported were all ingame
[19:30:06] <psch> didn't recompile with color fix yet
[19:35:16] <-- edheldil has left IRC (Read error: Operation timed out)
[19:36:05] <psch> colors look good too
[19:36:11] <brada> yay
[19:36:26] <psch> movement on the main screen drops fps quite a bit i just noticed
[19:36:45] <psch> as in, moving the whole party around sometimes drops me down to ~18 fps
[19:37:05] <psch> but that might be fog of war getting revealed
[19:37:06] <brada> did it not do that before?
[19:37:11] <psch> i don't remember tbh
[19:37:16] <brada> because i didnt change anything
[19:37:23] <brada> other than rendering
[19:37:31] <psch> actually, fog of war seems unlikely, could be path finding i guess?
[19:37:35] <brada> yeah
[19:38:08] <brada> unfortunate that we have to update the entire screen each frame
[19:38:15] <lynxlynxlynx> fog of war is expensive, especially the full one
[19:38:29] <lynxlynxlynx> forgot what the switch was
[19:38:31] <wjp> yup, software alpha...
[19:39:49] <brada> anyway we should probably post a build for download
[19:39:55] <brada> since its markedly faster
[19:40:43] <brada> I probably ought to hardcode that pxformat tho
[19:40:52] <brada> otherwise people with 16bpp settings will suffer
[20:21:08] <-- Yoshimo has left IRC (Quit: Yoshimo)
[20:44:46] --> Maighstir has joined #gemrb
[21:03:44] <-- xrogaan_ has left IRC (Ping timeout: 246 seconds)
[21:05:45] --> xrogaan has joined #gemrb
[21:06:01] --> vampi-the-frog has joined #gemrb
[21:17:50] <-- nutron has left IRC (Quit: I must go eat my cheese!)
[21:18:30] --> nutron has joined #gemrb
[21:30:36] <-- vampi-the-frog has left IRC (Quit: Leaving)
[21:44:27] <-- brada has left IRC (Quit: brada)
[21:45:31] --> brada has joined #gemrb
[21:48:19] --> edheldil has joined #gemrb
[21:48:19] --- ChanServ gives channel operator status to edheldil
[21:57:25] <-- brada has left IRC (Quit: brada)
[22:35:55] <-- edheldil has left IRC (Ping timeout: 264 seconds)
[22:42:28] <-- Maighstir has left IRC (Quit: .)
[22:54:50] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:03:23] --- ermo is now known as ermo^