#gemrb@irc.freenode.net logs for 4 Jul 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:31:48] --- ermo is now known as ermo^
[00:32:04] <-- brada has left IRC (Quit: brada)
[01:00:14] <-- Gekz has left IRC (Ping timeout: 246 seconds)
[01:02:37] --> Gekz has joined #gemrb
[03:45:45] <-- fuzzie has left IRC (Ping timeout: 246 seconds)
[03:45:52] --> fuzzie has joined #gemrb
[06:22:55] --> Eli2 has joined #gemrb
[06:24:43] <-- Eli2_ has left IRC (Ping timeout: 245 seconds)
[06:33:38] --> lynxlynxlynx has joined #gemrb
[06:33:38] <-- lynxlynxlynx has left IRC (Changing host)
[06:33:38] --> lynxlynxlynx has joined #gemrb
[06:33:38] --- ChanServ gives channel operator status to lynxlynxlynx
[07:03:05] --> Canageek has joined #gemrb
[07:12:04] <-- Canageek has left IRC (Quit: Leaving)
[07:17:57] --> WingedHussar has joined #gemrb
[07:56:20] <-- fireglow has left IRC (Quit: puf)
[08:27:59] --> fireglow has joined #gemrb
[09:27:32] --> fuzzie_ has joined #gemrb
[09:32:11] <-- fuzzie has left IRC (*.net *.split)
[09:50:07] --- fuzzie_ is now known as fuzzie
[11:06:15] --- ermo^ is now known as ermo
[11:18:27] --- ermo is now known as ermo^
[12:35:33] <-- WingedHussar has left IRC (Quit: WingedHussar)
[12:43:53] --> WingedHussar has joined #gemrb
[15:10:34] <-- WingedHussar has left IRC (Quit: WingedHussar)
[15:33:02] --- ermo^ is now known as ermo
[15:59:55] --> brada has joined #gemrb
[16:15:04] <brada> fuzzie: its going to be much longer till i can get back to this opengl business, but id like to merge my refactor up to this point: https://github.com/bradallred/gemrb/compare/master...sprites
[16:15:08] <Seniorita> Comparing master...sprites · bradallred/gemrb · GitHub
[16:15:09] <Seniorita> »gemrb - Game Engine Made with preRendered Background«
[16:33:19] <lynxlynxlynx> is it just a generalisation or does it also break/add stuff?
[16:35:32] <brada> nothing breaks that i know of
[16:35:43] <brada> some minor fixes/additions
[16:35:51] <brada> but mostly sdl2 related iirc
[16:57:07] <lynxlynxlynx> sounds good then
[16:57:30] <lynxlynxlynx> i can't give a good review, but maybe i'll do some testing later
[17:29:54] <brada> cool
[18:50:02] <lynxlynxlynx> let's see
[18:53:09] <lynxlynxlynx> it builds
[18:53:18] <lynxlynxlynx> gamedemo segfaults
[18:54:08] --> kingron has joined #gemrb
[18:54:08] <lynxlynxlynx> SDLVideo.cpp:342 backbuf is null
[18:55:00] <lynxlynxlynx> this is while loading the png palette
[18:55:02] <fuzzie> brada: why did you move so much into Video?
[18:55:46] <fuzzie> the AddPolygonToSpriteCover seems rather SDL-software-specific for example
[18:57:06] <fuzzie> and changing the CreateSpriteBAM8 call into a direct 'new BAMSprite2D' also seems not a great idea
[18:59:36] <brada> why?
[19:00:22] <fuzzie> because aren't hardware renderers going to want to convert it immediately to some other format?
[19:00:52] <brada> no
[19:00:58] <lynxlynxlynx> wierd animation issues in iwd2: actors sometime dont render properly at all
[19:00:58] <brada> because they wouldnt suport bams
[19:01:27] <fuzzie> oh
[19:01:29] <fuzzie> that's even more icky :-p
[19:01:36] <brada> why?
[19:01:51] <fuzzie> the responsibility here just seems wrong
[19:03:05] <fuzzie> this way the backends can't do things like caching
[19:03:22] <brada> im not sure what you mean
[19:03:31] <fuzzie> either they handle BAMs and get the raw data, or they don't and they get uncompressed data taking a lot more memory
[19:04:13] <fuzzie> you're just hoping to deal with that problem by SDL's RLE?
[19:04:47] <fuzzie> because right now you're keeping the pixels pointer around..
[19:05:42] <brada> how is that different then what we currently do?
[19:05:58] <fuzzie> right now, we pass the BAM data around, always
[19:06:09] <fuzzie> which is RLE-compressed, and so it takes a lot less memory
[19:06:51] <fuzzie> and also it's shared between instances
[19:09:10] <brada> i know that
[19:09:14] <fuzzie> and if you pass that to the backend, then the backend can keep the BAM data around as the efficient version, and then when it needs to create e.g. a texture, it renders the BAM into the texture
[19:09:22] <fuzzie> the way you've written this, I don't think that can work
[19:09:27] <lynxlynxlynx> hmm, there's also an unrelated regression with nonproficiency penalty
[19:09:59] <brada> i dont see what i did to break bams...
[19:10:00] <fuzzie> because the backend can't implement a BAM-aware Sprite2D subclass, right?
[19:10:34] <fuzzie> because the BAMImporter is now hard-coded to create the Sprite2D itself for the BAM-friendly case
[19:11:00] <brada> so when does the backend need to create a bam sprite?
[19:11:07] <brada> other than with sprite->copy()
[19:11:18] <brada> which does share the data
[19:11:27] <fuzzie> does it?
[19:11:36] <brada> taht was my intent
[19:11:47] <fuzzie> the backend doesn't get the data, in your new code
[19:12:11] <fuzzie> unless I'm missing something really obvious
[19:12:40] <fuzzie> I see two paths: one of which is 'new BAMSprite2D' (backend doesn't get data), and one of which is the 'BAM not supported by backend' (backend doesn't get data).
[19:13:44] <fuzzie> and obviously a software-rendering backend can jsut check if BAM is true, and then access the data directly
[19:13:57] <fuzzie> but that doesn't work if you need to manage textures
[19:14:45] <fuzzie> it all looks fine other than those two things anyway.
[19:14:50] <brada> i still dont understand :(
[19:14:56] <fuzzie> well
[19:15:05] <fuzzie> I come along, and I want to make an OpenGLBAMSprite2D class.
[19:15:12] <fuzzie> It handles BAM data, and also textures.
[19:15:24] <fuzzie> How would I make one of those with this new design?
[19:15:36] <fuzzie> It seems like I can't, because the BAMImporter doesn't allow it.
[19:17:13] <lynxlynxlynx> same anim problem in bg2
[19:26:05] <Eli2> is it possible to use gemrb with a scaler like hq2x ?
[19:28:43] <brada> what is a scaler?
[19:28:46] <Lightkey> I think the graphics are too detailed to profit from scaler filters
[19:29:48] <fuzzie> in any case, no :)
[19:31:36] <Lightkey> anyway, the D&D collection at GOG.com is again 75 % off for the next 17-something hours
[19:31:56] <fuzzie> also loads of other stuff!
[19:32:44] <Lightkey> yes, Ultima series too
[19:32:54] <-- brada has left IRC (Ping timeout: 240 seconds)
[19:33:07] <Lightkey> that was too much to handle for brada
[19:33:25] <Eli2> brf
[19:33:31] <fuzzie> poor brada :/
[19:33:50] <Eli2> just wanted to anwser
[19:34:05] <fuzzie> no, no scalers.
[19:36:21] --> brada has joined #gemrb
[19:36:43] <brada> my internet went out was all...
[19:37:26] --> psch_ has joined #gemrb
[19:37:32] --> Pepelka has joined #gemrb
[19:37:33] <fuzzie> brada: anyway it all looks fine if you're happy.
[19:38:10] --> ermo_ has joined #gemrb
[19:38:13] <Lightkey> yes, just take these pills and be happy..
[19:40:35] <-- wjp has left IRC (Ping timeout: 248 seconds)
[19:40:50] <Lightkey> :O
[19:41:05] <-- ermo has left IRC (Ping timeout: 248 seconds)
[19:41:06] <-- Seniorita has left IRC (Ping timeout: 248 seconds)
[19:41:06] <-- psch has left IRC (Ping timeout: 248 seconds)
[19:41:07] <-- nutron has left IRC (Ping timeout: 248 seconds)
[19:41:08] --- ermo_ is now known as ermo
[19:41:08] <-- ermo has left IRC (Changing host)
[19:41:08] --> ermo has joined #gemrb
[19:41:09] <brada> fuzzie: i thought you were saying there is a problem with BAM support currently (software rendering) but you mean that the problem is being able to potentially support bams with opengl
[19:41:10] <brada> right?
[19:41:28] <fuzzie> yes!
[19:41:33] <fuzzie> it seems fine as-is.
[19:45:03] --> wjp has joined #gemrb
[19:45:12] <brada> fuzzie: once the texture is created why do we need the pixel data at all?
[19:45:14] <fuzzie> and it seems nicely designed, e.g. where you make the sprites do their own cloning, and the pixels == checking for mirroring
[19:45:20] <fuzzie> brada: because you'll run out of texture ram
[19:45:28] <brada> and thats not handled by opengl?
[19:45:38] <fuzzie> well, yes, but you lose a lot of RAM that way
[19:46:11] <brada> i am going to try and take an opengl class this fall...
[19:46:13] <fuzzie> also reading the contents of textures back is *slow*
[19:46:21] <brada> yes true
[19:46:32] <fuzzie> don't know how much that actually matters though
[19:46:34] <brada> but would we need that much with opengl?
[19:46:43] <fuzzie> so mostly I was just considering memory usage
[19:46:46] <brada> right
[19:46:49] <brada> wich is good
[19:48:33] --> nutron has joined #gemrb
[19:48:45] <fuzzie> the iOS docs don't talk about it specifically any more, they just warn that memory is a scarce resource, so don't keep your textures around
[19:49:47] <Lightkey> brada: https://en.wikipedia.org/wiki/Hqx fyi
[19:49:49] <Pepelka> hqx - Wikipedia, the free encyclopedia
[19:50:09] <fuzzie> and then it also says creating textures is expensive so do it all at startup
[19:50:17] <fuzzie> not very consistent
[19:52:01] <fuzzie> for performance there might be another consideration which is that you might not want one single texture for every BAM frame.
[19:52:12] <fuzzie> but maybe one big texture with all the frames in it. I don't know.
[19:52:17] <brada> indeed
[19:52:21] <brada> i thought of that too
[19:56:11] <brada> fuzzie: AddPolygonToSpriteCover is SDL specific because we would do it another way with opengl?
[19:56:51] <fuzzie> yes
[19:57:04] <fuzzie> dont' know if that's smart
[19:57:59] <fuzzie> but in any case for opengl you'd want a mask rather than individual scanlines
[20:04:49] <brada> lynx: what is the nature of the animation issues?
[20:05:06] <brada> i assume you are telling me my changes broke something
[20:23:29] <brada> i fixed the png palette crash with this: https://github.com/bradallred/gemrb/commit/2823d16bb34c1dd87dd361600aa178869003a966
[20:23:31] <Pepelka> Interface: move video display creation to init · 2823d16 · bradallred/gemrb · GitHub
[20:23:32] <Pepelka> »gemrb - Game Engine Made with preRendered Background«
[20:23:40] <brada> is that undesireable for some reason?
[20:23:56] <brada> we need to do that for opengl anyway afik
[20:27:44] <brada> did find an odd crasher related to my changes tho
[20:28:10] <brada> attempting to scroll the demo viewport crashes when trying to change the cursor
[20:40:42] <brada> the same crash does not occur using standard game data
[20:44:41] <brada> ok tis is bizarre
[20:45:10] <brada> the problem definitely exists in master, but smehow it doesnt crash
[20:45:25] <brada> line 1612 of GameControl.cpp
[20:45:45] <brada> cursor is NULL but somehow cursor->release(); isnt crashing on master
[20:45:49] <fuzzie> why would it?
[20:45:50] <brada> o_O
[20:45:59] <brada> how can you -> a null?
[20:46:17] <fuzzie> because it's not really a member call
[20:46:22] <fuzzie> it just calls FreeSprite on the Video driver
[20:46:39] <fuzzie> I did wonder if you replacing FreeSprite with release would break stuff
[20:46:53] <fuzzie> but I didn't think to look if anything was silly enough to use release already :-P
[20:50:00] <brada> so easy fix then
[20:50:19] <brada> jsut replace that release call with video->FreeSprite(cursor)
[20:50:39] <fuzzie> doesn't that break in your shiny new model though?
[20:50:43] <brada> no
[20:51:09] <brada> and it does fix the crash
[20:56:02] <lynxlynxlynx> brada: like vertically flipped frames now and then
[20:56:08] <brada> ok
[20:56:13] <brada> so should be fixed then
[20:56:19] <lynxlynxlynx> can't really describe it better, but i've never seen any problem like that before
[20:57:07] <brada> i saw that i wasnt copying the renderflags during duplication and also mirroring a mirrored bam was broken
[21:19:33] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[21:56:18] <-- kingron has left IRC (Quit: Leaving)
[22:23:43] <-- brada has left IRC (Quit: brada)