[00:08:40] --> |Cable| has joined #GemRb
[00:14:51] --> Genrazn has joined #GemRb
[00:27:55] --> tomprince_loki has joined #GemRb
[00:31:00] <Genrazn> hey tom
[00:31:47] <tomprince_loki> Hello.
[00:38:01] <Genrazn> What you up to?
[00:38:30] <Genrazn> Curious are you different from the other tomprince?
[00:38:47] --> Gekz_ has joined #GemRb
[00:40:15] <tomprince_loki> No.
[00:40:31] <tomprince_loki> Studying ways of binding C++ to python.
[00:40:48] <tomprince_loki> IRC only allows one machine to logged in with a given name.
[00:40:55] * Genrazn nods
[00:41:34] <Gekz_> lol @ language binding
[00:41:36] <Gekz_> it's a pain in the anus
[00:43:20] <tomprince_loki> There seem to be some not bad solutions out there. The problem is, if you want to automate it, you need gccxml, which isn't actively developed.
[00:46:48] <tomprince_loki> I have actually just started playing with pybindgen, which actually look very nice.
[00:47:30] <tomprince_loki> Actually, in terms of gccxml, we are almost at the point where it could be replaced, since GCC supports plugins now, and the C++ support of clang is almost ready.
[00:48:48] <Gekz_> lol cool
[00:50:36] <tomprince_loki> The interesting thing is that clang already has a (buggy) xml dump option that is very similar in spirit to the gccxml one.
[01:07:33] <Genrazn> Too bad I know little of Programming
[01:07:42] <Genrazn> words that have no meaning to me heh
[01:20:13] <Gekz_> tomprince_loki: what is the xml dump for
[01:21:50] <tomprince_loki> So that you don't need to describe the C++ interface explictly. C++ is notoriously hard to parse, so interface generation tools use gccxml to get an easily parsed description of the interface.
[01:25:17] <Gekz_> ..k
[01:25:56] <tomprince_loki> Rather than having to write a description of all the objects and functions and variables you want to expose, you just let gccxml look a the description that you already have for C++. And then it turns it more or less automatically into, for example, code to interface to python.
[01:29:17] <-- Gekz_ has left IRC (Quit: This computer has gone to sleep)
[01:30:39] <tomprince_loki> It looks like GUILoad can be unified across bg1, bg2 and iwd.
[01:31:34] <tomprince_loki> And I wonder why TopIndex is stored in a Core, rather just using a python variable.
[01:36:45] <Genrazn> Curious tom, is it possible to implement the ability to... whats the word im looking for. Like able to tell a spellcaster to cast a variety of spells in order without having to keep a eye on it?
[01:37:00] <Genrazn> Like telling him to cast magic missile then fireball right after it when it can
[01:52:06] <tomprince_loki> There are spell sequencers in bg2. There are all the AI scripts.
[01:52:13] <tomprince_loki> Other than that, no.
[01:52:34] <tomprince_loki> That isn't to say that it couldn't be implemented.
[02:05:43] <-- Enverex has left IRC (Ping timeout: 260 seconds)
[02:10:35] <tomprince_loki> How I think SaveGames should be exposed to python: http://pastebin.org/128272
[05:44:55] --> Nomad010 has joined #GemRb
[05:58:15] --> nomad has joined #GemRb
[05:58:27] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[06:57:29] <-- nomad has left IRC (Ping timeout: 258 seconds)
[06:59:11] --> lynxlynxlynx has joined #GemRb
[06:59:11] --- ChanServ gives channel operator status to lynxlynxlynx
[07:05:46] --> nomad has joined #GemRb
[07:35:40] --> edheldil has joined #GemRb
[07:35:41] --- ChanServ gives channel operator status to edheldil
[07:36:04] <edheldil> good morning everybody
[07:52:45] <fuzzie> morning
[07:59:22] <fuzzie> tomprince_loki: doing that on the C++ side would be serious overengineering, though.
[08:01:11] <fuzzie> I mean, looking at this from the current "fixing the code" perspective.
[08:04:02] <fuzzie> And most things on the Python side can be unified across the games, just a question of someone familiar taking the time to make sure.. see all the now-shared levelup code.
[08:09:04] <fuzzie> All of the GUILOAD scripts seem like a candidate; if they're to be integrated at all, a few differing control values shouldn't be a problem to deal with.
[08:15:58] <edheldil> what's the topic?
[08:16:24] <fuzzie> well, on that last bit: the bg1/bg2/iwd GUILOAD files are almost identical (one line difference or so).
[08:17:35] <fuzzie> on the former bit: http://pastebin.org/128272
[08:17:50] <fuzzie> both things tomprince said 6 hours ago, so :)
[08:20:44] <edheldil> so you objected against objectifying the save games?
[08:21:04] <fuzzie> Well, it seems easier done by just adding a wrapper on the python side.
[08:23:14] <edheldil> I thought that wjp objectified buttons some time ago, no? Or was it also done in python only?
[08:24:31] <fuzzie> Python only. Very clever trick. :)
[08:25:14] <fuzzie> There are much cleverer ways to wrap objects, but they all pull in big dependencies, I think.
[08:30:10] <edheldil> in the end, for the (theoretical) Lua extension, the C++ objects would have to be rewritten anyway, I fear
[08:30:42] <edheldil> but, frankly, converting GUIScript API to objects was an idea I had also
[08:30:55] <fuzzie> Well, tomprince has been starting to move code out of GUIScript.cpp and into the core, which makes sense.
[08:31:03] <edheldil> it's so haphazard now that it hurts
[08:32:18] <fuzzie> But trying to write Type code against the python API is not much fun.
[08:35:01] <edheldil> yes, GUIScript was/is too fat, preventing other language plugins
[08:35:06] <edheldil> hmm
[08:36:05] <-- |Cable| has left IRC (Remote host closed the connection)
[08:37:35] * edheldil commanded his sinister botnet to start pinging
[08:38:14] <fuzzie> Some things, like SetupEquipmentIcons, SetupSpellIcons and SetupControls, really need some thought.
[08:38:48] <fuzzie> There's hard-coded SetButtonBAM calls in there, even.
[08:39:25] <fuzzie> Definitely no good for modders.
[08:41:36] <edheldil> well, buttons expect BAM for their 4 images
[08:42:03] <fuzzie> This is hard-coding BAM names on the C++ side, I mean.
[09:24:54] --> raevol has joined #GemRb
[10:19:38] <-- Gekz has left IRC (Read error: Connection reset by peer)
[10:19:47] --> Gekz has joined #GemRb
[10:23:07] <-- raevol has left IRC (Quit: Leaving.)
[10:59:44] <-- Gekz has left IRC (Read error: Connection reset by peer)
[10:59:47] --> Gekz_ has joined #GemRb
[11:33:38] <tomprince> fuzzie: ignoring the implications for the C++ side what do you think of that python interface?
[11:39:13] <wjp> what do you envision things like SaveGames[i].GetPortrait(j) returning?
[11:39:48] <tomprince_loki> I hadn't got that far yet. A Sprite, or and ImageMgr.
[11:39:49] <wjp> a small struct that is handled in a special case in SetPicture?
[11:40:43] <tomprince_loki> I'd rather not have a speicial case ....
[11:41:15] <wjp> I think I'd prefer two special cases to having to export general image functionaliy to python, though
[11:43:14] <tomprince_loki> In the short term, and for this particular thing: yes.
[11:43:24] <tomprince_loki> In the long run though?
[11:44:06] <wjp> I don't know, but I'd prefer designing such a feature when we have sufficient use for it to justify the effort
[11:44:38] <tomprince_loki> Well, I was just throwing that as something to aim for.
[11:45:36] <tomprince_loki> I think that in the long run, it would be good to have the entire python interface like that .... I sound like a broken record that. :)
[11:46:15] <wjp> I'm all for making it more OO than it currently is
[11:46:45] <tomprince_loki> I realise that people have issues with the difficulty/dependencies required for the C++ side, but I was curious about peoples reaction to the resulting python code.
[11:48:21] <wjp> oh, I would prefer this syntax to the current one
[11:52:05] <wjp> and it wouldn't even be that hard to implement if we implement the special cases inside SetPicture
[11:52:23] <tomprince_loki> Probably for a first pass, I would actually have a seperate function for SetPicture. That takes a Sprite2D*, but just have that exposed as a black box.
[11:53:30] <tomprince_loki> Actually the trickier bit is exposing the SaveGames as a python sequence.
[11:53:44] <wjp> I was thinking of a python class SaveGame that is created from C++ and basically wraps a savegame index
[11:53:54] <wjp> and then just create a list of those from C++
[11:54:12] <wjp> SaveGame's methods would then call the current C++ API functions
[11:54:37] <wjp> and for GetPortrait it would return a special-purpose class that is handled by Button.SetPicture (in python)
[11:54:47] <wjp> that would require the least work on the C++ side of things, I think
[11:55:08] <wjp> (so SaveGame is implemented entirely in python)
[11:55:09] <tomprince_loki> Well, the original motivation was that I wanted to fix the savegame index stuff, and that really requires replacing the savegame index with something stable.
[11:55:27] <tomprince_loki> And, I would like to avoid implementing more stuff like that in python.
[11:56:43] --> raevol has joined #GemRb
[11:56:49] <tomprince_loki> But, I'll code something up, and see what people think.
[11:57:00] <wjp> more stable than the index? in which sense exactly?
[11:57:36] <tomprince_loki> Well, I was think of just returning a list of C++ savegame objects.
[11:57:53] <tomprince_loki> Or that very least, (slot, savename) pairs.
[12:01:34] <tomprince_loki> The problem with the index, is that it is simply an index in to a list that gets regenerated, and that it doesn't have an meaning in terms of the savegame it is pointing to.
[12:03:04] <fuzzie> I have no problem with the interface, but I do think doing it on the C++ side is overcomplication.
[12:03:38] <fuzzie> Having caught up: what wjp said.
[12:05:23] <tomprince_loki> Well, let me have a go at it, and see what you think.
[12:05:38] <tomprince_loki> .... I will anyway. :)
[12:06:30] <wjp> I actually kind of like python's ability of creating OO interfaces on top of procedural ones
[12:07:04] <wjp> because it allows us to keep the actual interface very straightforward, but still provides a 'proper' interface to the scripts
[12:07:06] <fuzzie> My main worry is that we'll end up with a huge patch that we can't apply.
[12:08:19] <tomprince_loki> Well, I don't want it to be a huge patch.
[12:09:12] <wjp> but I can see the point in changing the interface to C++ to a more direct slot name than the current index
[12:10:27] <fuzzie> Yes.
[12:11:14] <tomprince_loki> Actually the reason I posted that was I couldn't find a good way to expose that to python, without giving returning to python a sequence. Otherwise, you need to have an index to iterate jus to get all the slotnames.
[12:11:54] <tomprince_loki> Which I desperately want to avoid.
[12:11:59] <fuzzie> I mean, I can see the motivation for putting the object stuff on the C++ side, I just don't see any situation where it'll be a tidier design in practice.
[12:13:16] <fuzzie> But my earlier comments about using an index were purely motivated by wanting to minimise the patch size.
[12:13:29] <wjp> what's the problem with returning a list/sequence to python?
[12:17:48] <tomprince_loki> or.cz/pybindgen: That is just me playing around ...
[12:18:03] <tomprince_loki> pbg.py generated sgi.py automatically, using gccxml.
[12:18:36] <tomprince_loki> sgi.py generated sgi.h using pure python.
[12:19:23] <tomprince_loki> s/sgi.h/sgi.cc/
[12:20:25] <tomprince_loki> It doesn't do what I want to do ... I have changed the C++ side yet at all, but just as a demonstration of pybindgen.
[12:23:19] <-- nomad has left IRC (Disconnected by services)
[12:23:37] --> Nomad010 has joined #GemRb
[12:36:23] <-- Gekz_ has left IRC (Read error: Connection reset by peer)
[12:36:26] --> Gekz has joined #GemRb
[12:36:30] --> Gekz_ has joined #GemRb
[12:43:18] <tomprince_loki> Anyway, I'll post something when I have something real to show.
[12:44:21] <Gekz> tomprince_loki: do you have a publicly accessible CV?
[12:44:45] <tomprince_loki> No. Nor a privately accesible CV. :)
[12:45:22] <tomprince_loki> Why?
[12:45:55] <Gekz> ah
[12:46:00] <Gekz> I wanted to know what you've studied
[12:46:02] <Gekz> your home address
[12:46:04] <Gekz> previous work experience
[12:46:09] <Gekz> so I could steal your identity and be awesome
[12:46:51] <tomprince_loki> Well, I am working on my PhD, in math. Abstract homotopy theory/abstarct category theory.
[12:47:36] <tomprince_loki> About the only work experience I have is working on the graphing language Asymptote.
[12:47:49] <fuzzie> We really do attract the mathematicians.
[12:48:07] <wjp> :-)
[12:48:30] * wjp has been meaning to look at Asymptote closer
[12:48:48] <Gekz> I suck at math
[12:48:53] <Gekz> :<
[12:49:05] <Gekz> basically due to teachers constantly telling me I cant achieve, without actually teaching me anything
[12:49:08] <Gekz> and not helping me when I got stuck
[12:49:11] <Gekz> <3 Australian education system
[12:49:19] <Gekz> I was two years ahead in maths when I was 12
[12:49:23] <Gekz> I was two years behind when I was 17
[12:49:41] <Gekz> and it's partially my fault for sucking, however, a student needs guidance >_>
[12:49:44] <tomprince_loki> :(
[12:49:54] <Gekz> and I dont learn rote very well
[12:49:58] <Gekz> I can memorise languages pretty easily
[12:50:25] <Gekz> je peux parler en francais tres mauvais mais je parle avec mes amis souvant
[12:50:36] <Gekz> I never studied french, just turned up
[12:50:44] <Gekz> and next year I'm majoring in French in International Studies
[12:51:24] <tomprince_loki> It wouldn't suprise me if part of the problem is that many math teachers don't understand math well enough to teach it well.
[12:51:44] <tomprince_loki> I was lucky and a couple of very good ones.
[12:51:59] <Gekz> dude
[12:52:02] <Gekz> I had a footballer
[12:52:03] <Gekz> for 3 years
[12:52:04] <Gekz> :<
[12:52:15] <Gekz> I seriously cant do a quadratic to save my life
[12:54:19] <CIA-43> GemRB: 03fuzzie * r5492d5866761 10gemrb/gemrb/GUIScripts/bg1/ImportFile.py: add a CancelPress function back into bg1's ImportFile
[12:55:03] <fuzzie> (someone should review that one)
[12:55:43] <tomprince_loki> Well, quadratics per se, are all that important.
[12:56:20] <tomprince_loki> s/are/aren't/
[12:56:39] <tomprince_loki> I seem very bad at including the proper negatives here.
[12:57:03] <edheldil> it's the surface integrals that matter ;-)
[12:57:35] <tomprince_loki> In my experience, most of mathematics shouldn't be about rote, but about connections and paterns.
[13:04:15] <tomprince_loki> See Isaac Asimov's "Realm of Numbers" for the patterns and connections in counting and arithematic
[13:07:30] <Gekz> tomprince_loki: is it long
[13:07:43] <tomprince_loki> No.
[13:07:43] <Gekz> also, where are you located?
[13:07:49] <Gekz> canada
[13:07:49] <tomprince_loki> Canada.
[13:07:53] <Gekz> I can whois like apro
[13:08:01] <Gekz> when I grow up, I'll be a Microsoft engineer
[13:08:05] <Gekz> :B
[13:08:39] <tomprince_loki> Except that that email address I will have for life, not matter where I am ...
[13:08:51] <Gekz> lolol
[13:12:22] <CIA-43> GemRB: 03fuzzie * r2a4d95464ce7 10gemrb/gemrb/GUIScripts/ (bg1/GUISAVE.py bg2/GUISAVE.py): bg1/bg2 GUISAVE: close window correctly
[13:12:33] <fuzzie> Depressing when I can't even save a game without hitting a bug, especially one which I introduced..
[13:17:34] <Gekz> lol.
[13:35:56] <-- lynxlynxlynx has left IRC (Ping timeout: 245 seconds)
[13:36:28] --> Brendan__ has joined #GemRb
[13:36:39] --> lynxlynxlynx has joined #GemRb
[13:36:40] --- ChanServ gives channel operator status to lynxlynxlynx
[13:40:45] <-- Gekz_ has left IRC (Ping timeout: 265 seconds)
[13:59:21] <-- raevol has left IRC (Quit: Leaving.)
[14:22:10] <CIA-43> GemRB: 03lynxlupodian * r13494a0c4d3d 10gemrb/gemrb/docs/en/Release.txt: Release.txt: noted who has access to the mod news forum
[14:23:30] <edheldil> lynxlynxlynx: can you help me to get an access to the wiki?
[14:23:53] <lynxlynxlynx> yes, you disappeared yesterday
[14:24:08] <lynxlynxlynx> the mail points to your domain
[14:24:16] <lynxlynxlynx> if you want a new pass ->pm
[14:25:21] <fuzzie> is our inventory intended to pause the game?
[14:25:39] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[14:25:41] <lynxlynxlynx> in some games, yes
[14:25:50] <fuzzie> am looking at bg1.
[14:27:30] <lynxlynxlynx> i don't remember
[14:27:35] <fuzzie> i just wasted 20 minutes trying to debug that learning-from-scrolls thing, turns out that the learn effect is delayed until you unpause.
[14:27:45] <fuzzie> (presumably that is a bug)
[14:28:04] <lynxlynxlynx> yeah, you can do all sorts of funnies with items that have effects
[14:28:39] <fuzzie> i just can't see where a pause would happen.
[14:28:42] <lynxlynxlynx> i got about -70 ac by repeatedly reequipping the helm of balduran :)
[14:29:24] <fuzzie> Oh, I bet it's not pausing at all, this logic is in the Draw() function. Ack.
[14:29:48] <fuzzie> in any case: learning from scrolls does work.
[14:29:53] <fuzzie> http://nowhere.ws/dump/gemrb-bugs.txt <- I am going through this.
[14:32:58] <lynxlynxlynx> yeah, learning works
[14:33:58] <lynxlynxlynx> * sometimes there is gold to loot, but when one clicks on it, nothing happens <-- something like this happened to me semiregularly during the iwd playthrough and is noted there
[14:34:10] <fuzzie> well, it gets confusing when 20 attempts with 100% chance apparently make no difference to your spellbook :)
[14:35:11] <lynxlynxlynx> I think even 25 int still has 99% :)
[14:35:11] <fuzzie> I fixed the HP regain and Import cancel button, most of the rest are on the todo, I think.
[14:35:18] <fuzzie> yes, I cheated :-)
[14:35:36] <lynxlynxlynx> yeah, the only really new thing is the cure light wounds on rest funny
[14:35:57] <fuzzie> The fog-of-war thing is presumably also code being in Draw() when it shouldn't be.
[14:39:20] <lynxlynxlynx> edheldil: so?
[14:53:53] --> tomprince_loki has joined #GemRb
[15:34:42] <-- tomprince_loki has left IRC (Read error: No route to host)
[15:35:25] --> tomprince_loki has joined #GemRb
[15:39:31] <tomprince_loki> What is happening in Draw that shouldn't be? It looks like DrawWeather should be split in two, at the if (!update). The ticking of DisplayTextTime. The population of queue[PR_SCRIPT] in Map::GenerateQueues.
[15:39:47] <tomprince_loki> That last is probably the big one.
[15:40:44] <tomprince_loki> fuzzie: Probably somewhat related, what requirements do you envision for the message queue system ...
[15:43:51] <fuzzie> "apply effect to actor", "start cut scene".
[15:44:46] <fuzzie> and "clear script actions".
[15:44:56] <tomprince_loki> Well, those are the things to put in the queue ...
[15:44:59] <fuzzie> Those are the ones I have in my branch.
[15:45:12] <fuzzie> That is about all I have re: thoughts.
[15:46:04] <fuzzie> They've got to be ordered, they've got to be serialisable. But a simple queue of structs would suffice.
[15:47:12] <tomprince_loki> So list of function to run each tick, that get run at a specific point in the tick?
[15:47:22] <tomprince_loki> And that can be added to anywhere?
[15:47:23] <fuzzie> Well, with data.
[15:47:33] <tomprince_loki> Well, function objects. :)
[15:47:56] <fuzzie> I have it implemented as subclasses of a Message class with an Apply() function.
[15:48:23] <fuzzie> Which I think is also how the original engine implements it.
[15:48:31] <fuzzie> But it's not a fixed design.
[15:49:25] <tomprince_loki> I was wondering if it might make sense to run everything off the queue. Or at least more stuff the we run manually right now.
[15:49:45] <tomprince_loki> Note: I haven't really looked at the gamescript side of things.
[15:49:57] <fuzzie> You'd probably want a seperate queue.
[15:51:31] <tomprince_loki> I had in my head that Apply would return a bool, and would keep things in the queue or not, based on the return value.
[15:51:50] <fuzzie> The context here is: the message queue is serialised for multiplayer sync.
[15:51:59] <tomprince_loki> But you may be right that there enough different things that need to be inserted at different places, that more than one would make sense.
[15:52:02] <tomprince_loki> Ah.
[15:52:40] <fuzzie> You could obviously just serialise some things, but I imagine it's not worth trying to keep all the 'categories' in that one queue.
[15:52:51] <fuzzie> But I haven't thought about it. :)
[15:53:31] <tomprince_loki> You might be right. But if we had multiple queues, it would be good if they could share an implemenation, and just be different instances.
[15:53:57] <fuzzie> Well, I'm not sure the game message queue would even be complicated enough to need an implementation.
[15:55:10] <tomprince_loki> Well, even if the implemnation was just std::list<Message>, and function to iterate over one, calling apply on each one.
[15:58:42] <fuzzie> *nod*
[15:59:22] <fuzzie> My plans for our message implementationwere very much along the lines of getting something trivial added, continue to add things to it, and then step back and rethink it once we've added a reasonable percent of the necessary messages.
[15:59:52] <tomprince_loki> That is a reasonable approach.
[16:01:29] <fuzzie> If you're looking at a more generic handling queue, the QuitFlag would be an obvious start, I guess.
[16:02:01] <fuzzie> The flags being there solely to make sure they happen at the right time.
[16:02:29] <tomprince_loki> That makes sense.
[16:02:52] <tomprince_loki> I would probably be inclined to implement it piecemeal as well.
[16:03:08] <edheldil> also keypresses, perhaps?
[16:03:32] <tomprince_loki> Although, looking at what all one might want to acheive might give some directions on what design decisions to make.
[16:03:35] <tomprince_loki> Yes.
[16:03:48] <fuzzie> Well, there's not much need to sync keypresses at all, I think.
[16:04:06] <fuzzie> There's the EF_ flags for Interface::HandleEvents..
[16:05:18] <fuzzie> I guess that is where it becomes a little more complicated, because you only want the functions to be called once.
[16:05:39] <edheldil> not sync, perhaps, but it allows you to put keys to queue and do not worry about who might be interested in them. Or perhaps not keys, but keyactions or st. like that
[16:06:06] <tomprince_loki> That was exactly my thought.
[16:06:11] <fuzzie> Comes back to the arguments about where keys should be handled, I guess.
[16:06:43] <fuzzie> I mean, not that a generic "event queue" would ever be a bad idea.
[16:07:05] <edheldil> and a queue would increase keypress latency, which is bad for UI responsiveness ...
[16:07:22] <fuzzie> The UI is not going to respond until the next frame anyway:)
[16:08:32] --> tombhadAC has joined #GemRb
[16:16:09] <-- tombhadAC has left IRC (Ping timeout: 276 seconds)
[16:31:20] <fuzzie> Oh, right, the fog thing is just because the map control doesn't ever redraw itself.
[16:37:13] <-- tomprince_loki has left IRC (Ping timeout: 264 seconds)
[16:39:12] --> tomprince_loki has joined #GemRb
[16:45:39] <-- tomprince_loki has left IRC (Quit: tomprince_loki)
[17:17:38] --> kettuz has joined #GemRb
[17:22:52] <fuzzie> edheldil: any idea why you drew the fog onto the sprite and not the display?
[17:25:59] <fuzzie> http://fuzzie.org/nfs/gemrb/draw_fog_live.txt makes the obvious fix, if someone wants to ok it.
[17:40:02] --> Edheldil_ has joined #GemRb
[17:59:49] --> |Cable| has joined #GemRb
[18:18:22] --> Genraznx has joined #GemRb
[18:20:29] <-- Genrazn has left IRC (Ping timeout: 246 seconds)
[18:37:42] --> tomprince_loki has joined #GemRb
[18:42:03] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[18:44:53] <tomprince_loki> I wonder if it was dwarn on the MOS, you would only need to redraw when it gets update, rather than every tick. Although, that doesn't look like what the code actually does.
[18:45:39] <fuzzie> Well, the old code draws once, which I imagine is efficient.
[18:46:20] <fuzzie> But the exploring code is kinda slow as it is, I wouldn't want to add more comparisons to it.
[18:50:53] <fuzzie> So, bla. :)
[18:54:20] <-- kettuz has left IRC (Quit: Leaving)
[19:02:14] <-- anji_ has left IRC (Read error: Operation timed out)
[19:04:04] --> Genrazn has joined #GemRb
[19:04:37] <tomprince_loki> Is that Map::UpdateFog?
[19:05:08] <fuzzie> yes
[19:06:23] <fuzzie> The code probably needs an #ifdef LOW_MEMORY and an alternative temporary form which isn't crazy, but for another time.
[19:06:43] <-- Genraznx has left IRC (Ping timeout: 246 seconds)
[19:07:21] <tomprince_loki> What is VisibilityMasks?
[19:07:32] <fuzzie> (ExploreMapChunk is the relevant bit here, I suppose.)
[19:07:54] <tomprince_loki> Yes.
[19:09:30] --> anji has joined #GemRb
[19:09:41] <-- anji has left IRC (Client Quit)
[19:09:52] <fuzzie> The visibility masks are a lookup table for exploring in the right order, or somesuch thing.
[19:10:56] <fuzzie> The algorithm is still not quite right, so I am wary of touching it myself.
[19:11:08] <fuzzie> zefklop was working on it, I think..
[19:14:30] --> anji has joined #GemRb
[19:21:28] <CIA-43> GemRB: 03fuzzie * r3bda35d7eba5 10gemrb/gemrb/plugins/Core/Video.cpp: endian-fix SpriteScaleDown
[19:36:38] <fuzzie> hrm, that is *not* the right fix, apparently.
[19:37:11] <fuzzie> i was misled by my test cases working.
[19:38:11] --> raevol has joined #GemRb
[19:44:42] <lynxlynxlynx> :s
[19:51:33] <tomprince_loki> http://www.gamedev.net/reference/articles/article729.asp
[19:51:59] <fuzzie> Is that what this is doing?
[19:52:32] <tomprince_loki> No.
[19:52:36] <fuzzie> Doesn't seem very likely to work.
[19:53:31] <-- raevol has left IRC (Quit: Leaving.)
[19:54:55] <fuzzie> I forget what was wrong with the existing one, I think it had problems with being underneath walls.
[19:57:39] <tomprince_loki> Yes.
[19:57:58] <tomprince_loki> I know that if you walk right up to a wall, sometimes you can't see anything.
[20:03:59] <tomprince_loki> Why don't you think it will work?
[20:04:30] <fuzzie> Because it doesn't seem to have any mechanism for dealing with things like the walls.
[20:06:45] <fuzzie> I mean, it seems like the kind of thing which is easy to try.
[20:08:02] --> Genraznx has joined #GemRb
[20:08:25] <fuzzie> Mayb e I'm missing something. Bit distracted.
[20:11:19] --> Gekz_ has joined #GemRb
[20:11:26] <-- Brendan__ has left IRC (Read error: Connection reset by peer)
[20:11:39] <-- Genrazn has left IRC (Ping timeout: 260 seconds)
[20:28:15] <CIA-43> GemRB: 03fuzzie * r2c317e7278f8 10gemrb/gemrb/plugins/ (Core/Video.cpp SDLVideo/SDLVideo.cpp): mostly revert last change, put endian fix in the right place
[20:28:16] <fuzzie> I don't think there's any possible way those other bits could be correct, but I could've sworn they were, so there are probably gremlins lurking and I will not touch.
[20:28:36] <fuzzie> The #ifdefs will presumably act as a warning to later adventurers.
[21:04:32] <lynxlynxlynx> http://img202.imageshack.us/img202/2002/biowareborder.jpg
[21:08:52] --> Maighstir_laptop has joined #GemRb
[21:09:11] <Lightkey> what is that referring to?
[21:09:32] <fuzzie> The Bioware 'community' Bazaar being US-only.
[21:10:07] <Lightkey> what's that
[21:13:25] <fuzzie> I don't know :)
[21:16:07] --> cfchris6 has joined #GemRb
[21:17:31] <-- cfchris6_ has left IRC (Read error: Operation timed out)
[21:22:16] <lynxlynxlynx> they had a counter on the webpage
[21:22:27] <lynxlynxlynx> they hyped everyone
[21:22:48] <lynxlynxlynx> and then it turns out it's just something silly AND limited to the usa
[21:31:46] <-- Maighstir_laptop has left #GemRb
[22:16:51] --> Maighstir_laptop has joined #GemRb
[22:28:20] <fuzzie> Hooray, I think I have the PS:T map working properly.
[22:43:10] <fuzzie> Except it breaks iwd2..
[22:50:08] <Lightkey> harr
[22:54:47] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[23:08:16] <-- Edheldil_ has left IRC (Remote host closed the connection)
[23:11:25] <fuzzie> Oh, it doesn't break iwd2, iwd2 is already broken..
[23:11:48] <Lightkey> nothing new in the west
[23:22:36] <CIA-43> GemRB: 03fuzzie * rfb9303e458df 10gemrb/gemrb/plugins/ (4 files in 2 dirs): try fixing the repaint problems with the pst map
[23:22:39] <CIA-43> GemRB: 03fuzzie * r77cbb237b545 10gemrb/gemrb/plugins/Core/MapControl.cpp: render map flags at the right place
[23:22:40] <CIA-43> GemRB: 03fuzzie * rd90e18879925 10gemrb/gemrb/plugins/Core/ (MapControl.cpp MapControl.h): update fog-of-war on the map
[23:48:31] <-- tomprince has left IRC (Remote host closed the connection)
[23:56:11] --> tomprince has joined #GemRb