[00:03:45] <-- tomprince_loki has left IRC (Ping timeout: 240 seconds)
[00:17:16] <-- cubathy has left IRC (Quit: Leaving)
[00:24:26] <-- Maighstir_laptop has left IRC (Quit: Maighstir_laptop)
[00:24:42] --> cubathy has joined #GemRb
[00:31:14] <-- cubathy has left IRC (Quit: Leaving)
[01:08:03] --> Gekz has joined #GemRb
[02:20:12] <CIA-24> GemRB: 03tom.prince * rb0396e9984b9 10gemrb/gemrb/GUIScripts/ (iwd2/GUISAVE.py pst/GUISAVE.py):
[02:20:12] <CIA-24> GemRB: Fix saving new game.
[02:20:12] <CIA-24> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[02:22:03] <tomprince> Do PsT stores actually work?
[02:33:45] <tomprince> It seems broken at least as far back as d2b6b668f0326cee3770de2f7be8dd22631fae3d
[02:34:28] <_pickle> anyone here run gemrb on a iphone/n900/other arm cortexA device?
[02:34:36] <tomprince> They seem to be empty, and fail to close.
[02:35:08] <tomprince> There are reports of it running on mameo.
[02:35:35] <tomprince> As far as I know, there is no one who regularlly tests it on arm.
[02:35:52] <tomprince> So it may currently be broken.
[02:37:38] <tomprince> _pickle: I am quite willing to help get it running on arm, but I don't have any experience, or access to machine.
[02:39:50] <_pickle> well ive built it for the pandora, but we have had issues getting past char creation
[02:40:16] <_pickle> i was just curious if anyone here might have run it
[02:41:20] <tomprince> What issues? We are certainly interested in fixing it, we just don't have any testers.
[02:42:10] <_pickle> well, im also going on second hand info, as i only have the demo game data, i think it didnt render correctly and might have crashed
[02:43:19] <tomprince> Do you have a log of the console?
[02:45:07] <_pickle> no, i can ask for it
[02:46:19] <tomprince> Ask for it, or send the people here.
[02:49:15] <tomprince> If somebody reports a problem, and is willing to debug it, the turnaround time here is ususually very good.
[02:53:14] <_pickle> sure, if i have something more concrete i come back
[02:53:34] <tomprince> Excellent.
[03:04:32] <tomprince> PsT stores are even broken in 313eb8d (last svn rev).
[03:50:58] <CIA-24> GemRB: 03tom.prince * re821b1262581 10gemrb/gemrb/ (6 files in 2 dirs):
[03:50:58] <CIA-24> GemRB: Dialog: "Compile" dialog triggers on read, rather than execution.
[03:50:58] <CIA-24> GemRB: Note: this means that dialog Or blocks short circuit now.
[03:50:58] <CIA-24> GemRB: Signed-off-by: Tom Prince <email@example.com>
[03:51:00] <CIA-24> GemRB: 03tom.prince * r79479b03d54a 10gemrb/gemrb/ (5 files in 2 dirs):
[03:51:00] <CIA-24> GemRB: Dialog: Compile Actions on load, rather than execute.
[03:51:00] <CIA-24> GemRB: If actions fail to compile then this treats it as having no actions
[03:51:00] <CIA-24> GemRB: (this affects whether the action queue is cleared).
[03:51:01] <CIA-24> GemRB: Signed-off-by: Tom Prince <firstname.lastname@example.org>
[03:51:05] <CIA-24> GemRB: 03tom.prince * rc68eccfd6995 10gemrb/gemrb/ (3 files in 2 dirs):
[03:51:05] <CIA-24> GemRB: Store: Compile trigger on load rather than test.
[03:51:05] <CIA-24> GemRB: This treats a trigger that fails to compile as lacking a trigger.
[03:51:05] <CIA-24> GemRB: Should we reconsider using infinite supply to hold the strref?
[03:51:06] <CIA-24> GemRB: NOTE: PST Stores are not implemented, so this is untested.
[03:51:06] <CIA-24> GemRB: Signed-off-by: Tom Prince <email@example.com>
[04:39:41] --> Gekz_ has joined #GemRb
[04:43:23] <-- _pickle has left IRC (Remote host closed the connection)
[05:12:40] --> raevol has joined #GemRb
[06:03:00] <tomprince> Does anybody here have experience doing GUI programming?
[06:04:02] <Gekz_> me
[06:04:05] <Gekz_> GTK and QT
[06:04:14] <Gekz_> in Python and Java
[06:05:06] <tomprince> The thing is, the way our GUI is implemented, every little bit of it is programmed essentially by hand.
[06:05:26] <tomprince> Which bugs me, so I would like to improve it, to bring it more in line with tradional GUI programing.
[06:05:39] <Gekz_> you mean
[06:05:45] <Gekz_> with xml files for the ui?
[06:06:02] <Gekz_> traditional UI programming does in fact use code.
[06:06:03] <Gekz_> lol
[06:06:13] <tomprince> I don't know.
[06:06:21] <Gekz_> or do you mean predefined classes for specific windows, etc?
[06:06:28] <tomprince> But I suspect that we want at least some data files.
[06:06:34] <Gekz_> like BGPrompt
[06:06:38] <Gekz_> BGDialog
[06:06:38] <Gekz_> etx
[06:06:57] <tomprince> Something like that.
[06:07:05] <Gekz_> you manually draw each dialog?
[06:07:08] <Gekz_> with chunks of code?
[06:07:23] <tomprince> Well, not so much *draw*.
[06:07:32] <tomprince> All the windows are prerendered.
[06:07:34] <Gekz_> "piece together"
[06:07:55] <Gekz_> prerendered in the BIFs?
[06:07:59] <tomprince> And there are files that say where the controls are on the screen, and what type of control they are.
[06:08:19] <tomprince> But, the are only refered to by number, and the numbers change from game to game.
[06:08:29] <Gekz_> so you'd like classes for this
[06:08:36] <Gekz_> so you could do Window->x
[06:08:36] <tomprince> I think so.
[06:08:39] <Gekz_> instead of
[06:08:44] <Gekz_> Window->pleaseBeThisNumber
[06:08:52] <tomprince> Something like that, yes.
[06:08:58] <Gekz_> that sounds pretty easy
[06:09:16] <Gekz_> would you want it in C++ or Python?
[06:09:37] <tomprince> Python, or perhaps a mix of both.
[06:09:47] <Gekz_> well it'd be per game now wouldnt it
[06:09:50] <Gekz_> so it'd have to be python
[06:10:16] <tomprince> I don't know if the api we expose to python is rich enough right now to express things nicely.
[06:10:40] <Gekz_> we can make it see things our way
[06:10:41] <Gekz_> haha
[06:11:06] <tomprince> But I have zero experience with GUI programming, so I have no idea one would write the code if you could pick the API.
[06:12:13] <Gekz_> consider how the windows are predefined
[06:12:18] <Gekz_> it wouldnt be that hard really
[06:12:29] <Gekz_> you're just defining them as variables
[06:12:49] <Gekz_> moreorless just structs
[06:13:28] <tomprince> Well, I was also wondering if it might make sense to do some MVC thing...
[06:13:58] <Gekz_> I've never touched MVC
[06:14:06] <Gekz_> but I've heard it's like touching satan
[06:14:23] <Gekz_> oh
[06:14:31] <Gekz_> I must be thinking of MFC
[06:14:36] <tomprince> Yes.
[06:14:36] <Gekz_> no, this is what GTK and QT do
[06:14:39] <Gekz_> and it's what I was proposing
[06:14:45] <tomprince> MVC = Model-View-Controller.
[06:15:28] <Gekz_> QWindow window = new QWindow();
[06:15:40] <Gekz_> QWidget w = new QWidget();
[06:15:50] <Gekz_> window.centralWidget(w);
[06:15:52] <Gekz_> window.show();
[06:16:57] <tomprince> Well, have a look at GUIScripts/bg2/GUISTORE.py, since that is what I have been looking at.
[06:17:43] <tomprince> There seems to be three separate tasks going on. One is the stuff that has all the magic numbers for getting the windows.
[06:17:58] <tomprince> One is doing all the game logic.
[06:18:38] <Gekz_> oh god
[06:18:38] <tomprince> And the third is telling each control what to display, based on the game logic in the second step.
[06:18:45] <Gekz_> this makes object oriented programming cry
[06:18:49] <Gekz_> might as well have written this all in C
[06:19:29] <Gekz_> the only positive thing about Java is every file must be a class
[06:19:39] <tomprince> It is better than it used to be. Originally, there where *no* objects exposed to python at all.
[06:20:06] <tomprince> It was Window.SetVisible(...), it was SetWindowVisible(Window, ...)
[06:20:34] <tomprince> I agree that it is horrid.
[06:22:34] <tomprince> If someone to rewrite it in a sensbile fashion, using whatever fanciful API would make the code nice, I could probably make that API appear. Or at least one close to it.
[06:22:46] --> puphome_ has joined #GemRb
[06:26:25] <-- puphome has left IRC (Ping timeout: 264 seconds)
[06:27:48] <Gekz_> remind me in two weeks after my exams
[06:29:12] <tomprince> Will do.
[06:48:06] <tomprince> Night.
[07:44:59] --> cubathy has joined #GemRb
[08:24:37] <fuzzie> huh, i thought pst stores worked fine at some point
[08:24:43] <fuzzie> well, 'fine', but still
[08:25:31] <fuzzie> and as noted, what we have is pretty much "traditional GUI programming" :)
[08:27:05] <fuzzie> I don't think there are any popular GUI systems where you don't have to go and fiddle with the objects in code from time to time.
[08:33:03] <fuzzie> And I still don't think there are any major GUI code design problems which couldn't be fixed solely on the python side.
[08:33:30] <fuzzie> Well, assuming the API was expanded a bit for actors.
[08:50:54] <Gekz_> fuzzie: it's not traditional
[08:50:58] <Gekz_> as it uses no object model that I can see
[08:51:06] <Gekz_> it's just spammy procedural code
[08:51:13] <Gekz_> that could do with some objectification
[08:52:47] <fuzzie> i'm pretty sure traditional doesn't really have objects, either :)
[08:53:00] <Gekz_> doing it wrong
[08:53:21] <Gekz_> and it is a bit better laid out in procedural
[08:53:26] <Gekz_> but even then they did it in an object-like way
[08:53:40] <Gekz_> using functions to refer to other widgets instead of just referring to the class itself
[08:54:11] <fuzzie> but i don't think you'd gain from object-orientation on the python side
[08:54:33] <fuzzie> the callback model is pretty ideally suited to what gemrb wants to do, imo
[08:55:09] <fuzzie> it's just that the guiscripts are a huge mess themselves, but you don't need API changes to move the magic numbers into a data structure
[08:56:56] <Gekz_> this is true
[08:56:57] <Gekz_> an enum
[08:56:58] <Gekz_> odit
[08:57:01] <Gekz_> doit*
[08:57:10] <fuzzie> exams :(
[08:57:17] <fuzzie> also i got a bit distracted with scummvm things
[09:01:58] <fuzzie> but tidying up the show/hide GUI stuff would prbly be my first step
[10:06:25] <-- raevol has left IRC (Quit: Leaving.)
[12:03:48] <Lightkey> ah well.. bought another German edition of Baldur's Gate on the flee market, with the "funny" translation
[12:18:35] <Lightkey> *bwaha* wait, that is actually the add-on to it
[12:18:43] <Lightkey> nice-u
[12:31:03] <Lightkey> from a smoker *ugh*
[12:32:45] <Lightkey> together with Hexplore, anyone played that?
[12:41:29] <fuzzie> never even heard of it :)
[12:42:01] <Lightkey> at least that, I did :p
[12:42:32] <Lightkey> 't was from the time when I still read the PC Games magazine
[13:15:56] <-- cubathy has left IRC (Ping timeout: 258 seconds)
[13:25:04] --> pupnik_ has joined #GemRb
[13:29:22] --> cubathy has joined #GemRb
[13:48:57] <tomprince> It looks like 83bd857cd211c12dde196f5910e9e5df3f12bc7e might have broken pst stores.
[13:52:37] <fuzzie> well, i mean, since 2008 :)
[13:52:53] <fuzzie> i know iwd2 stores are broken, but i'm pretty sure they never worked
[13:53:32] <fuzzie> could well have been some local fix i never got committed though.
[13:56:27] <-- cubathy has left IRC (Quit: Leaving)
[14:09:22] <tomprince> One thing that would simplify a lot of gui script code would be a listbox widget.
[14:10:10] <fuzzie> For what kind of thing?
[14:10:37] <tomprince> The save/load game window, the store window.
[14:10:59] <fuzzie> oh, right
[14:11:10] <fuzzie> but again, easy to do on the python side
[14:11:57] <tomprince> Proficency, Skill, spell, hated race selection.
[14:12:21] <fuzzie> and i guess you are looking at bg2 here
[14:12:54] <tomprince> To get that list, I just did 'git grep TopIndex'
[14:14:20] <fuzzie> wouldn't be surprised if there are more, then
[14:14:35] <fuzzie> but obviously I am against putting more logic on the C++ side
[14:15:09] <fuzzie> I would prefer the game rules all be on the python side, but the stupid effects make a real mess of that.
[14:17:22] <fuzzie> but it seems you could do listboxes very nicely on the python side, even with slicable objects so you could trivially do the savegame widgets on-demand.
[14:18:16] <tomprince> Well, I wasn't suggesting more logic on the C++ side, just perhaps richer, more natural access to stuff. (And no, I don't have any specific examples, just a feel that the python interface wsn't designed, it just sort of happened)
[14:19:06] <fuzzie> well, the interface could obviously do with a lot of work :-)
[14:20:06] <tomprince> That is why I was suggesting that it might involve C++.
[14:20:23] <tomprince> :)
[14:20:54] <fuzzie> but i think if anyone is to really improve the GUIScript situation, it would be a much better first step to refactor the python side.
[14:23:51] <tomprince> Well, that was why I was sort of wanting somebody to refactor the Python side, without limiting themselves to the current api, assuming what api makes life easiest. And then I could make that api happen.
[14:24:54] <fuzzie> but you can't really do that :)
[14:24:55] --> Dark-Star has joined #GemRb
[14:24:55] --- ChanServ gives channel operator status to Dark-Star
[14:26:14] <fuzzie> but i guess i worked quite a bit on trying to fix guiscript bugs, and the GUI API was never the problem
[14:26:58] <fuzzie> well, except for the ridiculous hidegui/showgui mess
[14:27:11] <tomprince> I don't doubt that.
[14:28:35] <fuzzie> The actor API is a problem, though, if only because it references actors by their party IDs.
[14:32:29] <fuzzie> looking through .. why is IncreaseReputation in C++?
[14:36:21] <fuzzie> i wonder if it might be an idea to split the GUIScript.cpp into multiple files
[14:38:01] <tomprince> As long as we aren't generating the code automatically, that would make sense.
[14:38:29] <fuzzie> did you ever find a way to generate code that wouldn't drive us all mad?
[14:40:12] <tomprince> This http://repo.or.cz/w/gemrb.git/commitdiff/0d3877a3bdfcc3add8d2b4e599a2fd74332a01b2 was my most recent attempt.
[14:40:41] <fuzzie> sure, but gccxml is never going to work
[14:41:26] <tomprince> Well, pbg.py uses pygccxml to generate sgi.py there. Then sgi.py can generate sgi.cc using pure python.
[14:41:55] <fuzzie> well, maybe i misunderstand
[14:42:09] <fuzzie> my scenario is: i have a patch to add a method, and i hand it to some end-user.
[14:42:40] <fuzzie> my understanding was that'd fail unless one of us ran the whole gccxml mess.
[14:44:24] <tomprince> Well, you could just edit sgi.py
[14:44:54] <tomprince> The thing is, if the binding are *entirely* autogenerated, then you need something like gccxml.
[14:45:20] <tomprince> But I think that even partially is better than what we have now, where we need to do all the marshalling by hand.
[14:45:20] <fuzzie> well, the core classes are mostly not 'safe' to be bound anyway
[14:45:29] <fuzzie> well, i was wondering about Cython
[14:46:39] <tomprince> I had a look as cython, but my impression is that it was much to verbose to be useful.
[14:47:20] <fuzzie> well, it is in the "partially" pile :)
[14:47:44] --> _pickle has joined #GemRb
[14:48:07] <fuzzie> but yes, as far as i can tell, there is nothing lightweight that is useful
[14:48:11] <tomprince> So is http://repo.or.cz/w/gemrb.git/blob/0d3877a3bdfcc3add8d2b4e599a2fd74332a01b2:/gemrb/plugins/Core/sgi.py
[14:49:05] <fuzzie> well, sure, but where can you add wrapper code there?
[14:50:23] <fuzzie> maybe i should grab that revision and try it
[14:51:25] <tomprince> I don't think I actually wired anything up there.
[14:52:04] <tomprince> What we can do for wrappers, is just write them in pure C++, and just have pybindgen call those wrappers.
[14:52:32] <fuzzie> well, i guess the question is, why bother with pybindgen then?
[14:53:06] <tomprince> Well, for some stuff you don't need wrapper code.
[14:53:44] <tomprince> And for the other stuff, you would be able to write taking and returning C++ types, and letting pybindgen do the marshalling.
[14:53:49] <fuzzie> well, i haven't worked out how pybindgen works yet :) but for it to be worth the change, it surely has to actually make it easier to fix the code
[14:54:36] <fuzzie> and the code which needs fixing is not the stuff which just does marshalling with no error checks etc
[14:55:52] <fuzzie> and if their solution is "yay, C++ exceptions", that is not v.helpful :)
[14:58:10] <fuzzie> although, i wonder if we could use exceptions
[15:01:48] <fuzzie> gcc still bloats code incredibly with RTTI/exceptions on, but i think we already gave up on the low-resource game
[15:09:15] <tomprince> We certainly haven't focused on it.
[15:21:13] <tomprince> I think that as we move logic out of GUIScript.cpp, the code in it will become easier to generate.
[15:24:52] <tomprince> Which is why I put the binding generator project on the back burner.
[15:29:10] <tomprince> We could probably even write a generator by hand for some things.
[15:43:10] <-- _pickle has left IRC (Remote host closed the connection)
[15:48:47] <pupnik_> looks like next handhelds will still be in the 256-512MB range
[15:50:15] <pupnik_> at least avoid RAM-extravagant datastructures/algorithms
[15:55:03] <fuzzie> 256mb is a huge amount, though
[15:55:35] <fuzzie> with some optimisation, you could trivially fit these games in 64mb, which almost everything seems to have available for userspace
[16:10:55] <tomprince> The worst offender, in terms of gratuitous memory usage is probably Interface, which weights in at 96k. Really, everywhere we use char[_MAX_PATH].
[16:19:00] <pupnik_> good. i have seen some projects with ridiculous requirements
[16:21:35] <tomprince> Note: that is just looking at the code, and the gratuitous memory usage.
[16:22:25] <fuzzie> well, storage doesn't really matter
[16:23:42] <fuzzie> i mean, in the sense of those kind of sizes
[16:24:46] <fuzzie> i'm pretty sure the only relevant memory usage culprit at our current scale is TIS files, although i have not actually checked
[16:25:55] <fuzzie> the solution there being "for goodness sake, don't load TIS files from the WED importer"
[16:27:58] <pupnik_> do you implement a basic swap algorithm to handle graphical resources?
[16:28:02] <fuzzie> nope
[16:28:14] <fuzzie> it is all loaded, even when the resources are entirely unused
[16:28:38] <pupnik_> i smell a project
[16:28:42] <fuzzie> yep
[16:28:55] <fuzzie> TIS tiles are the background tiles
[16:30:08] <fuzzie> so they're the biggest problem
[16:31:05] <fuzzie> although it is amplified by the fact that the WEDs are loaded when not needed, i guess
[16:31:18] <pupnik_> is it possible to to more content-aware loading/swapping? can we address individual tiles within a TIS file?
[16:31:56] <tomprince> Yes, and as far as I know we do.
[16:31:57] <pupnik_> not sure if i am making sense where i am going with this
[16:32:00] <pupnik_> ok
[16:32:21] <fuzzie> yes, so you could thereotically handle it far better
[16:32:32] <fuzzie> just really stupid code right now which just loads everything at once
[16:32:33] <pupnik_> lemme find someone who can code it :)
[16:32:46] <fuzzie> even worse, loads it all as Sprite2Ds at once, i think.
[16:34:18] <tomprince> Yes, it loads all the tiles as Sprite2Ds, at least all the tiles that the WED asks for.
[16:34:23] <pupnik_> is this possible to do without introducing unacceptable delays?
[16:34:38] <fuzzie> well, that is a more difficult question :)
[16:35:20] <pupnik_> pannng around an area should never trigger a load from disk imo
[16:35:21] <fuzzie> so i was hoping to get an opengl renderer working first
[16:35:29] <fuzzie> which would make the situation a bit clearer
[16:35:36] <pupnik_> use ogl2.0 then
[16:35:42] <pupnik_> easier to port to ogl es
[16:36:02] <fuzzie> well, my experimenting is just opengl es directly :)
[16:36:15] <fuzzie> because it seems the easiest way to make it work on Android
[16:36:49] <pupnik_> do they support ogles 2?
[16:36:51] <fuzzie> of course the nice thing about such devices is that disk reading really isn't that slow..
[16:37:36] <fuzzie> and, yes,it's all 2.0
[16:37:53] <pupnik_> yeah for seek latency/small reads
[16:37:56] <fuzzie> older android doesn't do it though
[16:38:07] <fuzzie> but for gemrb, i don't think older android devices have a large enough screen
[16:39:14] <pupnik_> indeed, and the game is playable with mostly mouse
[16:39:43] <fuzzie> but memory pressure is a big problem on android
[16:40:45] <-- CIA-24 has left IRC (Ping timeout: 240 seconds)
[16:43:45] <fuzzie> although the whole native situation is a mess
[16:44:04] <fuzzie> no STL, no exceptions, no RTTI..
[16:46:24] <pupnik_> i dislike android
[16:47:22] <pupnik_> but it has many users and good apps
[16:48:20] <fuzzie> if you can get the apps, of course
[16:48:47] <fuzzie> the "Android Market" rather frustratingly being a proprietary binary depending on the whole Google stack
[16:58:58] <tomprince> Massif is telling, (loading a single game+area), we allocate ~40M in GetTile +10M in SDL called from GetTile, 8M in GetAnimationFactory, 5M in MOSImproter
[16:59:27] <fuzzie> you're sure it only loads the one area?
[16:59:44] <fuzzie> those figures sound about right for a single large area, just curious
[17:00:41] <tomprince> Not sure. Just me starting up the game, loading a save game and then quitting.
[17:01:29] <fuzzie> ok. just curious because starting a new bg2 game loads at least two areas, which is where it went wrong for me
[17:03:02] <tomprince> This is PST ar0901, from the savegame 188x at eowyn.cz
[17:15:08] <pupnik_> tomprince: is that loading "completely unnecessary" things?
[17:15:53] <tomprince> I don't know, but probably not.
[17:18:38] <tomprince> I haven't really looked at WEDImporter to see what it loads, but I think that if don't want to load on scrolling, then you need everything it loads.
[17:20:37] <pupnik_> i think that settles it
[17:21:45] <pupnik_> it would probably have been an embarassment to make a data structure that would include unnecessary things
[17:24:41] --> CIA-23 has joined #GemRb
[17:28:48] <fuzzie> yes, if you need the WED at all, you need the whole WED, and enough tiles for whatever your demands are
[17:37:00] <pupnik_> i dont recall these games taking 64MB :)
[17:37:16] <pupnik_> trying to remember if there were loads in areas
[17:45:41] <fuzzie> there were
[17:49:06] <tomprince> I wonder if there is some way we could just mmap things and use that directly, in a way that isn't too ugly, and does make mmaping required.
[17:49:35] <fuzzie> do you think that would help?
[17:50:01] <fuzzie> anywhere you didn't have mmaping is going to be exactly where you're going to be low on memory
[17:50:16] <tomprince> I don't know.
[17:51:13] <tomprince> I was wondering if on embedded flash based systems, a mmap might not cause any memory pressure, if it can just be read in-place.
[17:51:51] <fuzzie> i don't think there are any devices where that happens
[17:51:57] <fuzzie> you never have enough internal NAND
[17:52:37] <tomprince> Then probably not worth it.
[17:59:16] <pupnik_> no biggie, 256MB is the new low end of high end phones
[18:01:21] <tomprince> One advantage to mmap is that it would allow the OS to drop the pages, without needing to write it to swap. And then transparently read it back in as needed.
[18:14:05] <fuzzie> mhm
[18:14:15] <fuzzie> afaik that's what they did in the original engine
[18:14:32] <fuzzie> unpack the TIS into cache, and then it's mmapable
[18:15:00] <tomprince> fuzzie: Two things that bother me are the magic names, and the SetVarAssoc stuff. Not that I have solutions, but that code just feels smelly.
[18:15:03] <fuzzie> it's not quite so trivial because you still have to think about when you create hardware sprites
[18:15:25] <fuzzie> well, you can fix all of that just by passing pointers around
[18:15:37] --> raevol has joined #GemRb
[18:16:06] <fuzzie> but i think you have to keep the SetVarAlloc string path too
[18:16:35] <tomprince> Well, I haven't looked at fixing it yet.
[18:16:55] <tomprince> Although I do have code sitting around here to make the callbacks be functions, rather then using strings.
[18:17:48] <fuzzie> i wrote something along those lines, but went a bit too far, trying to disable calling-by-name entirely
[18:19:50] <tomprince> or.cz/guicallback has what I have right now. It needs refactoring, and the changes on the python side.
[18:19:52] <fuzzie> and that ended up just as ridiculous as using names everywhere, so it ended up buried in the stash
[18:20:32] <tomprince> Right now it resolves the string to a function in GUIScript, but when setting, rather than on call.
[18:21:30] <fuzzie> does it actually work?
[18:21:38] <tomprince> Yes.
[18:23:38] <fuzzie> i am surprised, because i know some code depends on names being resolved at call tme.
[18:24:36] <tomprince> Well, I haven't done extensive tests, so there may be somethings that break.
[18:24:42] <fuzzie> i guess maybe only calls you didn't touch
[18:24:59] <tomprince> Well, the only calls I touched where the eventhandlers.
[18:26:21] <fuzzie> but changing the event handlers seems an obvious improvement :)
[18:27:22] <fuzzie> pupnik_: the trouble with using 256mb like that is that all the phones i've seen use most of that memory for their own thing
[18:27:34] <fuzzie> does maemo really allow apps to use most of that memory?
[18:28:52] <tomprince> Yes, I plan to commit it, but I first want to split it up. The first bit should just be making controls oblivious to how the callbacks are implemented, rather than knowing it is a string.
[18:29:24] <tomprince> And then I also need to change it so that Python actually passes in the function.
[18:34:20] <tomprince> The rest of the calls to RunFunction should probably be changed somehow, so that python tells the C++ side what it should be calling, rather than using magic names.
[18:34:36] <fuzzie> well, that is what i didn't like when i tried
[18:34:52] <fuzzie> you just end up with stupid boilerplate code on the python side.
[18:35:18] <tomprince> Well, if that code is shared ....
[18:36:18] <fuzzie> then you have *hackish* stupid boilerplate code on the python side. :P
[18:36:22] <tomprince> Then it is stupid boilerplate in one place, rather than magic strings litered over the C++ side.
[18:37:08] <fuzzie> well, i would be against that, because you're adding mandatory boilerplate code with no simplicity advantage
[18:44:05] <tomprince> Some of them will go away if/when we move keybinding to python.
[18:44:44] <fuzzie> yes
[18:45:15] <fuzzie> and i imagine some of the EventFlags can go too
[18:45:26] <tomprince> And I think most of the rest could do with some better abstractions.
[18:45:45] <fuzzie> well
[18:45:45] <fuzzie> yes
[18:46:11] <fuzzie> but a stored function pointer is *worse*.
[18:46:36] <fuzzie> because you have just as much hard-coded magic afterwards, but it's even more complicated.
[18:48:08] <fuzzie> and i don't see any candidates for de-hard-coding other than the keybindings and the EventFlags.
[18:48:57] <tomprince> What I was suggesting is that instead of saying, "I need to call this bit of python code, so insert a call here", figure out what the call is trying to do, and abstract that.
[18:49:13] <tomprince> Which sounds very complicated...
[18:49:16] <fuzzie> well, do you have a concrete example?
[18:49:23] <tomprince> No.
[18:49:33] <fuzzie> i'm thinking of the call one of the actions makes to OpenWorldMapWindow, for example
[18:49:50] <tomprince> Yes.
[18:50:03] <fuzzie> and the intent there is that it call a GUI function to open the world map window.
[18:50:40] <fuzzie> and you can't make that better by adding some kind of table lookup, all you'd do is move the lookup from a clear string lookup in the python module to some more complicated lookup elsewhere.
[18:50:48] <tomprince> Well, I would phrase the
[18:50:54] <tomprince> that as
[18:51:26] <tomprince> ... I wound phrase that intent as intiating travel.
[18:51:44] <fuzzie> does that make a difference to the conclusion, though?
[18:52:15] <tomprince> maybe...
[18:53:08] <tomprince> I think so, but I don't know what that conclusion is yet.
[18:53:10] <fuzzie> well, i mean, this is all opinion-based anyway
[18:54:09] <fuzzie> but i guess the summary is: I would be against anything which moves from the current string lookup to some indirect function lookup unless it actually adds an improvement other than just switching a magic string for some other magic identifier.
[18:54:35] <tomprince> Yes.
[18:55:13] <fuzzie> while I feel switching the callbacks to be python functions *does* add an improvement, and also actually simplifies the python side a bit.
[18:56:05] <tomprince> And allows things like binding a callback to a python method, which might allow some things to be simpler.
[18:56:38] <fuzzie> well, i don't think it actually gains you any new functionality
[18:56:51] <fuzzie> you can already just insert something into the python namespace with an arbitary name
[18:58:01] <fuzzie> so with a one-line trampoline you can do whatever you want :-)
[18:58:47] <tomprince> Well, I am just about for a listbox abstraction, for example, the callback would get a self parameter, if it was a method.
[18:58:51] <fuzzie> there is a disadvantage, which is that you can no longer automatically override functions on a screen-specific basis.
[19:00:11] <fuzzie> but am pretty sure we don't need that.
[19:00:46] <fuzzie> tomprince: that doesn't work, right?
[19:01:06] <fuzzie> i mean, if you don't use a trampoline, your callback call fails because you didn't pass it the parameter
[19:01:37] <tomprince> No, if you bind to object.method, python handles the trampolining for you.
[19:02:11] <tomprince> object.method returns a bound method, which passes object as self when called.
[19:02:24] <fuzzie> oh, you're right. well, okay, you get to avoid trampolining, but still not new functionality. :)
[19:03:09] <fuzzie> what i mean is, the only gain here is that you can avoid having to construct the trampoline
[19:04:03] <fuzzie> although having said that, i see we're actually doing on-load dictionary horrors
[19:04:20] <fuzzie> so slightly more annoying than i'd envisaged
[19:07:59] <tomprince> What horrors?
[19:09:19] <tomprince> I guess there isn't a whole lot of gain with the way the code is right now, because we always just redraw the entire window when anything is updated.
[19:12:03] <tomprince> And if you are doing that, it doesn't matter what triggered it.
[19:15:49] <tomprince> And, depending on how you set things up, you wouldn't need a SetVarAssoc, just to see which button got pressed, because you could just get it from self.
[19:33:22] --> _pickle has joined #GemRb
[19:35:48] <tomprince> Random question: Anyone know why we disallow recursive event handlers?
[19:47:28] <tomprince> And if we ever actually delete a control in its event handler.
[19:47:52] <fuzzie> yes, we do
[19:48:57] <tomprince> The reason I ask, is that I am thinking of passing paramaters in the event handler, and I don't want to duplicate Control::RunEventHandler, for the possible options.
[19:51:06] <tomprince> Do you know about recursive event handlers?
[19:51:52] <fuzzie> i imagine recursive event handlers are for simplicity
[19:52:05] <fuzzie> if i were writing the code, i would just abort() on an attempt to do such a thing
[19:52:09] <fuzzie> but i don't know what's in gemrb atm
[19:53:34] <tomprince> We just report an error, and ignore it. I was wondering why we don't just let the call through.
[19:53:41] <fuzzie> because it's a huge source of bugs
[19:54:43] <fuzzie> i mean, i dont know about gemrb in particular, but that is the usual reason that recursive calls are banned from GUI frameworks.
[19:56:46] <fuzzie> we should probably also not be calling into python from some of the places we do for similar reasons, but i think most/all of that will be resolved with the message queue.
[20:03:15] <tomprince> ?
[20:03:37] <fuzzie> well
[20:03:40] <fuzzie> the C++ side is not re-entrant.
[20:04:38] <fuzzie> so you only want to be calling into python from places where you're *sure* that the whole call stack above you is not going to get confused by python calling back in somewhere and messing with things
[20:04:39] --> Maighstir_laptop has joined #GemRb
[20:05:04] <fuzzie> and this is not the case for python calls made from within actions, for example
[20:06:26] <tomprince> Well, perhaps we could simply make the C++ side reentrant.
[20:06:46] <fuzzie> but then for recursive event handlers, you have to make the python side reentrant too
[20:07:47] <tomprince> Well, python itself is reentrant.
[20:07:50] <fuzzie> and that makes it far more complicated to code.
[20:08:09] <fuzzie> i mean reentrant in the sense of "doing the right thing", not in the sense of "not crashing".
[20:08:48] <fuzzie> if you just abort() instead of letting it happen, it is a lot more obvious than just allowing the inevitable logic bugs to occur.
[20:09:51] <tomprince> It wouldn't suprise me if we were mostly reentrant now.
[20:10:00] <fuzzie> sure, but how does that help?
[20:10:47] <tomprince> Well, I think things would just work.
[20:10:50] <fuzzie> i mean, you could make it work properly, but you make it a lot more difficult to code reliably, and this isn't even a "you can take responsibility for all GUIScripts", because they're intended to be moddable.
[20:11:45] <fuzzie> because everyone coding anything has to bear in mind that all their variables, the game state, globals, etc could change from under them.
[20:24:35] <raevol> i have too short an attention span right now to catch up on this discussion but i wanted to say that i love you guys
[20:24:38] * raevol huggles all around
[20:27:02] <raevol> k gotta run bye
[20:27:08] <fuzzie> are you the same raevol on openmw forums? :)
[20:27:08] <-- raevol has left IRC (Quit: Leaving.)
[20:27:11] <fuzzie> oh, too late
[21:06:19] --> cubathy has joined #GemRb
[21:54:04] --> pupnik has joined #GemRb
[21:59:45] <-- cubathy has left IRC (Quit: Leaving)
[22:44:10] <-- pupnik has left IRC (Quit: Lost terminal)
[22:45:40] <Lightkey> fuzzie: oh and I got something called Creatures Abenteuer, apparently targeted at kids - any good?
[22:46:09] <Lightkey> dated 1999
[22:47:26] <fuzzie> heh :) it is really targeted at young kids, not sure it'd be more than 5 minutes distraction for anyone above the age of 10 :)
[22:48:59] <Lightkey> I'm young at heart
[22:49:37] <Lightkey> I meant more like compatibility with your little side project :p
[22:51:44] <fuzzie> i haven't actually tried it in years, but i think it's a challenge to avoid bugs just enough to escape the first room. :( but it's cute, run it under wine for the 5 minutes! :)
[22:52:24] <Lightkey> yes, yes, when I get the parts together for my x86
[22:54:05] <Lightkey> the ole Mac mini suffers from fail of DMA and maybe HDD apparently.. does not sound good, need a new desktop soon
[22:54:18] <Lightkey> five years already..
[22:54:33] <Lightkey> time flies by
[23:08:02] <pupnik_> yes :(
[23:34:16] * Lightkey is lausching to Depeche Mode - Enjoy the Silence
[23:37:12] <pupnik_> hehe
[23:37:58] * pupnik_ is sitting on the porch listening to the moths bump into the lamp
[23:47:56] <pupnik_> but i am old as unix itself