[00:39:41] <-- barra_desktop has left IRC ("Verlassend")
[01:37:46] --> tomprince has joined #gemrb
[02:21:09] <-- tombhad-AC has left IRC ("Verlassend")
[02:34:11] <-- Maighstir has left #gemrb ()
[04:18:07] <-- raevol has left IRC ("Leaving.")
[06:43:56] <-- tomprince has left IRC (Read error: 113 (No route to host))
[06:46:03] --> Maighstir has joined #gemrb
[07:57:26] <-- Maighstir has left IRC (Remote closed the connection)
[08:30:26] --> Maighstir has joined #gemrb
[09:26:14] --> lynxlynxlynx has joined #gemrb
[09:26:15] --- ChanServ gives channel operator status to lynxlynxlynx
[12:06:21] --> Forgetful_Lion has joined #GemRB
[12:58:32] --> barra_desktop has joined #gemrb
[13:07:29] <-- Forgetful_Lion has left IRC (" HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...")
[15:01:58] <-- Nomad010 has left IRC (Remote closed the connection)
[15:45:01] --> barra_away has joined #gemrb
[15:50:59] <-- barra_desktop has left IRC (Read error: 60 (Operation timed out))
[16:02:33] --> tomprince has joined #gemrb
[16:23:49] <tomprince> Hello.
[16:27:52] <edheldil> hello
[16:27:57] <lynxlynxlynx> oj
[16:27:58] <Maighstir> hi
[18:27:55] --> tombhadAC has joined #gemrb
[18:53:21] <tomprince> I am curious if any knows why there are two kinds of sprites? Is just so that BAM sprites can share memory, or is it something more?
[18:58:29] <fuzzie> i thought the BAM sprites were RLE or similar
[18:59:14] <fuzzie> and so also rendered in a different way
[19:01:18] <tomprince> I think some of them are RLE. There is code to get non RLE encoded sprites.
[19:02:14] <fuzzie> in any case it's a combination of faster blitting and memory efficiency
[19:02:32] <tomprince> I was just thinking that the code would be simpler if all the sprites where the same format.
[19:02:49] <fuzzie> well, if you can make it fast enough..
[19:04:04] <tomprince> I wonder if it is actually faster. I don't know. I would guess that a straight memcpy would be faster than a conditional loop or something.
[19:04:10] <fuzzie> rendering is by far the biggest speed issue in gemrb; there are many obvious candidates for optimisation (eg, dirty rectangles)
[19:04:44] <tomprince> I was mostly wondering if there was something other than data format that seperated the sprites?
[19:04:48] <fuzzie> well, the 'faster' is in the blitting, mostly. i'd kind of hope that we don't make sprites often enough for it to matter..
[19:05:08] <fuzzie> but that Sprite2D_BAM_Internal is special-cased all over the renderer.
[19:06:11] <tomprince> It wouldn't suprise me if that cause a performance hit, since it means there is a lot more code, so more of a cache hit.
[19:06:28] <tomprince> And SDLVideoDriver.inl causes a lot of duplicated code.
[19:06:36] <fuzzie> well, maybe you could do it better.
[19:06:44] <fuzzie> naive blitting w/SDL's code is definitely awful, i tried it.
[19:06:55] <fuzzie> i don't know who wrote it all in the first place, before my time, i assume wjp?
[19:07:29] <tomprince> Before svn.
[19:07:31] <fuzzie> but you would think the important bit for caching is going to end up being the inner loops, which don't seem particularly large.
[19:07:35] <fuzzie> ah, drat.
[19:08:23] <fuzzie> i wouldn't be at all surprised to find that some forms of simplication would help, in that case..
[19:09:09] <fuzzie> i never did understand the code, it does a lot of shadow and effect magic.
[19:09:47] <tomprince> Ripping out all the BAM stuff would make the code at least somewhat easier to understand, I think.
[19:09:54] <fuzzie> i don't think saving memory usage is important enough to matter, anyway.
[19:10:10] <fuzzie> because at the moment we generate sprites for the entire tilemap and that is huge, for example.
[19:10:20] --- barra_away is now known as barra_desktop
[19:10:36] <fuzzie> but the rendering speed is miserable enough on embedded platforms as it is, so i would be nervous on that front.
[19:12:20] <fuzzie> Presumably the only realistic way to simplify the code would be to just make it always take the BAM path anyway, even if you end up simplifying that, since the magic is all BAM-only..
[19:13:47] <tomprince> I was actually thinking about the opposite route, going all non-bam.
[19:16:53] <fuzzie> I can't see how you'd implement much of the blitting functionality otherwise.
[19:19:45] <fuzzie> I mean, I can't see a good reason for the BAM/sprite split, but I *can* see a good reason for all the custom blitting code. There's no harm in changing it if you think you can make it just as fast, though?.
[19:21:08] <wjp> a large benefit of the RLE is that the transparent borders of sprites come for free
[19:21:30] <wjp> you can skip entire runs of transparent pixels
[19:21:56] <fuzzie> there's some kind of RLE code in SDL itself, though
[19:22:07] <wjp> yes
[19:22:35] <fuzzie> not the most efficient ever, but as long as we keep sprites around it's presumably sufficient
[19:23:00] <wjp> but you can't really access the internals I believe
[19:23:24] <wjp> and for the spritecover stuff, and the double colourkey, that's very useful
[19:24:46] <fuzzie> i was wondering if the cache issues might have been the problem with the awful rendering performance on the ARM devices, but it looks like at least the modern ones have enough
[19:25:23] <tomprince> Well, I'll have a go at it.
[19:26:26] <fuzzie> i imagine simplified code would be rather nice for trying to accelerate it with opengl etc
[19:28:26] <tomprince> Unrelated, have you had a chance to look at the patch to tear out ClassDesc?
[19:31:25] <fuzzie> well, it is motivation to move to git :|
[19:31:39] <fuzzie> as it is, applying it kind of ruins svn history
[19:33:13] <wjp> (just reading the back log): there aren't many straight memcpy's involved in blitting sprites, by the way. They're indexed (and clown-coloured) and often tinted as well. Then there are the covering polygons
[19:33:17] <fuzzie> removing all the *CD* boilerplate seems an obvious simplification hough
[19:33:19] <fuzzie> erm, though.
[19:33:30] <fuzzie> wjp: i think that was about the fact that BAMs are reference-counted, rather than the blitting
[19:33:55] <tomprince> Well, both.
[19:34:28] <tomprince> About the renaming: I just wanted to get rid of all the random abbreviations
[19:34:31] <fuzzie> well, in that case, what wjp said, i guess.
[19:34:41] <fuzzie> sure, i jsut don't think it's a good idea to apply onto svn
[19:34:51] <fuzzie> Avenger seemed maybe agreeable to just moving to git, and i think everyone else is using git-svn anyway
[19:36:09] <tomprince> I would be fine without that bit of the patch. It would be easy enough to do without. It might make sense even for git to split the patch up that way.
[19:36:33] <tomprince> As is, git doesn't by default detect the delete+rename.
[19:36:36] <wjp> maybe some perl magic to turn that patch into a bunch of 'svn mv' commands? :-)
[19:36:45] <lynxlynxlynx> we haven't moved to git, since there doesn't seem to be a good gui for it on windows
[19:37:05] <fuzzie> wjp: yes, something along those lines.
[19:37:05] <wjp> lynxlynxlynx: from what I understand the situation has improved quite a bit recently
[19:37:30] <lynxlynxlynx> good, then avenger will be even more agreeing ;)
[19:38:19] <wjp> it might be good to start with a test repo first to see how things work in practice
[19:39:10] <tomprince> Well there is a repo up. :)
[19:39:26] <tomprince> http://stackoverflow.com/questions/157476/what-guis-exist-for-git-on-windows
[19:40:14] <tomprince> If anybody want access to the repo ...
[19:41:27] <fuzzie> mm, something not subject to sf's whims might be nice.
[19:42:09] <wjp> tomprince: what was the .git url again? I saw it go by somewhere but I can't seem to find it
[19:42:16] <lynxlynxlynx> on the other hand sf is reliable in the long run
[19:42:23] <fuzzie> http://repo.or.cz/w/gemrb.git
[19:42:34] <tomprince> That is the gitweb url.
[19:42:37] <fuzzie> well, the nice thing about git is that we can just transplant it :)
[19:42:39] <tomprince> which has the git url.
[19:42:49] <tomprince> And everybody has a complete copy of it.
[19:43:09] <tomprince> If we do move to git, the svn import should probably be redone with a proper authors file for svn.
[19:44:02] * wjp nods
[19:44:25] <fuzzie> I have a couple of projects with shared repositories hosted on github, which has worked out rather nice with people easily making visible forks, etc.
[19:44:55] <tomprince> I think repo.or.cz also has that functionality.
[19:45:08] <tomprince> Although I have no attachment to it, or against github.
[19:46:09] <fuzzie> yes, i think they keep track of each other's forks, too
[19:46:48] <fuzzie> in any case you can see i have very little time recently, so i am in no way volunteering..
[19:52:33] <lynxlynxlynx> me neither, not that it is a lot of work
[19:53:12] <wjp> I might :-)
[19:53:21] <fuzzie> presumably most of the work is walking everyone through making git work, and since everyone seems to have disappeared for the last few months..
[19:54:14] <-- tombhadAC has left IRC ("Verlassend")
[20:01:54] <lynxlynxlynx> i have a greater calling since 0.6.0
[20:02:41] <lynxlynxlynx> we're preparing the biggest volunteer action in Slovenia yet :)
[21:04:46] <tomprince> fuzzie: I split the patch into two parts.
[21:10:42] <tomprince> git diff 85df0 52250 --raw --diff-filter=R -M | cut -f 2,3 | xargs -n2 svn mv
[21:10:59] <tomprince> That should tell svn about all the renames in the rename patch.
[21:11:25] <tomprince> (untested)
[21:20:47] <tomprince> Or if using git-svn; dcommit will handle this automatically (--rmdir to remove the moved directory) (untested)
[21:42:15] --> tombhadAC has joined #gemrb
[23:04:58] <-- lynxlynxlynx has left IRC (Remote closed the connection)