#gemrb@irc.freenode.net logs for 31 Dec 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:22:22] <brada> we maybe ought to just use signed variables for coordinates...
[00:31:20] <-- brada has left IRC (Quit: brada)
[00:55:42] <-- raevol has left IRC (Quit: Leaving.)
[01:20:38] <edheldil> there were gamecontrol refocus issues before brada's patch. GC sometimes lost focus, but I have not found when it happens
[01:31:26] --> brada has joined #gemrb
[01:38:46] <edheldil> brada: there were gamecontrol refocus issues before brada's patch. GC sometimes lost focus, but I have not found when it happens
[01:39:07] <edheldil> s/brada's/your/
[01:39:35] <brada> yeah I already checked out before my changes and determined the same
[01:54:14] <edheldil> nice to see so much activity, reading backlog & commits took me a lot of time today
[02:17:35] <brada> yeah weve been a busy bunch
[02:17:38] <brada> its nice
[02:17:46] <brada> helps get everybody interested again
[02:20:57] --> planetaxxi has joined #gemrb
[02:29:03] <-- planetaxxi has left IRC (Remote host closed the connection)
[03:02:15] <edheldil> good night
[03:07:12] <-- edheldil has left IRC (Ping timeout: 272 seconds)
[04:34:37] <brada> re: GC focus. it only looses focus when using mta
[04:34:43] <brada> traveling normally works
[04:34:58] <brada> so something is different in that code path
[04:43:50] <-- brada has left IRC (Quit: brada)
[08:32:08] --> edheldil has joined #gemrb
[08:32:08] --- ChanServ gives channel operator status to edheldil
[08:54:53] --> Beholder has joined #gemrb
[08:55:02] <Beholder> hi
[09:07:34] --> Yoshimo has joined #gemrb
[09:08:13] <wjp> morning
[09:09:00] <Beholder> about performance
[09:09:08] <Beholder> we need to do some things
[09:09:25] <wjp> I tried this palette shader program here last night, and I think it should either be (0.5+r*255.0)/256.0 or GL_CLAMP
[09:09:52] <Beholder> i added clamp
[09:10:52] <Beholder> gpu is optimised to render big buffers few times, not a small buffers often
[09:11:22] <Beholder> we need generate big textures for each font
[09:11:38] <Beholder> and using VBO for rendering
[09:12:31] <Beholder> all text on control must render one time (not each symbol)
[09:13:00] <Beholder> calls DrawArrays often reduce performance on all hardware
[09:13:40] <Beholder> I write DrawText
[09:14:22] <Beholder> this method we should use instead BlitSprite for text
[09:15:09] <Beholder> for font textures we need to generate hash tables of course
[09:15:26] <Beholder> symbol:coordinates
[09:17:39] <Beholder> with these optimizations I get> 150fps on my hardware, I'm sure
[09:23:10] <fuzzie> the performance is worrying though
[09:23:24] <fuzzie> there's not *that* many glyphs on the screen
[09:23:34] <fuzzie> we'll be rendering just as many bitmaps in-game
[09:24:25] <fuzzie> but brada is busy rewriting the font code so it's silly to try optimising it now, we'll probably have to throw that out..
[09:24:36] <-- Yoshimo has left IRC (Ping timeout: 246 seconds)
[09:24:38] <fuzzie> would really recommend moving onto something that isn't fonts
[09:27:13] <Beholder> Im sure, that using big textures with VBO for rendering text are increase performance dramatically
[09:27:29] <fuzzie> yes
[09:27:39] <fuzzie> but we removed the big textures
[09:27:46] <fuzzie> because the code has to be rewritten first
[09:29:56] <fuzzie> probably soon we'll make one sprite per label, and call DrawSprite on the label instead
[09:31:01] <fuzzie> the font textures aren't easy because they don't work for Japanese/Korean/etc where you have 10,000 symbols..
[09:31:48] <Beholder> i have my own test program, it draws 64x64x2 textured triangles per frame with matrix transformations and lighting and i got a 150fps on my old hardware
[09:32:30] <fuzzie> but one sprite per label would be good enough for you, right?
[09:32:50] <Beholder> right, and one sprite per text area too)
[09:32:58] <fuzzie> that's maybe not so easy
[09:33:01] <fuzzie> I'm not sure
[09:33:07] <fuzzie> the problem with that is, we'd have to render a big 32bpp one
[09:33:19] <fuzzie> because there are multiple palettes in a text area
[09:33:41] <Beholder> hm
[09:34:00] <fuzzie> but we could do either one big sprite, or else one sprite per coloured area
[09:34:23] <fuzzie> this is what brada is working on, anyway
[09:35:26] <Beholder> ok
[09:35:36] <fuzzie> if you think the big font textures are better, then do complain :)
[09:37:05] <Beholder> it will be better, i think
[09:37:30] <fuzzie> just we don't have a plan for how to handle the huge fonts then
[09:42:02] <Beholder> hm, i cant use texture larger than 1024x1024
[09:42:21] <fuzzie> a lot of devices run out of memory pretty quickly then
[09:42:31] <fuzzie> so probably huge textures is not a good idea
[09:43:24] <Beholder> but drawing small portions often is a not a good idea too
[09:43:36] <fuzzie> I had a few ideas: for example you could add new symbols to a texture as they're used, using LRU to replace old ones
[09:45:36] <fuzzie> but .. it gets so complicated to do, so then the 'one sprite per control' makes a lot more sense
[09:45:42] <Beholder> may be, but editing buffers during rendering not a good too
[09:45:58] <Beholder> you are right
[09:46:13] <fuzzie> it is annoying, I really liked the big font texture idea, but I think brada is right :)
[09:49:52] <Beholder> i used this technique in one my old game for symbian, but i don't used a big fonts (no japanese or chinese localization, only latin, cyrillic)
[09:49:56] <fuzzie> probably this is also the easiest way to make the game work: render GameControl into an SDL_Surface and then upload that every frame
[09:50:51] <Beholder> you are right, it will be simpler
[09:51:02] <fuzzie> of course that is horrible :-)
[09:52:22] <Beholder> :)
[09:52:46] <wjp> and you avoid all the fun of writing game sprite effects :-)
[09:53:08] <fuzzie> yes, someday we must write shaders for the game sprite effects, but that will be a lot of wokr..
[09:53:11] <fuzzie> work
[09:53:16] * fuzzie pushes wjp back into the salt mines
[10:00:05] <-- Beholder has left #gemrb
[10:35:04] <edheldil> that "texture per label or textarea" sounds ugly :(
[10:35:55] <edheldil> e.g. we need to have a decent history in TA, so one texture would be rather huge
[10:36:12] <edheldil> and we need to update it on mouseover
[10:37:28] <wjp> not sure if there are better options though
[10:39:43] <edheldil> what's the current slow way Beholder was using?
[10:41:34] <edheldil> having a quad for each letter?
[10:44:10] <fuzzie> having one texture for each letter
[10:45:22] <wjp> or even two?
[10:45:35] <fuzzie> well yes it read as if there was a per-sprite palette too
[10:45:47] <edheldil> and having a big texture for the whole font is not doable because of asian fontrs?
[10:45:51] <edheldil> fonts
[10:46:02] <fuzzie> but: i disabled generate new palettes during rendering [...] this is not a bottleneck
[10:46:37] <fuzzie> edheldil: yes, and maintaining a "glyphs currently in use" texture seems possibly overcomplicated
[10:47:19] <fuzzie> I'm not particularly convinced either way
[10:47:21] <edheldil> and having the font in several textures?
[10:47:30] <fuzzie> would mean you ran out of texture RAM
[10:47:39] <fuzzie> (and doesn't solve the performance problem)
[10:47:55] <edheldil> sigh
[10:48:22] <wjp> it went from 15 to 22 fps with that palette change though, so quite significant
[10:48:34] <edheldil> so if I understand it correctly, we have to render everything offscreen? will it be fast, even?
[10:48:51] <fuzzie> edheldil: well we're just looking at ideas right now?
[10:48:54] <fuzzie> but text is almost universally static
[10:49:18] <edheldil> TA is not though :)
[10:49:19] <fuzzie> probably for textareas we'd only want to render a few lines offscreen
[10:49:32] <fuzzie> so we'd have to re-render when you scroll too far
[10:49:36] <fuzzie> but rendering this stuff is very cheap
[10:49:48] <edheldil> or when you mouseover
[10:50:04] <fuzzie> does the *text* change when you mouseover?
[10:50:16] <edheldil> the color does
[10:50:22] <fuzzie> my own proposal was to render in spans of text
[10:50:28] <fuzzie> each with their own palette
[10:50:32] <fuzzie> so swapping palettes would be easy
[10:50:47] <fuzzie> and it remains a nice simple 8bpp texture that way
[10:51:01] <edheldil> and just redrawing the color changed text?
[10:51:16] <fuzzie> well I thought just draw all the spans every frame
[10:51:33] <fuzzie> no need to actually maintain offscreen buffer of the whole control
[10:51:50] <fuzzie> but again it's probably overengineering to do that
[10:52:08] <edheldil> no, that sounds ok, I think
[10:52:25] <fuzzie> the thing is, the software re-rendering is not a performance problem at all
[10:52:35] <fuzzie> it's just the texture upload which is painful
[10:52:56] <fuzzie> so re-rendering the whole thing on mouseover really shouldn't be a problem
[10:53:24] <fuzzie> but honestly I don't see why the fps is so very bad in Beholder's current case anyway
[10:54:33] <fuzzie> as wjp says it went 15->22fps without palettes, but that's a huuuge gap from the reported >150fps with less text onscreen
[10:55:19] <wjp> it's puzzling
[10:55:30] <wjp> with static text it shouldn't really be re-uploading texture either
[10:56:16] <fuzzie> the driver might well not cope very well with all these tiny textures
[10:56:39] <wjp> could be
[10:57:47] <edheldil> are thetextures power-of-two sized?
[10:59:00] <wjp> could the palette fragment shader be limiting on old hardware?
[10:59:25] <fuzzie> edheldil: not at all :)
[10:59:51] <fuzzie> and the shader is pretty trivial
[11:00:02] <fuzzie> but I don't know Beholder's setup exactly
[11:00:35] <edheldil> I thought the ^2 size requirement was a strong one
[11:00:54] <fuzzie> nope
[11:01:27] <fuzzie> or rather, not any more :)
[11:10:26] <edheldil> that missing break coverity complains about is not a falthrough, right?
[11:10:58] <fuzzie> I thought it was
[11:11:39] <fuzzie> hm
[11:13:22] <fuzzie> no clue, it might make sense either way
[11:15:24] <edheldil> somebody ask Avenger when you see him
[11:20:30] <fuzzie> you have as much a chance as any of us I think
[11:24:43] --> Yoshimo has joined #gemrb
[12:14:12] <-- WingedHussar has left IRC (Ping timeout: 252 seconds)
[12:20:52] --> WingedHussar has joined #gemrb
[12:46:24] --> EVBB-Eugene has joined #gemrb
[13:04:09] --> brada has joined #gemrb
[13:19:09] <-- brada has left IRC (Quit: brada)
[13:28:50] --> brada has joined #gemrb
[13:35:22] <brada> i think rendering spans in textare is the way to go
[13:35:41] <brada> since thats the way the new layout is going to work
[13:36:17] <fuzzie> you could wrap the spans in a class and have them keep the sprite I guess
[13:37:35] <brada> that could work
[13:38:04] <brada> and use the same "span" class for labels and buttons?
[13:38:05] <brada> so they have one text texture?
[13:38:07] <fuzzie> yes
[13:40:34] <brada> no doubt this is going to be harder than it wounds :)
[13:49:32] <brada> on the plus side about using a separate renderer for gamecontrol, it makes it easy to zoom in on just that one area
[13:50:52] <brada> except how do you handle sprites that render to both?
[13:51:15] <brada> i guess they retain their pixel data for that
[13:53:42] <fuzzie> in the long-term it would be silly to implement that way
[14:28:34] <brada> why is that?
[14:29:32] <-- brada has left IRC (*.net *.split)
[14:36:15] --> brada has joined #gemrb
[14:39:45] <fuzzie> brada: you want to hw accelerate the rendering, right?
[14:43:27] <fuzzie> so for zoom you'd want the same rendering code but an on/off switch for targetting a FBO
[14:44:49] <-- WingedHussar has left IRC (Quit: WingedHussar)
[15:05:58] <-- edheldil has left IRC (Ping timeout: 245 seconds)
[15:06:57] <brada> oh you mean that
[15:07:03] <brada> i thought you were talking about text
[15:07:26] <brada> i completely forgot i mentioned that
[15:07:31] <brada> its very early here :(
[15:07:45] <fuzzie> more coffee!!
[15:14:03] <brada> indeed!
[15:41:36] --> Beholder has joined #gemrb
[15:50:15] --> timonmac has joined #gemrb
[15:53:45] <-- Beholder has left IRC (Read error: No route to host)
[15:58:40] --> Beholder has joined #gemrb
[16:01:42] <-- timonmac has left IRC (K-Lined)
[16:50:30] <-- Yoshimo has left IRC (Quit: Yoshimo)
[16:53:06] --> kpederse1 has joined #gemrb
[16:54:52] <brada> we should maybe think about handling the state "fonts" as a special case single spritesheet texture
[16:55:15] <-- kpedersen has left IRC (Ping timeout: 252 seconds)
[17:23:53] --> Yoshimo has joined #gemrb
[17:32:48] <-- Beholder has left IRC (Quit: Beholder)
[18:06:47] <-- Yoshimo has left IRC (Ping timeout: 272 seconds)
[18:27:24] --> Beholder has joined #gemrb
[18:28:28] <fuzzie> brada: can't it be integrated with the rest of this code?
[18:28:55] <brada> sure
[18:29:24] <brada> i thought maybe it would be a worthwhile optimization to separate it out, but i honestly dont know if it can easily be done
[18:29:46] <brada> certainly nothing to worry about now
[18:33:40] <fuzzie> well it would be nice if it was custom-drawn so we could position stuff properly
[18:34:02] <fuzzie> but I think we'd still want to have it as glyphs
[18:34:20] <brada> what isn't positioned properly with them?
[18:34:24] <fuzzie> and trying to blit bits of a spritesheet into a temp textarea texture sounds no fun at all
[18:34:33] <brada> i thought i fixed that (for BG2 at least)
[18:34:51] <brada> i thought we had to handle images in textareas anyway
[18:34:57] <brada> portraits?
[18:34:58] <fuzzie> yes
[18:35:08] <fuzzie> but everything is an image in the proposed model
[18:35:21] <brada> yeah
[18:35:22] <fuzzie> spritesheet textures are a different story?
[18:35:45] <brada> i havent commited to anything yet
[18:35:56] <fuzzie> yes, I'm just replying to your thought
[18:36:08] <brada> well im not sure yet :p
[18:36:15] <fuzzie> I mean it's all really annoying
[18:36:23] <brada> the only work i have done so far is teardown...
[18:36:25] <fuzzie> because you have to ruin the layer separation
[18:36:32] <fuzzie> in order to do any rendering at all on the client side
[18:36:40] <brada> and parsing
[18:36:51] <fuzzie> and I'm not convinced it's a good idea to special-case fonts anyway
[18:36:56] <brada> sure
[18:37:07] <brada> if it is we can probably worry about it later
[18:37:11] <fuzzie> so grmbl
[18:37:27] <brada> one step at a time right
[18:37:38] <fuzzie> yes
[18:37:40] <fuzzie> do you not have pst?
[18:37:46] <brada> I do own it
[18:37:48] <fuzzie> ok
[18:37:49] <brada> never played it
[18:37:52] <brada> and it isnt installed
[18:38:02] <fuzzie> ok yes I'm just looking at gog
[18:38:32] <brada> i chiv keeps driving us toward PST then I may have to download and install it :)
[18:38:49] <fuzzie> pst is great
[18:38:52] <fuzzie> but it's terrible in gemrb
[18:39:04] <fuzzie> also, terribly buggy in original engine
[18:39:05] <brada> yeah i keep hearing that
[18:39:08] <fuzzie> so interesting target
[18:39:22] <brada> well chiv seems to have worked out a bunch of the bugs
[18:39:36] <brada> he probably needs you/lynx to actually implement a good fix tho
[18:40:27] <brada> I can probably fix floating window thing
[18:40:27] <fuzzie> yes, with Avenger mostly gone, I guess I should really take the 'complicated fixes' hat
[18:40:40] <fuzzie> but frankly I'm never going to have time for the GUI/etc code in that case
[18:40:55] <brada> what did you want to do in the GUI?
[18:41:23] <brada> I finally fixed the scrollbars yesterday :)
[18:41:40] <brada> tho who knows what else i broke with that event manager code
[18:44:39] <fuzzie> the GUI for all the games is still full of issues
[18:44:43] <fuzzie> like that stupid levelup icon
[18:44:46] <fuzzie> and the world map
[18:44:57] <fuzzie> what the heck is with the labels on the local map anyway?
[18:45:35] <brada> well the levelup icon can and should be fixed by implementing the concept of subviews, no?
[18:45:52] <fuzzie> well, 'should be' I'm not going to sign onto :)
[18:45:52] <brada> we need to have NeedsDraw to return true always still
[18:46:12] <brada> well other things benifit from that i think
[18:46:27] <fuzzie> the drawing of the local map is totally broken with NeedsDraw on though
[18:46:43] <fuzzie> oh nice, it segfaulted
[18:47:00] <fuzzie> let's try that again, with a debugger
[18:47:15] <fuzzie> Program received signal SIGSEGV, Segmentation fault.
[18:47:15] <fuzzie> GemRB::Window::OnMouseOver (this=0x0, x=574, y=539)
[18:47:26] <fuzzie> it was brada, in the C++, with the GUI code.
[18:47:50] <fuzzie> 183 if (focusLock) {
[18:47:50] <fuzzie> 184 last_win_mousefocused->OnMouseOver(x, y);
[18:47:56] <fuzzie> ^- last_win_mousefocused is NULL here
[18:48:00] <brada> ah
[18:48:06] <fuzzie> does that make sense?
[18:48:09] <brada> yes
[18:48:23] <fuzzie> can I leave it to you? :p
[18:48:23] <brada> well i thought that it would always be there if the other focus was
[18:48:26] <brada> but I am wrong
[18:48:29] <brada> clearly
[18:48:33] <brada> yes ill fix it
[18:48:40] <brada> but does that fix your issue?
[18:48:45] <brada> or was there something else?
[18:48:46] <fuzzie> no, not at all
[18:49:21] <fuzzie> yes, the drawing is pretty brioken
[18:49:51] <fuzzie> which is annoying given that NeedsDraw always returns true..
[18:50:09] --> raevol has joined #gemrb
[18:50:10] <brada> you mean more broken than it always was?
[18:50:19] <fuzzie> it worked for me :P
[18:51:10] <brada> well which thing specifically is broken?
[18:51:14] <fuzzie> corruption when drawing
[18:51:24] <brada> i cant seem to replicate that...
[18:51:29] <fuzzie> as well as the obvious issues with points-of-interest (e.g. them not appearing in the label)
[18:51:29] <brada> what do i have to do?
[18:51:37] <brada> yeah those were broken before
[18:51:44] <fuzzie> when did that break?
[18:51:47] <brada> no idea
[18:51:53] <fuzzie> the code actually looks fine so it's confusing
[18:51:59] <brada> i was going to bisect that...
[18:52:04] <brada> then i got distracted
[18:54:27] <brada> well i pushed those couple of minor fixes
[18:54:44] <fuzzie> thanks
[18:54:57] <brada> yup
[18:55:03] <brada> thanks for pointing them out :)
[18:55:29] <fuzzie> I guess the mapcontrol has stopped redrawing the background?
[18:56:09] <brada> oh is that where the info points are?
[18:56:17] <fuzzie> no, I'm looking at the corruption I'm seeing
[18:56:25] <brada> oh good cuz it didnt make sense
[18:56:34] <fuzzie> but I mean
[18:56:39] <fuzzie> why would the background not get redrawn?
[18:56:56] <brada> I guess its because its part of another control?
[18:57:00] <brada> what game?
[18:57:03] <fuzzie> bg2
[18:57:08] <brada> hmmm
[18:57:17] <brada> strange that I dont see a problem
[18:57:30] <fuzzie> you have to try with a small area
[18:57:41] <brada> oh
[18:57:53] <fuzzie> I just don't see what you changed that would cause this
[18:58:04] <brada> oh i see a little bit now
[18:58:13] <brada> the corners of the green rect
[18:58:15] <fuzzie> yep
[18:58:23] <fuzzie> sorry, I didn't expect you to care
[18:58:24] <brada> so i guess we do need to invalidate the window
[18:58:25] <fuzzie> otherwise I'd have said
[18:58:34] <fuzzie> where did you remove window invalidation though?
[18:58:36] <fuzzie> I don't see
[18:58:55] <brada> it was probably in another place or this has been a problem for a while?
[18:59:03] <fuzzie> maybe the latter?
[18:59:41] <brada> well the annoying thing is that its only when the area first loads and your party is at the edge
[19:00:07] <brada> I cant get the rectangle back down to where the corruption is
[19:00:12] <fuzzie> yes
[19:00:19] <fuzzie> so that's how I caused that crash, by clicking down there :)
[19:00:27] <brada> so maybe a better fix is possible
[19:00:35] <brada> then redrawing the entire window i mea
[19:01:00] <-- Beholder has left IRC (Quit: Beholder)
[19:01:42] <brada> closing the map and reopening it doesnt cause the corruption either
[19:01:49] <fuzzie> unless you scroll down a bit :p
[19:02:54] <brada> i cant tho
[19:03:02] <fuzzie> ah, it works for me (outside the map)
[19:04:05] <brada> meh its pretty minor, so im inclined to leave it for now in favor of more important things
[19:04:10] <fuzzie> yes
[19:04:13] <brada> really want to get the text layout done soon
[19:04:16] <fuzzie> like the points :-P
[19:05:19] <brada> oh yes those should be fixed
[19:07:25] <fuzzie> so what broke map notes, hrmph
[19:08:48] <fuzzie> they are *there*
[19:10:52] <brada> all I know is I thought i broke them, but I checked out to before my changes and they were still just as broken :/
[19:11:21] <fuzzie> yes, it's odd, how dare it not be your fault
[19:11:44] <brada> dont worry ill break some more stuff soon
[19:11:47] <fuzzie> :)
[19:11:53] <fuzzie> if it's fonts then all good
[19:12:51] <brada> I wish I would have done that years ago
[19:12:52] <fuzzie> these compiler flags are annoying
[19:12:57] <brada> ?
[19:13:03] <fuzzie> the -Werror on unused vars
[19:13:21] <brada> oh yeah
[19:13:30] <brada> it does make development a bit of a pain sometimes
[19:17:38] <fuzzie> sorry, should I be updating on the map thing?
[19:23:44] <fuzzie> I was wondering who'd written some of this code since it's terrible, and I've gotten to the point where I found out it's me
[19:24:34] <raevol> xD
[19:26:37] <brada> i hate when that happens :) the scrollbar code i fixed yesterday was my doing ha ha
[19:26:41] <fuzzie> it's so weird though
[19:26:46] <fuzzie> the BlitSprite just doesn't show anything!
[19:27:18] <brada> so being mysteriously drawn offscreen?
[19:27:20] <fuzzie> no
[19:27:23] <brada> like the console text yesterday
[19:27:26] <fuzzie> coords are fine
[19:27:59] <brada> is the blitter actually reaching a point where it draws?
[19:29:12] <fuzzie> looking into it
[19:30:15] <fuzzie> we seem to have a mysterious computeClipRect
[19:30:36] <fuzzie> ah, in the .inl
[19:32:12] <fuzzie> so yes, they're being clipped
[19:32:20] <fuzzie> by the global clip rect
[19:32:23] <fuzzie> which probably someone reordered
[19:34:09] * fuzzie points a finger at brada
[19:34:26] <fuzzie> take a look at SDLVideoDriver::GetClipRect :-)
[19:35:21] <brada> :(
[19:35:37] <fuzzie> aw, come on, that's totally a cool mistake
[19:35:52] <fuzzie> works fine if I revert the accidental refactor
[19:37:28] <fuzzie> on the other hand, opening the map and then leaving it now breaks totally
[19:37:43] <fuzzie> wah
[19:39:20] <fuzzie> anyway, map pins: fixed
[19:40:25] <fuzzie> and the reason the label isn't resetting is again because the background isn't being drawn..
[19:41:11] <fuzzie> I guess that worked before because Label::SetText called Owner->Invalidate(), but brada removed it, which makes sense, maybe we should put it in Label::MarkDirty
[19:41:28] <brada> probably
[19:41:33] <brada> commit the fix?
[19:41:37] <fuzzie> done
[19:55:15] --> Eli2 has joined #gemrb
[19:59:31] <fuzzie> three commits in one month :)
[20:11:04] --> Yoshimo has joined #gemrb
[20:22:41] --> chiv has joined #gemrb
[20:22:49] <chiv> hi all
[20:24:03] <chiv> thanks for fixing some of the pst bugs, I just scanned the log
[20:32:24] <brada> hey man
[20:32:32] <brada> what do you have for us today?
[20:33:26] <chiv> oh nothing i am afraid, I am shattered, there was a big new year rush at work
[20:33:41] <brada> thatll happen
[20:33:44] <chiv> somehow I have to find the energy to go out later as well
[20:33:51] <brada> yup :)
[20:33:55] <brada> im sure youll manage
[20:34:16] <chiv> I'm sure I will be fine if someone just puts me in a wheelbarrow when it's all over
[20:38:11] <-- Yoshimo has left IRC (Ping timeout: 246 seconds)
[20:45:01] <chiv> that fix for the float menu dragging is niiiiiiice....
[20:46:48] <chiv> I think I just need to clean up my fixes for the other bits and that thing is dealt with
[20:47:34] <brada> who did that?
[20:47:44] <brada> i dont reember seeing such a fix
[20:48:03] <chiv> you apparently? didn't you fix the scroll bar dragging?
[20:48:12] <brada> yes
[20:48:29] <brada> that fixed a problem with the float menu?
[20:48:43] <chiv> well, one of them heh
[20:48:48] <brada> neat :p
[20:48:52] <brada> bonus fix!
[20:49:44] <chiv> saved me looking for it, i have the other bits of it working though in my branch
[20:51:57] <brada> yeah, id still like to do that more elegantly, but it looks like maybe that a lot of work so ill dl pst and have a look at your fix
[20:52:37] <brada> what exactly is the problem again?
[20:52:44] <brada> it closes when it whouldnt?
[20:52:47] <brada> shouldnt
[20:53:41] <chiv> fundamentally the problem is that in torment, right mouse should never do any action at all, but gemrb does because it is sensible for the other games
[20:54:14] <chiv> so what happens is you carefully choose your action, and then when you right click again to unpause, your action gets thrown away for a basic walk move
[20:54:26] <fuzzie> that should really be easy to fix
[20:54:55] <brada> yeah ill look at it
[20:55:32] <chiv> i have a fix for it but I don't really know if it has side effects...
[20:55:57] <brada> i know it killed formation rotation, but that is probably irrelevant for PST
[20:56:04] <chiv> https://github.com/chilvence/gemrb/commit/9d101907dee106d6074de0df47ee3666f66115cd
[20:56:05] <Pepelka> Hack to stop the RMB cancelling the float menu action · 9d10190 · chilvence/gemrb · GitHub
[20:56:06] <Pepelka> »gemrb - Engine Made with preRendered Background«
[20:56:13] <chiv> pst has that, but it uses the alt key instead
[20:56:27] <brada> well obviously gemrb doesnt :p
[20:56:50] <brada> maybe i can reconcile that
[20:58:06] <chiv> I'm also slowly working on bringing the python bits up to speed
[20:58:12] <brada> nice
[20:58:26] <brada> hopefully that means more consolidation
[20:58:50] <brada> even tho everytime we do it bugs crop up :/
[20:58:56] <brada> but its worth it
[20:58:56] <chiv> eg lynx did spellbook.py which was very nice but torment still doesn't use it
[21:00:12] <chiv> well I already added that anyway, but its sort of hard to test
[21:00:50] <brada> the bugs from merging are easily fixed anyway
[21:04:31] <fuzzie> optimistic
[21:06:04] <chiv> well, I actually like working on the python bit, I don't have to wait 10 minutes for it to compile
[21:07:05] <fuzzie> mm
[21:07:18] <fuzzie> yes waiting for gemrb to compile is v.annoying on a slow machine
[21:07:27] <brada> it shouldnt take gemrb 10 min to compile either :)
[21:07:40] <fuzzie> it would help if we didn't make cmake, somewhat
[21:07:41] <chiv> it's also probably the one part of the game I have familiarity with...
[21:07:49] <fuzzie> bit frustrating
[21:07:52] <chiv> i like cmake
[21:08:00] <fuzzie> yes, but it's unhelpful for compile times
[21:08:01] <chiv> i just have a computer from the 90's
[21:08:17] <brada> i like cmake too, but i use xcode which compiles in like 2 seconds
[21:08:20] <fuzzie> it doesn't do dependency scanning which is annoying
[21:08:33] <fuzzie> brada: you probably have an overpowered processor :)
[21:08:43] <brada> its not that strong
[21:08:45] <brada> im on a laptop
[21:08:52] <fuzzie> does it have 'core' in the name? :P
[21:09:02] <brada> it is an i7 so yeah :p
[21:09:08] <fuzzie> so, yeah, overpowered :)
[21:09:18] <brada> moar powah!
[21:09:25] <fuzzie> I like hacking around on my netbook but it has a 1.6ghz atom
[21:10:41] <fuzzie> which is, well, alas.
[21:11:31] <fuzzie> *slightly* faster than 15-year-old processors. bless.
[21:12:16] <fuzzie> I'm all in favour of pushing stuff into python though
[21:13:28] --> Beholder has joined #gemrb
[21:13:35] <Beholder> happy new Year :)
[21:13:41] <fuzzie> hey Beholder
[21:15:03] <chiv> с новым годом
[21:15:15] <Beholder> :)
[21:15:40] <fuzzie> ☃
[21:16:12] <Beholder> no code, no opengl today. only wine, fireworks, and fun
[21:18:14] <-- Beholder has left #gemrb
[21:21:39] <Lightkey> fuzzie: teh funneh, just overheard a random discussion in the bus back where someone made fun of $standard which allows UTF-16 in names for USB devices
[21:22:34] <Lightkey> ..and he said "why, I always wanted to have a snowman in there"
[21:28:58] <fuzzie> Lightkey: 👯
[21:40:58] <Lightkey> I don't have that character
[21:41:31] <fuzzie> no-one ever does :(
[21:41:45] <brada> the two dancing girls?
[21:47:29] <fuzzie> no, but close
[22:28:21] <fuzzie> well, you all went quiet
[22:29:29] <raevol> :E
[22:39:03] --> Yoshimo has joined #gemrb
[22:43:06] <brada> TouchInputEnabled looks wrong to me
[22:43:12] <brada> tho im sure it doesnt matter
[22:43:21] <brada> is that for EE or something?
[22:52:25] <-- Yoshimo has left IRC (Ping timeout: 272 seconds)
[23:10:33] <-- raevol has left IRC (Ping timeout: 245 seconds)
[23:24:49] --> raevol has joined #gemrb