#gemrb@irc.freenode.net logs for 13 Apr 2010 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage


[00:07:53] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[00:19:17] --> Gekz has joined #GemRb
[01:01:28] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[01:05:13] <-- Lightkey has left IRC (Ping timeout: 248 seconds)
[01:05:17] --> Lightkey has joined #GemRb
[01:20:58] <-- Gekz has left IRC (Quit: This computer has gone to sleep)
[01:47:20] --> Gekz has joined #GemRb
[03:06:34] <-- ratpor has left IRC (Quit: Get used to disappointment.)
[05:33:24] <-- fuzzie has left IRC (*.net *.split)
[05:33:27] <-- |Cable| has left IRC (*.net *.split)
[05:35:30] --> |Cable| has joined #GemRb
[05:35:30] --> fuzzie has joined #GemRb
[05:36:28] <-- fuzzie has left IRC (*.net *.split)
[05:36:31] <-- |Cable| has left IRC (*.net *.split)
[05:36:32] <-- tomprince_loki has left IRC (*.net *.split)
[05:36:32] <-- tomprince has left IRC (*.net *.split)
[05:36:33] <-- wjp has left IRC (*.net *.split)
[05:36:34] <-- Gekz has left IRC (*.net *.split)
[05:36:34] <-- xrogaan has left IRC (*.net *.split)
[05:37:16] --> fuzzie has joined #GemRb
[05:37:16] --> |Cable| has joined #GemRb
[05:37:16] --> Gekz has joined #GemRb
[05:37:16] --> tomprince_loki has joined #GemRb
[05:37:16] --> tomprince has joined #GemRb
[05:37:16] --> wjp has joined #GemRb
[05:37:16] --> xrogaan has joined #GemRb
[06:35:04] --> Nomad010 has joined #GemRb
[06:35:32] --> Gekz_ has joined #GemRb
[06:35:36] <-- Gekz has left IRC (Read error: Connection reset by peer)
[07:37:12] <-- raevol has left IRC (Quit: Leaving.)
[07:59:29] --> lynxlynxlynx has joined #GemRb
[07:59:30] --- ChanServ gives channel operator status to lynxlynxlynx
[08:07:07] <fuzzie> g'morning
[08:09:03] <lynxlynxlynx> oj
[08:44:15] <-- |Cable| has left IRC (Remote host closed the connection)
[08:54:12] <wjp> hi
[08:55:04] <fuzzie> i have to go sit in a lecture and learn about turing machines and non-determinism so we can learn what NP means, please send help. :|
[08:55:47] <wjp> oh, fun stuff :-)
[08:56:38] * wjp is in the wrong country today to send help, though
[09:51:40] --- Gekz_ is now known as Gekz
[12:22:47] <fuzzie> all is well, someone else rescued me
[13:06:56] <-- Nomad010 has left IRC (Ping timeout: 258 seconds)
[13:17:41] <tomprince> I can pretend I know that stuff. :)
[13:25:15] <tomprince> I know enough to help, anyway.
[13:25:35] <fuzzie> I could lecture on that stuff, but I promised I'd turn up.
[13:25:57] <tomprince> :)
[13:26:43] <fuzzie> I spent the time learning what the Central Limit Theorem is.
[13:30:59] <fuzzie> I really need to catch up on the rest of first-year probability today, so should probably be staying away from the patch queue, alas.
[13:41:04] <tomprince> I ... acquired a copy of WinXP /w vs6/mingw to test against.
[13:42:07] <fuzzie> Aha. I was hoping Maighstir's were just issues with the cache, but I guess you can work it all out, now!
[13:42:35] <tomprince> Hopefully.
[13:47:21] <Gekz> In other news
[13:47:28] <Gekz> have nay of you tried to make a Mac OS X GUI?
[13:47:29] <Gekz> jesus fuck
[13:48:16] <fuzzie> Having fun with Interface Builder?
[13:49:15] <Gekz> it makes no sense!
[13:52:59] <tomprince> The VS6 project doesn't seem to want to open for me at all here.
[13:54:28] <fuzzie> You need to unpack it in the same place as the gemrb tree, I think.
[13:56:07] --> Nomad010 has joined #GemRb
[13:56:40] <fuzzie> Oh, and you need to do the libpng magic first.
[13:57:52] <tomprince> My trouble is that it didn't seem to reconginze the project file. Maybe the version of VS i found.
[14:00:05] <fuzzie> Oh.
[14:00:14] <fuzzie> If you're checking it out of git, line ending problems?
[14:05:40] <tomprince> That would do it.
[14:14:34] <Gekz> is there no mod that allwos your npcs to take strongholds?
[14:19:13] <tomprince> fuzzie: The problem is passing -ansi to g++. :)
[14:20:28] <fuzzie> If you have a minimal patch for me to apply.. otherwise I suggest poking lynx/wjp/etc.
[14:20:46] <tomprince> Not yet. But I thought I'd report, so there is a record.
[14:20:56] <fuzzie> well, thankyou, then :)
[14:22:48] <tomprince> There is also something going on with Core.cpp, but then, I've not had a succesful build *before* the changes.
[14:23:02] <tomprince> Anyway ... off to do real work for a change. :)
[14:23:24] <fuzzie> Nice to know it's not just me. :)
[14:24:17] <wjp> :-)
[14:26:34] <lynxlynxlynx> :P
[14:26:57] <lynxlynxlynx> i worked till 0300 yest err today
[14:27:45] <tomprince> Well, yesterday, if mark days by sleep cycles, rather than by clocks. :)
[14:27:58] <tomprince> Which is what most people tend to do in practice.
[15:56:31] <-- Gekz has left IRC (Read error: Connection reset by peer)
[15:56:40] --> Gekz has joined #GemRb
[16:24:13] --> kettuz has joined #GemRb
[17:35:56] --> |Cable| has joined #GemRb
[18:17:52] --> Edheldil_ has joined #GemRb
[19:41:11] <fuzzie> Meh, the bug tracker situation really isn't such a nice one, still.
[19:43:51] <wjp> at some point I should get a VM with some more RAM so I can host things like that myself
[19:44:38] <fuzzie> Well, I can always throw things onto my VM, if necessary.
[19:44:58] <fuzzie> Although I am a terrible sysadmin.
[19:45:27] <lynxlynxlynx> the fact that there's only terrible bug tracking software doesn't help
[19:45:36] <fuzzie> But just trying to find a *friendly* bug tracker is.. perhaps a bit hopeless.
[19:46:01] <fuzzie> I ended up using Google Code for other projects a few years ago, it looks like there still isn't anything simpler.
[19:46:31] <fuzzie> (You can make a project there and just turn off all the functionality except the bug tracker.)
[19:48:05] <fuzzie> ( eg,http://code.google.com/p/openc2e/issues/list )
[19:48:37] <wjp> I've never really thought very hard about what would be nice to have in a bug tracker
[19:48:39] <fuzzie> But it's such a *simple* system, you'd think there would be similar out there.
[19:49:06] <tomprince_loki> I don't really have any opinion or preference one way or another, but is there a reason to turn off all the other functionality?
[19:49:41] <fuzzie> tomprince: Well, everyone already seems happy with the existing wiki, and they only do subversion for hosting, and sourceforge is fine for downloads.
[19:50:37] <fuzzie> So I've found that to avoid confusion it's easier to disable the things you're not using (you can simply make the tabs link to arbitary URLs).
[19:51:03] <fuzzie> Oh, maybe not arbitary URLs yet, which I guess is why I have it disabled on that project.
[19:52:19] <fuzzie> But I'm not sure I suggest using Google Code, I'm just pondering.
[19:54:37] <wjp> I'm actually not that unhappy with SF's bug tracker. It seems to mostly do the job
[19:55:09] <wjp> (of course that's what I thought about SVN too until I tried git...)
[19:55:54] <fuzzie> It has been throwing random errors at me half the time I've tried modifying anything, recently.
[19:56:12] <fuzzie> SF staff tell me that they don't really support it any more, SF-hosted trac is the new thing.
[19:56:12] <tomprince_loki> One thing against the SF tracker is the search. I have tried a couple of times to search, and haven't had any luck getting any results.
[19:56:26] <tomprince_loki> Not that I tried very hard, but it should take effort.
[19:56:46] <tomprince_loki> And I couldn't figure out how to look at multiple tracker simultaneously.
[19:57:01] <tomprince_loki> s/should/shouldn't/
[19:59:19] <fuzzie> (But SF don't offer automated migration, and their trac API is broken, which presumably gives an idea of how reliable their trac hosting is..)
[20:00:11] <wjp> trac seems fairly nice from what I've seen (sagemath.org uses it)
[20:00:48] <tomprince_loki> There does appear to be an export function at sf.net/export.
[20:02:14] <lynxlynxlynx> can you get just the bugtracker out of trac?
[20:02:22] <tomprince_loki> Not sure how useful it is.
[20:02:46] <wjp> last time I looked at the export you could get all tracker data in XML
[20:03:35] <wjp> (possibly minus the attachments, I'd have to check)
[20:04:44] <fuzzie> I think there are tools around to do the rest of the export,too.
[20:04:56] <fuzzie> SF's trac is also incredibly uncustomisable, which is not making me like it.
[20:06:16] <wjp> the XML comes with links to the attachments, so it would be easy to get at them
[20:10:38] <fuzzie> I really don't think getting the data *out* of the old tracker is the problem.
[20:10:41] <fuzzie> Although to be honest, I.
[20:10:48] <fuzzie> I'm not sure there's a lot of value there any more.
[20:20:08] <tomprince_loki> There might, if the data was actually somewhat accesible.
[20:20:53] <tomprince_loki> For someone like me wo hasn't been around, being able to look back and see what things were broken, to explain workarounds in the code.
[20:21:10] <tomprince_loki> Although, I don't know how much of that is record in the tracker.
[20:21:23] <tomprince_loki> And ideally, all that would be migrated into the code itself. :)
[20:21:51] <wjp> the tracker isn't a really useful place for that I think
[20:22:01] <wjp> (historically speaking, I mean)
[20:23:49] <tomprince_loki> I'll beleive you, since I find the tracker painful enought that it is more effort than it is worth to look for myself. I suspect there are a few bits and pieces, but not worth the effort.
[20:24:23] <fuzzie> I would like somewhere to keep track of obvious things which need to be fixed, and maybe even how to do them.
[20:24:42] <fuzzie> The wiki will suffice, though.
[20:24:56] <wjp> tomprince_loki: I can send you the tracker .xml if you want to grep through it sometime
[20:25:29] <tomprince_loki> Sure.
[20:25:46] <tomprince_loki> No big deal, but if it is easy to get ...
[20:30:06] <fuzzie> It doesn't help that the reality is that a lot of the knowledge is in 10 years of Infinity Engine modding discussions/forums/notes/etc.
[20:36:16] <tomprince_loki> Well, maybe at some point, my attempt to completely refactor the code base will end up turning that knowledge into an accesible form. ;)
[20:36:31] <tomprince_loki> If only because I keep breaking things.
[20:38:07] <tomprince_loki> Particularly turning the GameScript stuff into a plugin.
[20:39:24] <fuzzie> Would be an interesting challenge.
[20:39:56] <fuzzie> Not sure how you'd do it, though.
[20:40:45] <fuzzie> An awful lot of functionality is run by blocking GameScript code, even if we have rather too much of it still lurking in outside functions right now.
[20:40:57] <tomprince_loki> If I cared simply about moving the code, I remember looking and seeing that there only about a dozen calls into
[20:41:07] <tomprince_loki> GameScript/Actor/Trigger/....
[20:41:22] <fuzzie> It's the GameScript->elsewhere code which would be tricky. :)
[20:42:14] <fuzzie> But I guess given that it's a requirement, you'd simply have to write the same functionality for the other plugins.
[20:43:04] <tomprince_loki> I'm not sure I understand what you mean.
[20:43:21] <fuzzie> Well, for instance, combat is controlled by blocking combat scripting actions.
[20:44:03] <fuzzie> You ask an actor to update scripts, it asks the blocking action to update itself, the blocking action does some scripting system updates, calls the combat functions on the relevant actor, does some scripting system updates.
[20:44:56] <fuzzie> The same for spellcasting, movement, dialog, etc.
[20:45:47] <tomprince_loki> I think I understand. I haven't yet got around to sitting down and looking at the code a figuring out the current structure, let alone what the final sturcutre might look like.
[20:45:49] <fuzzie> When you perform any of those actions from the UI, it simply constructs a scripting action.
[20:46:15] <tomprince_loki> I've had a couple of brief looks at the code, but then been scared away, and went and worked on lower hanging fruits.
[20:47:22] <fuzzie> But it's a rather annoyingly interconnected system.
[20:47:49] * tomprince_loki goes for supper.
[20:48:05] <tomprince_loki> I agree, hence my desire to refactor it.
[20:48:09] * tomprince_loki grins.
[20:48:25] <fuzzie> Well, I mean, it's required to be annoyingly interconnected. :)
[20:49:00] <fuzzie> I don't think it would be impossible to simply chop the GameScript bits off and put them in a plugin, but you'd necessarily take an awful lot of the code with it.
[20:49:35] <fuzzie> I have slowly been refactoring the other bits as I go.
[20:49:50] <fuzzie> But obviously only when it's convenient for me.
[20:53:11] <fuzzie> But with sloccount, I estimate about a third of the lines of code in Core are going to be BGScript-specific?
[21:00:41] --> raevol has joined #GemRb
[21:03:56] <lynxlynxlynx> what was all the tinting stuff good for (except small teeth pass)?
[21:04:30] <lynxlynxlynx> and is there something visibly new with weather?
[21:04:33] <fuzzie> Yes.
[21:04:35] <wjp> dusk/night/dawn/dream/weather effects
[21:04:40] <fuzzie> What wjp said :)
[21:04:48] <wjp> small teeth pass was actually something else
[21:05:06] <lynxlynxlynx> so before the lighting was always the same?
[21:05:09] <fuzzie> Small Teeth Pass was just me asking wjp to fix that while he was looking at it.
[21:05:19] <wjp> but it was easier to tackle both at the same time since they required doing tile rendering differently
[21:05:21] <fuzzie> The lighting for the background, yes.
[21:05:40] <fuzzie> An obvious example is the first cutscene in Baldur's Gate 1.
[21:05:52] <fuzzie> It should be both at nighttime and in the rain, now.
[21:07:28] <lynxlynxlynx> cool
[21:08:06] <fuzzie> (It is also why I was asking about the missing LIGHTB, and the flaky Sarevok animations, and the viewport centering - they are all issues in that cutscene.)
[21:09:22] <tomprince_loki> At the very least, I think the reading of BCS/BS files, and the knowledge of the format of scripts as blocks of triggers with assoicated actions could be factored out.
[21:09:52] <fuzzie> The triggers have side-effects.
[21:10:10] <fuzzie> And the blocks have to be executed in a careful order depending on the triggers and actions.
[21:10:51] <fuzzie> The parsing of BCS files would seem an easy candidate for moving to an importer, though.
[21:10:57] <tomprince_loki> What kind of side effects? Just changing the results of other triggers (like setting of variables?)
[21:11:13] <CIA-74> GemRB: 03lynxlupodian * r5f0398379438 10gemrb/NEWS: NEWS update
[21:11:26] <fuzzie> Yes, I think just things like that.
[21:11:31] <tomprince_loki> Like I think it would be possible to have a faithful mapping from BCS to a conventional imperative style.
[21:11:55] <fuzzie> I mean, "setting of variables" influences everything, not just other triggers.
[21:12:45] <tomprince_loki> So can an if statement in C++ though.
[21:12:55] <fuzzie> But, I mean, there's nothing special about BCS files that you couldn't generalise to lists of blocks with triggers+actions.
[21:13:36] <fuzzie> I just think you'd have a difficult time beyond that.
[21:14:05] <fuzzie> How would you expose an interface which meant "check all blocks, and report back those which should be newly executed, given we're currently in block 18"?
[21:18:22] <fuzzie> And for instance, dialogs have the same actions/triggers, except a different parsing method, and some actions have to be executed instantly, while others go on the queue. And you have ActionOverride(), which zaps the current blocking action only.
[21:18:53] <tomprince_loki> Well, like I said, I don't know all the details of what needs to be done.
[21:19:14] <tomprince_loki> But I was under the impression that a BCS file could almost be thought of as a function that is called each tick.
[21:19:24] <fuzzie> This is true.
[21:20:23] <tomprince_loki> So that is sort of the idea that I had for a first approximation. That the plugin would expose it self as a function to run.
[21:21:33] <fuzzie> Each block is along the lines of "if (triggers are true) and (this block was not the last one ran) { if this is the first block this run, wipe the object queue; add $list_of_actions to the queue; mark ourselves as the last block the object ran; if the last action was not Continue(), stop here; }.
[21:23:41] --> cfchris6_ has joined #GemRb
[21:23:44] <tomprince_loki> I think that information could usefully be hidden in a plugin.
[21:24:05] <fuzzie> Cutscene mode is a special-case (all blocks have the first action removed, the object extracted, and then the remaining actions run on that object).
[21:24:16] <fuzzie> But that gives the general idea.
[21:24:52] <fuzzie> You could abstract 'last-run block' with some kind of special storage in the object, and probably hide the triggers, but you can't hide the actions at all.
[21:26:57] <-- cfchris6 has left IRC (Ping timeout: 260 seconds)
[21:27:01] <fuzzie> There are an awful lot of requirements about when those scripts are processed, and in which context, and etc, but the caller could be responsible for that.
[21:27:10] <fuzzie> Doesn't really help your abstraction, though.
[21:29:40] <fuzzie> In "other things which needs abstracting to Importers", note the absence of a VVCImporter..
[21:33:23] --> lynxlynx has joined #GemRb
[21:33:23] <-- lynxlynx has left IRC (Changing host)
[21:33:23] --> lynxlynx has joined #GemRb
[21:33:23] --- ChanServ gives channel operator status to lynxlynx
[21:33:47] <-- lynxlynxlynx has left IRC (Read error: Connection reset by peer)
[21:33:53] --- lynxlynx is now known as lynxlynxlynx
[21:39:55] <wjp> hm, tis(un)pack seem to be assuming the colourkey for tiles is always 0
[21:42:14] <wjp> well, makes unpacking easier
[21:42:16] <fuzzie> Well, for custom TIS files, I think they always are.
[21:42:53] <wjp> ah, libjpeg actually supports quantizing to a user-supplied palette; nice
[21:44:54] <wjp> so I guess we'd really want to unpack type 1 tiles to indexed sprites
[21:45:13] <wjp> and only type 2 would be 32bpp
[21:46:03] <fuzzie> You've seen tomprince's code?
[21:46:20] <tomprince_loki> I'd be nice not to need to do that, so that JPEGImporter doesn't need to know about quantizing.
[21:47:36] <wjp> it'd be nicer to support that though :-)
[21:48:11] <fuzzie> Questions of priorities, I guess.
[21:48:49] <fuzzie> If you keep *any* tiles as 32bpp, you're going to make TIZ files slower.
[21:48:57] <wjp> it's slightly tricky to do the mask properly without indices
[21:49:25] <wjp> (you'd have to pick a colour key that doesn't also show up as a non-masked pixel)
[21:50:01] <fuzzie> wjp: Or store it as alpha, presumably.
[21:50:08] <wjp> or that
[21:51:10] <wjp> (that would be cleaner, yes)
[21:51:41] <fuzzie> But the 4x memory hit seems a bit sad.
[21:51:51] <tomprince_loki> I'm not sure why dithering would be *nicer* necessarily. 8bpp tiles would seem like a limitation of the original engine, that we don't need to emulate.
[21:52:10] <tomprince_loki> I could see someone generating TIZ files from 24bpp data ...
[21:52:37] <tomprince_loki> Probably no one does, since nobody targets gemrb yet.
[21:52:44] <fuzzie> Well, it's again real world usage vs thereotical modding abilities. :)
[21:52:51] <tomprince_loki> :)
[21:52:51] <fuzzie> It would be nice to keep both.
[21:53:23] <-- kettuz has left IRC (Quit: Leaving)
[21:53:37] <wjp> tomprince_loki: but in that case format 1 probably couldn't be used, because that explicitly specifies a palette
[21:53:38] <tomprince_loki> Part of it is that I don't know how to get the dithered tile out of JPEGImporter.
[21:54:17] <fuzzie> wjp: gemrb could ignore the palette, though.
[21:54:28] <wjp> we could, but presumably we lose jpeg-artifacts if we quantize
[21:54:39] <wjp> </optimistic> :-)
[21:55:38] <fuzzie> hehe, TIZImporterorter.
[21:55:53] <tomprince_loki> :)
[21:56:06] <tomprince_loki> I've created a few of those :)
[21:57:06] <tomprince_loki> I think I've caught all of them before they hit the tree.
[21:57:21] <tomprince_loki> And I've learned to avoid them.
[21:58:04] <wjp> tomprince_loki: libjpeg.txt has a section 'Decompression parameter selection' that seems to cover it
[21:58:34] <wjp> "When quantize_colors is TRUE, the target color map is described by the next
[21:58:34] <wjp> two fields. colormap is set to NULL by jpeg_read_header(). The application
[21:58:34] <wjp> can supply a color map by setting colormap non-NULL and setting
[21:58:35] <wjp> actual_number_of_colors to the map size."
[21:59:15] <tomprince_loki> That part isn't the problem, it is getting TIZImporter to communicate to JPEGImporter that it should do that, and what palette to use. The original patch had the jpeg handling in TIZImporter, which dealt with that.
[22:00:06] <tomprince_loki> I thought that full color would be nicer then 8bpp anyway. Not considering the difficulty that then results in SDLVideo.
[22:00:29] <wjp> ah, but you can create the palette in TIZImporter before having to call JPEGImporter, right?
[22:00:53] <tomprince_loki> Yes.
[22:02:15] <fuzzie> Well, I mean, I can see the "24bpp is thereotically nicer" point.
[22:02:56] <fuzzie> Just seems like the ideal target for the smaller TIZ files are the platforms where the increased resource usage would perhaps be painful.
[22:03:03] <fuzzie> So it seems a bit sad.
[22:03:24] <wjp> regardless, I think we should just assume those'll be type 2, and mask-tiles will always be type 0 or 1
[22:03:36] <tomprince_loki> True.
[22:03:42] <fuzzie> Well, yes, my point here is seperate from wjp's point :-)
[22:03:45] <wjp> we can also add an option to make it quantize type 2 tiles if it hurts performance
[22:04:09] <fuzzie> And the bit which concerns me the most is moving GetTile out of TISImporter.
[22:04:25] <tomprince_loki> wjp: tispack doesn't allow type two for tiles with masks.
[22:04:36] <wjp> tomprince_loki: my point exactly
[22:05:00] <wjp> (but it's worth noting that tispack also doesn't support RGB tiles :-) )
[22:05:38] <fuzzie> That would be trivial to fix, however.
[22:05:46] * wjp nods
[22:06:12] <wjp> hm, GetTile is scarily special-purpose
[22:06:13] <fuzzie> But I think for modders, you would have far more luck with isometric tiling.
[22:07:00] <wjp> I guess GetTile is designed for the WED format?
[22:07:04] <tomprince_loki> Looking at GetTile in more detail, perhaps that should move all the way to WEDImporter.
[22:07:10] <fuzzie> Nooo.
[22:07:28] <wjp> no?
[22:08:17] <fuzzie> Oh, I guess moving it to WEDImporter would work.
[22:08:46] <fuzzie> It's just hiding too much right now, making new copies of everything every time is not so great.
[22:09:36] <fuzzie> Imagine how many times a single-tile secondary animation is duplicated in some TIS files..
[22:09:40] <wjp> true
[22:10:06] <wjp> bam used to have the same problem
[22:10:26] <tomprince_loki> So TileSetMgr should be caching Tiles?
[22:10:44] <tomprince_loki> That would make sense, and be easy enough to implement.
[22:10:51] <wjp> yes, I think so
[22:10:58] <fuzzie> There should probably be a more involved interface in general.
[22:11:05] <wjp> similar to have BAM caches sprites too
[22:11:08] <tomprince_loki> Since Sprite2Ds are refcounted anyway.
[22:11:09] <wjp> s/have/how/
[22:11:20] <wjp> yup. That BAM stuff is the reason for the refcounting
[22:12:59] <wjp> are TISs small enough that we can cache those in their entirety?
[22:14:02] <tomprince_loki> Probably not permantly. Like I said, there is ~1.2G of tiz (more of tis) for the Classic Adventures mod.
[22:14:38] <fuzzie> A typical TIS is about 15mb of data.
[22:15:16] <lynxlynxlynx> LRU
[22:15:46] <fuzzie> If we load-on-demand and drop it as soon as we move off a map, that seems a reasonable hit.
[22:15:54] <fuzzie> 60mb for 32bpp, a bit less so.
[22:16:13] <wjp> about 4K tiles?
[22:16:23] <fuzzie> I don't know, sorry, I'm just looking at the files.
[22:16:39] <tomprince_loki> Well, I think that if we were going to do something like a LRU, then it would probably make sense to do that at a higher level, like in GameData.
[22:17:15] <wjp> maybe, but I can imagine special-casing large things like TIS
[22:17:21] <fuzzie> That's just pushing more knowledge of the rendering internals into the core, though..
[22:17:22] <wjp> (large, non-granular)
[22:18:40] <tomprince_loki> Well, we could put infomation like that into TypeID, and then still handle it at the gamedata level, but with specific information about when and what to cache.
[22:20:35] <lynxlynxlynx> don't we already use LRU somewhere?
[22:20:47] <wjp> at least for audio buffers
[22:21:09] <lynxlynxlynx> mhm
[22:27:44] <-- lynxlynxlynx has left IRC (Remote host closed the connection)