#gemrb@irc.freenode.net logs for 22 Feb 2012 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:29:19] <brad_a> i think before we tackle unicode we need to figure out how to use an array/vector of glyphs instead of a sprite map
[00:29:41] <brad_a> by that i mean specifically how to deal with palettes
[00:30:24] <brad_a> do we jsut point all the glyph palettes to the font palette and memcpy over it?
[00:37:32] <CIA-28> GemRB: 03edheldil * r52f409b8fb7e 10gemrb/gemrb/GUIScripts/pst/MessageWindow.py: Show party gold in MessageWindow
[00:37:43] <CIA-28> GemRB: 03edheldil * re482b6f66df7 10gemrb/gemrb/ (11 files in 11 dirs):
[00:37:43] <CIA-28> GemRB: Better handle right click in PS:T
[00:37:43] <CIA-28> GemRB: * popup FloatMenu on rightclick down
[00:37:43] <CIA-28> GemRB: * rotate formation on any modifier+rightclick
[00:37:43] <CIA-28> GemRB: * add GF_HAS_FLOAT_MENU
[00:37:44] <CIA-28> GemRB: * pass menu pos as parameters, instead of vars
[00:38:59] <edheldil_> night
[00:43:46] <-- edheldil_ has left IRC (Ping timeout: 265 seconds)
[00:51:55] <brad_a> i wonder how i should enable use of formation rotation with a touch screen for PST
[00:52:26] <brad_a> i guess the soft keyboard has a ctrl and alt modifier
[00:52:42] <brad_a> awful cumbersome
[00:55:39] <-- brad_a has left IRC (Quit: brad_a)
[01:28:25] --> nutron has joined #gemrb
[02:31:31] --> brad_a has joined #gemrb
[03:34:50] --> mrugiero has joined #gemrb
[03:36:14] <-- mrugiero has left #gemrb
[04:04:34] <brad_a> tomprince: is it possible to cast a class to a struct? ie Rect to SDL_rect?
[04:04:54] <brad_a> they both have the first 4 members the same
[04:07:36] <brad_a> if not then i think i should make an SDL_rect ivar for sdlvideo instead of creating all these SDL_rects everywhere
[04:20:18] <tomprince> not with well defined semantics.
[04:26:42] <brad_a> basically what i meant :) glad you could decipher that
[04:27:21] <tomprince> In practice, it will do the right thing, but I don't want to depend on that.
[04:28:55] <tomprince> #ifndef WIN32
[04:28:57] <tomprince> #include <sys/time.h>
[04:29:13] <tomprince> https://gist.github.com/1881370 <-- would proably work, but that does feel a bit hackish.
[04:29:44] <tomprince> You could write a toSDL_rect(Region) function, though.
[04:29:55] <tomprince> (If your are doing it enough times to matter)
[04:30:17] <tomprince> Although, if you already have an SDL_Rect lying around, better to store that than anything else.
[04:41:18] <brad_a> yeah kinda exactly what i figured
[04:41:26] <brad_a> works but not promised to work
[04:42:00] <brad_a> we use it very frequently so probably should jsut store a viewport rect as an sDL_rect
[04:42:47] <tomprince> Well, is that information shared with core?
[04:44:00] <brad_a> ? not sure what you are asking. i was going to have and SDL_rect to mirror the viewport rect
[04:44:43] <tomprince> I don't like the idea of having 2 structures that need to be kept in sync.
[04:45:03] <brad_a> would it suprise you if i told you that was already the case?
[04:45:17] <brad_a> video player subtitle rect :)
[04:45:39] <tomprince> no.
[04:46:27] <brad_a> i dont like it either but i dislike having to construct a rect every call to a drawing method
[04:46:39] <brad_a> we could use my original plan and cast :)
[04:47:10] <tomprince> Why don't you like it?
[04:47:35] <brad_a> probably not a good reason :)
[04:48:09] <brad_a> its probably not as performance intensive as it seems
[04:49:42] <tomprince> A smart compiler will notice that the structures are the same shape, and that we are copying avlue, and inline ite away.
[04:49:53] <tomprince> Don't know if we have compilers that smart, though.
[06:19:53] --> edheldil_ has joined #gemrb
[06:22:18] <CIA-28> GemRB: 03bradallred * r6b6efcde0d3e 10gemrb/gemrb/plugins/SDLVideo/SDL20Video.cpp: SDL20Vidoe: remove some useless function calls
[06:24:16] <-- edheldil_ has left IRC (Ping timeout: 244 seconds)
[06:43:29] <brad_a> so SDLVideoDriver::BlitGameSprite simply blows my mind o_O
[06:44:02] <brad_a> my hat goes off to anyone that can understand it!
[06:45:05] <tomprince> That wuold be wjp.
[06:47:28] <brad_a> i never realized how complicated drawing computer graphics is
[06:48:43] <tomprince> That code also handles a lot of different combinations of options and output widths.
[06:49:36] <brad_a> it certainly impressive
[06:54:49] <-- brad_a has left IRC (Quit: brad_a)
[07:12:40] --> edheldil_ has joined #gemrb
[07:27:44] <CIA-28> GemRB: 03edheldil * r83a7d7fed3a5 10gemrb/gemrb/core/GUI/ (GameControl.cpp TextArea.cpp):
[07:27:44] <CIA-28> GemRB: Highlight reply under cursor after scrolling in dialog
[07:27:45] <CIA-28> GemRB: * Fixes LONG time annoyancein TextArea
[07:27:45] <CIA-28> GemRB: * Remove unneeded setvar in GameScreen
[07:32:08] <wjp> I should finish my rewrite of that to something more like BlitTile
[07:32:52] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[07:35:58] --> edheldil_ has joined #gemrb
[07:42:22] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[08:03:59] --> lynxlynxlynx has joined #gemrb
[08:03:59] <-- lynxlynxlynx has left IRC (Changing host)
[08:03:59] --> lynxlynxlynx has joined #gemrb
[08:03:59] --- ChanServ gives channel operator status to lynxlynxlynx
[08:17:16] <-- pmjdebru1jn has left IRC (Ping timeout: 252 seconds)
[08:45:34] --> SiENcE has joined #gemrb
[08:49:06] <edheldil> Good morning
[08:50:37] <fuzzie> morning
[08:53:28] <edheldil> We should have adopted mvc model
[08:53:58] <lynxlynxlynx> did it exist back then?
[08:53:59] <edheldil> .... from the start :)
[08:54:12] <edheldil> good question :)
[08:56:10] <fuzzie> why? :p
[08:57:19] <fuzzie> well, I guess if you are still only looking at the GameControl then that is a silly question
[08:58:28] <edheldil> no. Maybe not exactly mvc but signal/listen - it would be nice to e.g. in MessageWindow do on_party_gold_changes(update_gold_label) or st. like that
[08:58:51] <fuzzie> yes, the complete lack of game state tracking is a huge pain
[09:00:10] <fuzzie> but we *do* have the framework there from all the GUI/etc callbacks, right?
[09:00:36] <edheldil> partial - we can have only one listener
[09:01:05] <edheldil> and you have to call SetEvent() on random (gui) objects
[09:01:16] <fuzzie> that isn't a design limitation
[09:01:39] <fuzzie> you can have a std::array<Holder<Callback> > if you want, no?
[09:02:04] <edheldil> it would be maybe better to have signal objects which would have emit() and listen() methods
[09:02:14] <fuzzie> you just have to be careful to do the calls from the main loop
[09:02:29] <fuzzie> so you'd presumably want some kind of signal queue
[09:02:38] <fuzzie> I mean, from a guiscript point of view.
[09:04:40] <edheldil> why queue?
[09:04:47] <fuzzie> well
[09:04:56] <fuzzie> when the gold changes, you'll be deep inside game code
[09:05:18] <fuzzie> and that is (thankfully) not intended to be re-entrant
[09:05:42] <edheldil> ok, I understand now
[09:05:54] <fuzzie> so to avoid a huge source of bugs, you could simply have a queue
[09:06:00] <fuzzie> but it doesn't seem too tricky to do!
[09:07:23] <edheldil> so that some central event processing loop would marshal the events based on source object and sevent type?
[09:07:38] <edheldil> event
[09:08:10] <fuzzie> well, it depends what kind of signals you want
[09:08:45] <fuzzie> but that sounds about what I am thinking, yes
[09:08:55] <edheldil> btw, is not there already message passing bus in gemrb?
[09:09:01] <fuzzie> there's some hacky stuff
[09:09:05] <fuzzie> you'd probably want to merge that in
[09:09:28] <fuzzie> e.g. there's EventFlag
[09:09:43] <fuzzie> which has hard-coded EF_SELECTION, EF_UPDATEANIM, EF_PORTRAIT, EF_ACTION, etc
[09:09:59] <fuzzie> which is basically begging for a more central framework
[09:10:41] <fuzzie> what I said last time is that what I *don't* think is a good idea is simply moving this stuff to require that scripts have to register callbacks, without actually adding anything smart
[09:11:14] <edheldil> ?
[09:11:48] <fuzzie> e.g. just adding a huge amount of on_xxx(my_func) boilerplate to all the guiscripts
[09:11:56] <fuzzie> without actually improving things at all
[09:12:42] <fuzzie> but if we added an actual flexible signal system would be great
[09:13:15] <edheldil> what do you mean with boilderplate? Handlers for signals you do not actually want?
[09:13:31] <fuzzie> I mean, right now, there's a huge bunch of RunFunction stuff.
[09:14:05] <fuzzie> you could just replace the hard-coded call inside EF_SELECTION with a callback, thus un-hardcoding the function name
[09:14:40] <fuzzie> but if we still have all the EF_SELECTION etc stuff hard-coded, then that doesn't actually help, and just adds more complication to everything
[09:14:54] <fuzzie> but if we can de-hardcode the EF_SELECTION so that there's an actual queue, that would be great
[09:14:57] <fuzzie> i don't know if that makes any sense :)
[09:15:26] <edheldil> not really, I will have to look at the EF part first
[09:15:41] <fuzzie> it's basically just a mask on an EventFlags variable
[09:16:01] <fuzzie> so if 'EventFlags & EF_SELECTION', then it does guiscript->RunFunction( "GUICommonWindows", "SelectionChanged", false); and then unsets EF_SELECTION
[09:17:39] <fuzzie> and I think replacing it with hard-coded runCallbacks(m_selectionCallbacks); would be silly, but if you could have emitSignal(sigSelectionChanged); and de-hardcode everything, that sounds useful
[09:21:14] <edheldil> you mean that the bad thing would be to encode all the possible signals in the event queue processing, instead of EQ being oblivious to what it's really passing, right?
[09:21:44] <fuzzie> yes!
[09:23:03] <fuzzie> and I guess it should also only be used for signals
[09:23:23] <fuzzie> but that needs someone to think I guess
[09:23:26] <edheldil> i.e. no keys and mouse stuff?
[09:24:02] <fuzzie> no, but e.g. it isn't really appropriate for things like 'StartLoadScreen'
[09:25:42] <edheldil> hmmm ... it would be best to save ideas like this somewhere
[09:26:16] <fuzzie> well it's the kind of thing that only needs an hour or two to do
[09:26:21] <fuzzie> but of course I am shortly gone :)
[09:26:47] <edheldil> and I am at work :)
[09:32:09] <fuzzie> and in fact I am really very bad at merging this cleanup patch stuff to anything
[09:45:27] <-- SiENcE has left IRC (Quit: @all: cya)
[10:05:26] --> kettuz has joined #gemrb
[11:53:12] --> kida_laptop has joined #gemrb
[12:21:37] <-- kettuz has left IRC (Quit: Leaving)
[12:59:06] --> haad has joined #gemrb
[13:57:14] --> SiENcE has joined #gemrb
[15:00:31] --> kettuz has joined #gemrb
[15:30:01] --> brad_a has joined #gemrb
[15:35:59] <CIA-28> GemRB: 03bradallred * r8d26754720c1 10gemrb/gemrb/plugins/SDLVideo/SDL12Video.cpp: Actually check that we are attempting to use a software keyboard before spewing warnings about it not being supported.
[15:36:02] <CIA-28> GemRB: 03bradallred * r7b8d1259f750 10gemrb/gemrb/core/GUI/ (GameControl.cpp TextArea.cpp): Merge branch 'master' of ssh://gemrb.git.sourceforge.net/gitroot/gemrb/gemrb
[15:39:38] --> alx3apps has joined #gemrb
[16:00:34] <-- brad_a has left IRC (Quit: brad_a)
[16:21:23] --> edheldil_ has joined #gemrb
[16:26:46] <-- edheldil_ has left IRC (Ping timeout: 272 seconds)
[16:57:30] <-- kettuz has left IRC (Quit: Leaving)
[17:12:13] --> brad_a has joined #gemrb
[17:15:49] <brad_a> im not the one that broke text input am i?
[17:16:28] <fuzzie> I'm sure we can safely assume it's all your fault.
[17:16:39] <brad_a> gdb does break in SDLVideo when i key down/up where it calls event manager
[17:16:46] <brad_a> :-P
[17:17:38] <brad_a> keys still work fine other than text input....
[17:25:40] <brad_a> unsure of why text input doesnt work while hot keys etc do
[17:25:56] <brad_a> i haven't the time to look at it till tonight either
[17:31:11] --> Yoshimo has joined #gemrb
[17:37:54] <-- SiENcE has left IRC (Quit: @all: cya)
[17:53:41] <-- brad_a has left IRC (Quit: brad_a)
[17:56:21] <lynxlynxlynx> a safe bet would be they don't have focus
[18:25:10] --> brad_a has joined #gemrb
[18:25:28] <-- kida_laptop has left IRC (Quit: 전 이만 갑니다.)
[19:00:53] --> wrotek_ has joined #gemrb
[19:41:59] --> edheldil_ has joined #gemrb
[20:33:51] --> Avenger has joined #gemrb
[20:35:01] <Avenger> fuzzie: about EF_*/QF_* messages. Sometimes a queue is not a solution, because some messages have priority. In other cases, yeah, it is a substitution for the IE message system
[20:35:22] <Avenger> but, even in the IE, the messages are hardcoded
[20:35:41] <Avenger> so, short of a queue, the IE version doesn't differ much from ours
[20:39:51] <Avenger> heh, cool, someone really broke character input :)
[20:42:05] --> SiENcE has joined #gemrb
[20:42:08] <-- alx3apps has left IRC (Quit: Leaving.)
[20:42:55] <Avenger> this is a very recent change, before the sdl split, i could use the console (it is broken too)
[20:51:25] <Avenger> the change about polling events in sdlvideo broke this
[20:52:34] <brad_a> we figured that, but i was unable to see how with a cursory exam. I should have time to fix it tonight.
[20:54:55] <Avenger> i wonder how it retains the special keys, if the whole event structure is destroyed, it wouldn't be possible
[20:55:31] <Avenger> also, keysym.sym is ok, only unicode is broken
[20:55:54] <Avenger> didn't you set/remove some unicode option somewhere?
[20:56:28] <brad_a> the unicode option should have moved to SDL12Video
[20:56:51] <Avenger> our code has SDL_EnableUNICODE(1)
[20:57:45] <Avenger> init should return nonzero when all is ok?
[20:57:46] <brad_a> i shouldnt have added or removed anything. should have just moved adl 1.2/2 specific code to teh respective new files
[20:58:41] <Avenger> yeah, silly you, should always use ==GEM_OK
[20:58:43] <Avenger> :P
[20:58:57] <brad_a> yes :-P that bit me good before did i miss one?
[20:59:03] <fuzzie> we should really replace those with bool
[20:59:07] <brad_a> yes
[20:59:11] <fuzzie> or just error out
[20:59:13] <brad_a> is that ll it was ?
[20:59:58] <Avenger> no, i prefer gem_ok, programmer intent is clearer (if it is used)
[21:00:27] <Avenger> you'll can never know what 'ret' means, is it an error code? is it all_ok?
[21:00:39] <fuzzie> if it's a bool, it's pretty clear
[21:00:50] <Avenger> well, you have 50%
[21:01:08] <fuzzie> but usually there's no legitimate reason for stuff to return at all
[21:01:43] <Avenger> sdl20 has no keyrepeat/unicode?
[21:02:02] <fuzzie> sdl20 has a different text entry model
[21:02:14] <fuzzie> because users might be using a emulated keyboard
[21:02:14] <Avenger> well, hope it works
[21:02:35] <fuzzie> so, you might not necessarily get key presses
[21:02:58] <Avenger> will keysym.unicode work in sdl20?
[21:03:05] <fuzzie> nope
[21:03:53] <Avenger> then this line in the common code: key = (unsigned char) event.key.keysym.unicode; is bad?
[21:03:58] <fuzzie> yes
[21:04:03] <fuzzie> but you get 0, so it 'works' anyway
[21:04:16] <fuzzie> i mean this is assuming they didn't change it yet again :P brad_a would know better than me
[21:04:18] <Avenger> it will be broken like now
[21:04:25] <fuzzie> sure, but it was broken already
[21:04:36] <brad_a> I will look into that in 2.0
[21:04:53] <brad_a> last i checked input still worked on ios but i havent tried on mac
[21:05:14] <brad_a> if its broken in 2.0 ill fix it
[21:05:36] <CIA-28> GemRB: 03avenger_teambg * r9a40ca1a706d 10gemrb/gemrb/plugins/SDLVideo/SDL12Video.cpp: fixed text input (only in sdl 1.2)
[21:05:54] <fuzzie> i don't see any handling of SDL_TEXTINPUT at all
[21:06:04] <brad_a> there isnt any at the moment
[21:06:10] <fuzzie> but i guess you don't do StartTextInput
[21:07:02] <-- Yoshimo has left IRC (Quit: Yoshimo)
[21:07:35] <fuzzie> the wiki is kind of useless
[21:07:48] <fuzzie> it just says "use SDL_TextInputEvent instead (deprecated)"
[21:10:01] <Avenger> it is deprecated before we notice it :)
[21:10:24] <fuzzie> well I'm sure I already went through all this pain with someone
[21:10:26] <fuzzie> but I guess not for gemrb
[21:51:54] <-- Avenger has left IRC (Quit: bye!)
[22:19:14] <lynxlynxlynx> heh
[22:19:25] <lynxlynxlynx> googling for gemrb stuff from today
[22:19:37] <lynxlynxlynx> 7h someone volunteered on openhatch
[22:19:43] <lynxlynxlynx> wierd that there's no notification
[22:22:13] <-- nutron has left IRC (Quit: I must go eat my cheese!)
[23:06:50] <-- haad has left IRC (Ping timeout: 260 seconds)
[23:09:00] --> haad has joined #gemrb
[23:13:19] <-- SiENcE has left IRC (Quit: cya)
[23:48:04] --> fuzzie_ has joined #gemrb
[23:54:14] <-- fuzzie has left IRC (Ping timeout: 252 seconds)
[23:54:23] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[23:55:47] <-- brad_a has left #gemrb