#gemrb@irc.freenode.net logs for 23 Feb 2013 (GMT)

Archive Today Yesterday Tomorrow
GemRB homepage

[00:01:22] <thomcom> fast invsqrt is just a mystery
[00:01:24] <thomcom> :D
[00:05:25] <psch> i saw a blog post somewhere some time ago that explained the math behind it, and how to get different magic numbers for different precisions i think
[00:05:37] <psch> i didnt understand that either :/
[00:09:22] <thomcom> there's a big wiki page on it now, math isn't any less inscrutable
[00:12:52] <wjp> wow, that is one clever trick
[00:15:33] <psch> i like how no one knows the exact origin
[00:15:53] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[00:27:54] <-- lynxlynxlynx has left IRC (Remote host closed the connection)
[00:35:40] <-- nutron has left IRC (Remote host closed the connection)
[00:41:46] --> nutron has joined #gemrb
[00:47:18] <-- nutron has left IRC (Read error: Connection reset by peer)
[00:48:45] --> nutron has joined #gemrb
[00:53:03] <traveler> i was right
[00:53:12] <traveler> you can choose in config.exe
[00:53:18] <traveler> heart of fury
[00:53:23] <traveler> before foinishing gam
[00:53:27] <traveler> *finishing game
[00:53:43] <traveler> moreover, difficulty=4
[00:53:48] <traveler> is only very hard
[00:53:57] <traveler> highest normal mode is insane (5)
[00:54:06] <traveler> which when set is breaking slider ingame
[00:54:27] <traveler> *when set from config
[02:07:36] <-- duckpunch has left IRC (Quit: Lost terminal)
[02:13:24] <-- edheldil_ has left IRC (Ping timeout: 252 seconds)
[03:51:31] <-- brada has left IRC (Quit: brada)
[04:23:23] --> thomcom has joined #gemrb
[05:26:13] <-- fireglow has left IRC (Remote host closed the connection)
[05:30:48] --> fireglow has joined #gemrb
[05:36:18] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[06:00:52] --> brada has joined #gemrb
[06:07:16] <-- brada has left IRC (Ping timeout: 248 seconds)
[06:18:35] --> brada has joined #gemrb
[06:22:44] <-- brada has left IRC (Ping timeout: 248 seconds)
[06:32:20] --> edheldil_ has joined #gemrb
[07:00:49] --> brada has joined #gemrb
[07:03:16] <-- brada has left IRC (Client Quit)
[07:04:14] --> brada has joined #gemrb
[07:05:54] <-- brada has left IRC (Client Quit)
[07:52:27] <-- edheldil_ has left IRC (Ping timeout: 260 seconds)
[07:54:36] <-- edheldil has left IRC (Remote host closed the connection)
[07:57:07] <-- WingedHussar1 has left IRC (Ping timeout: 260 seconds)
[07:57:49] --> WingedHussar has joined #gemrb
[08:02:31] <-- kida has left IRC (Remote host closed the connection)
[09:40:26] <-- traveler has left IRC (K-Lined)
[09:48:49] --> lynxlynxlynx has joined #gemrb
[09:48:49] <-- lynxlynxlynx has left IRC (Changing host)
[09:48:49] --> lynxlynxlynx has joined #gemrb
[09:48:49] --- ChanServ gives channel operator status to lynxlynxlynx
[09:51:14] --> fizzle has joined #gemrb
[10:00:11] <fizzle> can I assume that SpawnGroups are not used inside regular Spawns?
[10:00:26] <fizzle> or if they do, which takes precedence?
[10:00:38] <fizzle> since they both define difficulty and stuff
[10:02:40] <fuzzie> isn't that the only place they're used?
[10:03:09] <fizzle> I don't know, that's why I'm asking :P
[10:03:10] <fuzzie> oh, no, I guess also in rest code
[10:03:22] <fuzzie> anyway they're separate
[10:05:04] <fuzzie> you work out if you should be triggering a spawn, and if so, you spawn SpawnGroups/creatures as appropriate
[10:05:37] <fizzle> yes, but a Spawn has a difficulty and a SpawnGroup has a difficulty, too
[10:05:45] <fizzle> so I don't know what's appropriate
[10:05:52] <fuzzie> they're different :)
[10:06:13] <fizzle> not much
[10:06:15] <fuzzie> i mean, presumably you're trying to do something in particular here
[10:06:19] <fuzzie> perhaps you should explain what first
[10:06:26] <fuzzie> because you use *both* difficulties afaik
[10:06:39] <fizzle> I'm just trying to fix Spawns (for bg1 anyway)
[10:06:56] <fuzzie> right, but what in particular are you trying to fix right now?
[10:07:14] <fizzle> so a creature spawned from a group needs to take into account both difficulties (which means stay below both)?
[10:07:18] <fuzzie> no
[10:07:32] <fuzzie> we already have code to handle the difficulty for the spawn groups, right?
[10:07:40] <fizzle> yes
[10:07:55] <fizzle> but that completely ignores the spawn difficulty
[10:07:57] <fuzzie> no
[10:08:22] <fizzle> yes, it does
[10:08:32] <fizzle> it only checks Count
[10:08:52] <fizzle> which is different
[10:08:53] <fuzzie> it checks Level
[10:08:58] <fuzzie> which is what you are calling 'difficulty'.
[10:09:05] <fizzle> of the SpawnGroup, not the Spawn
[10:09:08] <fuzzie> yes
[10:09:19] <fuzzie> oh, I see
[10:09:22] <fizzle> so it does ignore the Spawn difficulty
[10:09:24] <fuzzie> sorry, I misinterpreted what you said
[10:09:28] <fuzzie> yes, but you didn't capitalise it :P
[10:09:42] <fuzzie> What I mean is that the spawn group difficulty is already handled.
[10:09:52] <fuzzie> In theory.
[10:10:08] <fizzle> right
[10:10:24] <fuzzie> what you mean is, you want to handle the Spawn difficulty in the same way?
[10:10:44] <fizzle> pretty much, yes
[10:10:52] <fizzle> according to iesdp
[10:11:03] <fuzzie> does it have the bg1 rules though?
[10:11:19] <fizzle> it has cre v1
[10:11:30] <fuzzie> yeah, that means 'bg2' :p
[10:11:31] <fizzle> so I assume it does
[10:11:48] <fizzle> eh, but it would make sense for bg1, too, afaics
[10:11:49] <fuzzie> i mean, where are you seeing the iesdp explanation?
[10:12:01] <fuzzie> well, the background is basically that this is known for bg2
[10:12:11] <fuzzie> and everyoen is sure it's inconveniently different for bg1.
[10:12:14] <fizzle> http://gemrb.org/iesdp/file_formats/ie_formats/are_v1.htm#formAREAV1_0_Spawn
[10:12:15] <fuzzie> but no-one knows how.
[10:12:16] <Seniorita> ARE File Format
[10:12:30] <fuzzie> and afaik the only info in iesdp is the bg2 info.
[10:13:04] <fizzle> from the spawns I've looked at the bg2 rules would be better than what we have now, then
[10:13:39] <fizzle> (except I think they mean Difficulty when the say Frequency)
[10:14:04] <fizzle> which would be very similar to the SpawnGroup logic, too
[10:14:05] <fuzzie> no
[10:14:15] <fuzzie> 0x76 is what you're calling Difficulty
[10:14:39] <fizzle> yes
[10:14:52] <fizzle> but the formula doesn't actually use that
[10:14:55] <fuzzie> oh right
[10:15:00] <fuzzie> uh, let me check
[10:16:16] <fuzzie> the problem is that iesdp is just copied directly out of our forum threads in cases like this
[10:16:21] <fuzzie> so it' not necessarily consistent at all :/
[10:16:40] <fizzle> some of it is rather hard to intrepret
[10:18:18] <fuzzie> yeah so that formula is crazy
[10:18:36] <fuzzie> http://forums.gibberlings3.net/index.php?showtopic=17946&st=45&p=154954&#entry154954 is the authorative source for bg2 behaviour
[10:18:38] <Seniorita> Random notes - The Gibberlings Three Forums - Page 4
[10:18:53] <fuzzie> where 0x9a means the rest spawn Difficulty field, so at 0x76 for non-rest spawns
[10:20:22] <fizzle> ah, that makes more sense
[10:21:38] <fuzzie> so maybe modify SpawnCreature to take an optional pointer to a difficulty-so-far variable, and if it's non-NULL, handle everything there (including that check for the first spawn I guess)
[10:22:23] <fizzle> that's one possible change, yes, and we need to handle Maximum, too
[10:22:41] <fuzzie> hence 'maybe' :)
[10:22:52] <fizzle> since we currently only spawn a single gibberling for a lvl 8 party
[10:23:49] <fuzzie> later in the thread devSin notes that the difficulty thing looks perhaps the same for bg1
[10:25:11] --> rocket_hamster has joined #gemrb
[10:35:04] <Seniorita> [wiki] todo - [Icewind Dale] http://www.gemrb.org/wiki/doku.php?id=todo&rev=1361615391&do=diff
[10:51:06] --> traveler has joined #gemrb
[11:44:53] <-- nutron has left IRC (Ping timeout: 256 seconds)
[11:49:16] --> nutron has joined #gemrb
[11:53:09] <-- rocket_hamster has left IRC (Remote host closed the connection)
[11:55:00] <-- nutron has left IRC (Max SendQ exceeded)
[12:00:14] --> nutron has joined #gemrb
[13:04:50] <traveler> is there a wat to restore control from cinema mode?
[13:04:56] <traveler> *way
[14:01:12] <fizzle> here's what I have on spawns now: http://paste.debian.net/hidden/ce7df0c7/
[14:01:13] <Seniorita> Debian Pastezone
[14:02:31] --> Yoshimo has joined #gemrb
[14:17:04] <lynxlynxlynx> traveler: EndCutSceneMode()
[14:22:04] <fizzle> lynxlynxlynx: tried the clock stuff yet?
[14:24:46] <lynxlynxlynx> wanted to check yesterday, but the paste expired
[14:24:58] <lynxlynxlynx> can do later today
[14:25:19] <fizzle> I'll upload it again
[14:27:44] <fizzle> http://paste.debian.net/hidden/9c2edb01/
[14:27:46] <Seniorita> Debian Pastezone
[14:44:00] --> rocket_hamster has joined #gemrb
[14:45:38] <-- rocket_hamster has left IRC (Client Quit)
[14:49:57] <traveler> lynx: ty, passed it already
[15:13:25] <psch> well alright
[15:13:39] <psch> i went and reset my local gemrb repo
[15:14:13] <psch> applied the patch and the fix for SDL_CreateRGBSurface
[15:14:24] <psch> and the touch input works
[15:15:39] <psch> so i guess i messed up something somewhere
[15:16:11] <psch> touch input is a bit wonky, buttons far on the left or right react a bit further offset to the corresponding direction, but that's probably because gemrb renders at 800x600 but screen dimensions are 1280x736
[15:16:31] <psch> what doesn't work right now is quitting the game, it just hangs
[15:16:52] <psch> and i dont have any possibility of keyboard input
[15:17:17] <psch> the latter might be because of the .cfg? i think i saw something wrt softkeyboard in there
[15:18:20] <psch> sorry for the headaches and whatnot anyway, this really seemed to have been some stupidity on my part
[15:23:00] <lynxlynxlynx> yeah, the keyboard is configurable
[15:23:10] <lynxlynxlynx> though it is also possible it is currently in an apple ifdef
[15:32:34] <psch> well, it seems to be working fine
[15:32:46] <psch> ill try with widescreen, to if that solves the button-misplaced thingy
[15:33:08] --> brada has joined #gemrb
[15:37:30] <brada> psch: just glad it works really
[15:37:38] <brada> is that from head?
[15:38:01] <brada> i mean was that fingerid -1 stuff even necessary
[15:38:38] <brada> it almost sounds like you didnt clean something
[15:38:49] <psch> well i looked around the log a bit more
[15:39:05] <psch> and i did changed touchId to fingerId somewhere
[15:39:13] <brada> oh god
[15:39:15] <brada> ha ha ha
[15:39:20] <psch> you told me to!
[15:39:22] <brada> yeah
[15:39:24] <psch> in my defense, i have no clue
[15:39:30] <psch> but it explains everything
[15:39:32] <psch> my touchId is 2
[15:39:33] <brada> YES IT DOES
[15:39:38] <brada> sorry
[15:39:45] <brada> didnt mean for caps
[15:39:49] <psch> so only 3 fingers get a valid state
[15:39:52] <psch> etc etc
[15:39:55] <brada> right
[15:40:29] <brada> sad that you get some odd behavior tho
[15:40:42] <psch> well it fits with the resolution discrepancy
[15:40:54] <brada> ill have to take yoru word for it
[15:41:02] <brada> but you should be able to put any res in the cfg now
[15:41:10] <brada> and gemrb will scale to fit it best
[15:41:13] <psch> yeah ill try native resolution next
[15:41:29] <brada> you dont even need widescreen mod
[15:41:36] <brada> unless you want it
[15:41:48] <brada> does fullscreen work?
[15:41:55] <brada> ie does it hide the status bar
[15:41:59] <psch> no
[15:42:08] <psch> i have Fullscreen=1 but the menu bar stays
[15:43:11] <brada> lame
[15:43:18] <fuzzie> what do you want it to do?
[15:43:33] <psch> it might be tablet specific i think? seeing as tablets usually dont have a home button
[15:43:52] <psch> so without the bar there's no way to suspend a fullscreen process manually
[15:43:53] <fuzzie> most modern android devices have no home button
[15:44:04] <fuzzie> so indeed, you're not allowed to remove the bar
[15:44:06] <psch> idk, my only other android device has touchbuttons
[15:44:07] <fuzzie> it is possible to hide it though
[15:44:26] <fuzzie> but your app doesn't get control over that area of the screen
[15:44:43] <fuzzie> it just fades out until user touches it.
[15:45:12] <brada> oh
[15:45:20] <psch> i also get the following in the log when i quit gemrb
[15:45:21] <brada> i still have android 2.3 :(
[15:45:22] <psch> I/SDL ( 7920): [STUB] GL_DeleteContext
[15:45:25] <psch> and it hangs
[15:45:35] <fuzzie> brada: well it's device-specific anyway.
[15:45:49] <psch> anyway, gonna change the resolution and report back about button behavior!
[15:45:50] <fuzzie> If you have physical buttons then you don't get the bar.
[15:47:07] <fuzzie> http://www.google.com/nexus/images/n4-product-hero.png <- this is typical
[15:47:46] <psch> hm, nice
[15:47:51] <psch> one thing i forgot to mention
[15:48:07] <psch> the intro video after "New Game" had a flickering overlay of the narration screen
[15:48:16] <psch> that's gone with native resolution
[15:48:20] <brada> i wonder if that hang is due to the nice exit stuff
[15:48:35] <brada> except if that were the case he should have the save window presented
[15:48:39] <brada> i guess
[15:48:41] <fuzzie> it is nice but you did conclude correctly about why you're not allowed to remove the bar :)
[15:48:48] <brada> sure
[15:49:00] <brada> doesnt matter to me anyway
[15:49:12] <fuzzie> afaict the official sdl2 tree doesn't obey fullscreen at all, it just force-sets it
[15:50:05] <brada> pash: did that help the touch input?
[15:50:14] <psch> from the looks of it, yeah
[15:50:26] <psch> i couldnt resist watching the full intro
[15:50:35] <psch> gonna test char creation, that's a pretty good test i think
[15:50:35] <brada> forgive my typing. its very early here
[15:50:51] <brada> and i stayed up quite late giving myself a bit of a hangover :p
[15:51:25] <brada> psch: form here on out there isnt anything diffrent from the standard build
[15:51:53] <fuzzie> but I guess you could add hide code to the java easily enough if you wanted.
[15:52:40] <brada> nah
[15:53:16] <psch> so then ill try without the experimental patch from yesterday
[15:53:18] <psch> see if that also works
[15:53:21] <fuzzie> it's just slightly messy because it's Android 3.0+ only so you have to do it with reflection or another class.
[15:53:26] <brada> well i already committed it
[15:53:29] <psch> oh
[15:53:30] <psch> alright
[15:53:40] <brada> fuzzie knows what she is talking about
[15:53:50] <brada> if she says 0 is valid good enough for me
[15:54:01] <fuzzie> well, also it helps that -1 is invalid :)
[15:54:08] <brada> for sure
[15:54:18] <psch> the softkeyboard doesn't close with the "Enter name" dialogue
[15:54:27] <psch> as in, i hit enter on the kbd, the dialogue closes, keyboard stays
[15:55:00] <psch> and touches sometimes dont come through on the first attempt, i think that's slow fingers on my hand though
[15:55:08] <psch> the locations seem fine with native resolution
[15:55:22] <psch> button locations that is
[15:55:28] <fuzzie> sounds very positive
[15:56:37] <brada> how slow is gemrb?
[15:56:58] <brada> one of the reasons beholder abandoned adl2 was due to less than 20 fps
[15:57:09] <psch> that's about what i get here, from eyeballing
[15:57:12] <brada> even with optimized builds of sdl and gemrb iirc
[15:57:17] <brada> yuck
[15:57:20] <fuzzie> it's better with pelya's build?
[15:57:30] <fuzzie> obvious question, you're using 16-bit graphics, right?
[15:57:34] <psch> pelya doesn't build against sdl2
[15:57:44] <psch> i have Bpp=16 in GemRB.cfg
[15:58:02] <brada> yeah that setting doesnt help much with sdl2
[15:58:08] <fuzzie> no?
[15:58:12] <psch> no
[15:58:16] <psch> he has a project against sdl1.3
[15:58:21] <psch> but i couldn't build that succesfully
[15:58:21] <fuzzie> no, i mean at brada
[15:58:31] <brada> well with ios you get 30fps
[15:58:35] <brada> with or without
[15:58:46] <fuzzie> gemrb's sdl video driver seems to ignore bpp
[15:59:07] <fuzzie> if I understand it right?
[15:59:08] <brada> so i have no idea but i imagine the slowdown between 1.2 on android and 2.0 is the fact that we are creating and destroying a screen sized texture every frame
[15:59:39] <brada> and yes sdl2 dirver may ignore it
[15:59:55] <fuzzie> so, that's a slowdown right there..
[16:00:02] <brada> do you think it would be faster to have 16bpp backbuff for rendering to
[16:00:10] <brada> then convert to the native 32bpp te?
[16:00:12] <fuzzie> no
[16:00:12] <brada> tex
[16:00:18] <fuzzie> why would you use 32bpp natively?
[16:00:27] <brada> well i dont know about android
[16:00:35] <brada> but thats the only choice on ios
[16:00:43] <fuzzie> well, this is one of the things which annoys me about official sdl2
[16:01:00] <brada> the sdl docs say that no matter what you request you get some rgb 32 bpp context
[16:01:02] <fuzzie> they don't bother with the display format stuff
[16:01:09] <fuzzie> on android
[16:01:26] <brada> psch isnt necessarily using the best backbuf format either
[16:01:44] <brada> because for whatever reason we couldnt get the format the window was using
[16:01:52] <brada> osme sdl_mutex error
[16:02:01] <brada> which sounds like an sdl bug to me
[16:02:04] <psch> not quite happy with this tbh: http://imgur.com/olF0g0P
[16:02:06] <Seniorita> imgur: the simple image sharer
[16:02:26] <brada> that aint right lol
[16:02:52] <brada> on ios setting higher res then your resources just results in it scaling up
[16:03:09] <fuzzie> Android_JNI_CreateContext is called by Android_GL_CreateContext which does specify the bpp
[16:03:31] <fuzzie> so presumably there is some way to do that right
[16:03:49] <brada> ill bet we could squeeze more performance out of it
[16:03:53] <fuzzie> on iOS too
[16:05:10] <brada> i guess that interface problem is due to you using a non 4:3 ration
[16:05:13] <brada> ratio
[16:05:33] <brada> but then you have touch coordinate isssues
[16:05:45] <brada> but maybe you feel like figuring out how to fix that :D
[16:05:53] <-- traveler has left IRC (Ping timeout: 245 seconds)
[16:06:13] <fuzzie> the upstream android code looked pretty dubious on the touch coordinate front
[16:06:29] <fuzzie> i suspect everyone might just use it at native res with opengl renderer
[16:06:41] <brada> well thats a pretty easy fix
[16:07:01] <brada> but really should be done inside sdl imo
[16:07:15] <brada> like it is for ios apparently
[16:09:22] <psch> the sdl window size i get is always native resolution, independent of GemRB.cfg settings
[16:09:56] <psch> i dont know if thats true for ios, if it's not that could be the cause i guess
[16:12:09] <psch> but then im pretty much still simply guessing heh
[16:14:39] --> rocket_hamster has joined #gemrb
[16:17:13] <brada> well the window on ios is always the screen size too
[16:17:22] <brada> but the ogical render size is what you set it to
[16:17:27] <brada> logical
[16:17:55] <brada> it just sounds like ios compensates for that
[16:18:00] <brada> but android does not
[16:18:11] <brada> id call that an sdl bug
[16:20:32] --> edheldil_ has joined #gemrb
[16:22:49] <psch> so you're saying i screwed something up again ;)
[16:23:25] <psch> you're not actually saying that, im just trying to be funny
[16:24:07] --> kida has joined #gemrb
[16:25:23] <brada> psch: what happens with 800x600 and fullscreen?
[16:25:30] <brada> does it scale to fill the screen then?
[16:25:43] <psch> no
[16:25:46] <psch> that's what i ran first
[16:26:05] <psch> let me check again though
[16:26:59] <brada> well feel free to muck around with the CreateDisplay code
[16:27:20] <brada> tryp creating a buckbuf that is rgb565
[16:27:28] <brada> see if you get better performance
[16:28:21] <psch> actually
[16:28:27] <psch> i think it scales, but keeps the aspect ratio
[16:28:44] <psch> fonts are a bit messed up, which indicates scaling, and i dont have empty space above the menubar
[16:28:55] <psch> but i do have black bars on the left and right
[16:29:28] <psch> touch input coordinates are also only warped on the horizontal axis
[16:30:59] <psch> i still need to call SDL_CreateRGBSurface with r = g = b = 0 btw, don't know if that was clear
[16:31:26] <brada> psch: yes it probably does keep ratio
[16:31:56] <brada> how do you figure you need to call with 0?
[16:32:03] <brada> that makes no sense
[16:32:06] <psch> well that's the fix you gave me
[16:32:13] <brada> it was not a "fix"
[16:32:18] <brada> a hack at best
[16:32:18] <psch> otherwise it segfaults
[16:32:21] <psch> yes, i know
[16:32:31] <brada> but use rgb565
[16:32:42] <brada> instead of 0
[16:34:12] <psch> as in, call with the values as per http://www.fourcc.org/rgb.php#RGBA
[16:34:13] <Seniorita> RGB pixel formats
[16:34:28] <psch> probably not, cause it says "can be described.."
[16:34:37] <brada> change winFormat to SDL_PIXELFORMAT_RGB565 instead of mucking with rgba values
[16:34:47] <psch> okay
[16:36:25] <brada> you still need to set a to 0
[16:36:31] <brada> probably
[16:36:39] <psch> i didnt have to set it previously
[16:37:30] <brada> because i already did that for you
[16:37:52] <brada> the a = 0 right below SDL_PixelFormatEnumToMasks ;)
[16:39:04] <psch> im ok with that
[16:44:32] <brada> so better?
[16:45:19] <psch> if anything it's actually worse
[16:45:40] <psch> hard to compare side by side, but it doesn't seem better at all
[16:45:51] <psch> err, hard to compare without having it side by side i mean
[16:46:05] <brada> we have the ability to output fps
[16:46:12] <brada> tho i forget how
[16:46:28] <psch> right
[16:46:41] <psch> there's a setting in the config
[16:46:47] <psch> if that works..?
[16:47:32] <psch> it does
[16:47:35] <psch> 18 in the menu
[16:47:44] <psch> with rgb565
[16:47:57] <brada> yuck
[16:48:08] <brada> feel free to try other values
[16:48:16] <psch> movie playback is also ~18
[16:48:41] <brada> you probably want to also add this->bpp = bpp;
[16:48:53] <brada> not sure if that is used anywhere to create sprites
[16:48:58] <brada> but it wont hurt
[16:50:40] --> thomcom has joined #gemrb
[16:51:28] <psch> so which of the pixelformats make sense to try?
[16:52:16] <psch> id assume only the RGB ones
[16:52:28] <brada> yes
[16:52:34] <brada> did you add that line?
[16:52:47] <psch> yeah i added the assignment just now
[16:53:52] <psch> but seeing as RGB is obviously something different than RGBA i don't know which pixelformat to try
[16:54:02] <brada> er wait
[16:54:09] <psch> http://wiki.libsdl.org/moin.cgi/SDL_PixelFormatEnum
[16:54:11] <brada> im not sure what code you have anymore
[16:54:15] <Seniorita> SDL_PixelFormatEnum - SDL Wiki
[16:54:24] <brada> you have this SDL_PixelFormatEnumToMasks(winFormat, &this->bpp, &r, &g, &b, &a);
[16:54:37] <brada> and got rid of the separate rgb assignments correct?
[16:54:50] <psch> yeah
[16:54:55] <brada> if thats the case remove the this->bpp assignment
[16:55:04] <brada> that will be set by the SDL_PixelFormatEnumToMasks(winFormat, &this->bpp, &r, &g, &b, &a); line
[16:55:20] <psch> alright
[16:55:27] <brada> then just test new formats by changing winformat
[16:56:11] <brada> you nee to change the SDL_CreateRGBSurface to use this->bpp
[16:56:12] <brada> tho
[16:56:26] <psch> ok
[16:56:39] <brada> there
[16:56:49] <brada> now you should be good to test
[16:57:08] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[16:57:40] <psch> well the sdl wikipage only has one RGB format for 16 bit, if i understand that correctly
[16:57:52] <psch> so i should test 24 and 32 bits?
[16:58:02] <psch> oh there's RGB555, i missed that
[16:58:07] <psch> i guess i could try that at least
[16:58:33] <psch> because 15 is close to 16...
[16:59:22] <brada> the 16th bit for that is alpha iirc
[16:59:46] <brada> but i suggested rgb565 because your logs led me to believe that was the opengl context format
[17:00:05] <brada> and 16 bit software blits should be faster
[17:00:30] <brada> you will want to retest everything since that change tho
[17:00:40] <brada> in case anything uses the bpp setting to make sprites
[17:00:56] <brada> we want to avoid expensive conversions
[17:01:06] <brada> between 16bit and 32bit
[17:02:24] --> thomcom has joined #gemrb
[17:03:04] <psch> yeah, the logs have something about rgb565 being the format, i remember that
[17:03:16] <psch> there's RGB555 and RGBA5551 though
[17:03:23] <psch> i think the first just doesn't use the 16th bit
[17:04:40] <psch> okay, that totally garbles colors, obviously
[17:04:44] <psch> and gives me 6 fps
[17:06:04] <thomcom> did you try bgr565?
[17:06:32] <thomcom> wouldn't surprise me one big since this is all initially windows software
[17:06:46] <psch> ill try that
[17:12:16] <psch> that has inverted colors, which makes sense, and 6 fps
[17:12:54] <thomcom> Are the colors right now with RGB, just slow fps? I saw your image link from 16:02
[17:13:25] <psch> yeah the image is RGB565 with ~18 fps
[17:13:32] <psch> the one with the wonky hud
[17:23:30] <thomcom> seems to me that optimization is a lower priority than getting the hud rendered properly
[17:24:02] <thomcom> looks like there's a big spot of tearing in your link too, is that right?
[17:24:28] <thomcom> I don't remember the color scheme of BG2 but it looks basically correct to me in your image
[17:24:41] <psch> the hud works when i run in 800x600, it's some scaling issue
[17:24:52] <thomcom> so SDL_PixelFormatEnumToMasks is working correctly with that image
[17:25:00] <psch> no, it's hardcoded there
[17:25:02] <thomcom> SDL_PixelFormatEnumToMasks won't have anything to do with scaling afaik
[17:25:48] <thomcom> but when you run at 800x600 its rendered in android at native resolution instead of full screen? sorry, just reading the logs and making sense out of your conversation :)
[17:26:11] <psch> it's scaled to fit vertically
[17:26:22] <psch> but keeps aspect ratio
[17:26:54] <psch> which results in touch input getting weird, as in, off-center buttons react further to the sides than they are rendered
[17:28:39] <psch> oh
[17:29:26] <psch> brada: passing this->bpp instead of bpp to SDL_CreateRGBSurface seems to have removed the SDL_PIXELFORMAT_UKNOWN crash
[17:30:51] <psch> but the colors seem off
[17:31:07] <brada> hud is a non issue
[17:32:22] <psch> oh nevermind, i didnt install the build after pushing it to the device
[17:32:35] <psch> so for some reason we can't get the proper pixelformat for the display
[17:33:42] <psch> that's the mutex thing, right
[17:35:21] <wjp> what do mutexes have to do with pixelformats?
[17:36:50] <psch> "Passed a NULL mutex." is the error message i get from calling SDL_GetError() after calling SDL_GetWindowPixelFormat
[17:37:10] <psch> SDL_GetWindowPixelFormat still returns SDL_PIXELFORMAT_UNKNOWN
[17:37:30] <psch> which means that SDL_GetError() should give that error
[17:37:37] <psch> i.e. pixelformat unknow
[17:37:39] <psch> n
[17:37:58] <psch> no that's wrong
[17:38:34] <wjp> is SDL's video already initialized there?
[17:38:38] <psch> getwindowpixelformat only sets SDL_Error when it gets called on an invalid window
[17:39:16] <-- Yoshimo has left IRC (Quit: Yoshimo)
[17:39:56] <psch> it should be
[17:40:05] <psch> it definitely is created
[17:40:11] <psch> not sure how long initializing might take
[17:44:28] <psch> but that blocks anyway, doesnt it
[17:44:35] <psch> seeing as SDL_CreateWindow returns the window
[17:46:30] <wjp> anyway, if RGB565 is 18fps but others are 6fps, that does suggest RGB565 is the right one
[17:51:32] <fuzzie> rgb565 is almost always the best format for mobile gpus
[17:55:14] <-- fizzle has left #gemrb
[18:04:08] <psch> could the SDL_Surface change in sdl2 have something to do with the performance degradation?
[18:04:23] <psch> seeing as those aren't ever accelerated anymore
[18:05:32] <gembot> build #269 of nmake-msvc++6 is complete: Failure [4failed compile] Build details are at http://buildbot.gemrb.org/builders/nmake-msvc%2B%2B6/builds/269 blamelist: Brad Allred <bradallred@me.com>
[18:06:57] <psch> hm, probably not, seeing as the driver is explicitely written for sdl2 and does create an SDL_Texture before swapping buffers
[18:08:18] <psch> fyi, SDL_GetError returns "Passed a NULL mutex." even right after starting the app
[18:08:39] <psch> which seems to indicate everything goes as it should but the pixelformat isn't defined
[18:09:04] <psch> i can't say anything to that, because i don't really get SDL_pixels.h
[18:17:58] <-- thomcom has left IRC (Ping timeout: 245 seconds)
[19:02:10] <psch> 800x600 gives me ~30 fps btw
[19:03:03] <psch> which isnt that surprising, seeing as it's about half as many pixel
[19:21:42] <brada> psch: we dont actually use sdl_textures
[19:21:57] <brada> all our rendering is software
[19:22:17] <brada> we then convert to a texture right before displaying the backbuffer on screen
[19:22:19] <brada> very slow
[19:33:04] <-- rocket_hamster has left IRC (Quit: bye!)
[19:57:07] --> traveler has joined #gemrb
[20:11:01] <-- kida has left IRC (Remote host closed the connection)
[20:26:59] <psch> i see
[20:27:40] <psch> from the looks of it, there's not much code dealing with SDL_Surface in SDL20Video.cpp nor SDL12Video.cpp
[20:28:09] <psch> which probably means much refactoring of SDLVideoDriver if SDL_Textures where to be supported...
[20:28:29] <wjp> that'll take rewriting, not refactoring
[20:28:31] <psch> leaving aside the obvious issue of "does this actually make sense to do?"
[20:28:42] <psch> maybe that
[20:28:47] <psch> or rather, probably
[20:28:53] <psch> seeing as you most likely actually know the code
[20:29:39] <psch> i think refactor actually is the wrong word, yeah
[20:30:24] <psch> but the intended end result would be letting the video driver use surfaces with SDL12Video and textures with SDL20Video
[20:30:59] <psch> anyway, yeah, that's not for me to do
[20:31:07] <wjp> it's not so much a surface vs texture as it is software blitting vs hardware accelerated rendering
[20:31:56] <psch> surface has hw acceleration in 1.2, doesnt it
[20:32:08] <psch> but that's not being utilized in the existing code base?
[20:32:40] <wjp> no useful type of acceleration for us
[20:33:09] <psch> and that wouldnt change with textures
[20:35:00] <wjp> right
[20:36:02] <psch> well, that's a bit disappointing
[20:43:38] <psch> anyway, ill write up a script for creating the build env and prebuilding libs as well as clean the makefile a bit during the next few days
[20:43:58] <psch> although the issue with not getting the right pixelformat probably needs to be solved somehow still
[20:44:02] <wjp> cool
[20:44:35] <psch> oh, im not sure what to do with python though
[20:44:47] <psch> the libpython that works is from pelya, which im not so happy with
[20:45:08] <psch> similarly, sdl_mixer only builds with mikmod from pelya, but openal works fine so i guess sdl_mixer can go
[20:46:16] <wjp> why is mikmod relevant?
[20:46:32] <wjp> but, yes, if openal works, go with that
[20:47:00] <psch> sdl_mixer depends on mikmod, and i didnt want to mess with lib makefiles
[21:00:30] <-- tomprince has left IRC (Ping timeout: 240 seconds)
[21:10:53] --> tomprince has joined #gemrb
[21:30:52] <traveler> haha
[21:31:26] <traveler> yuan-ti sorcerer just casted removal of effects on me an yxunomei
[21:33:01] <traveler> effectively rendering her defenceless i think.
[22:15:38] <brada> psch: its not a simple matter of just replacing surfaces with textures
[22:15:43] <brada> palettes and other things
[22:15:49] <brada> effects rendering
[22:16:04] <brada> we already know what we need to do
[22:16:08] <brada> its just a lot of work
[22:18:59] <psch> yeah, i understand that
[22:19:23] <psch> it's not like i thought some sed -i -e',s/SDL_Surface/SDL_Texture/' would work...
[22:19:59] <psch> but i clearly don't know either about sdl nor gemrb to have any proper idea about the work required
[22:22:06] <psch> i'll just finish the android build stuff and rest on my accomplishment for a bit afterwards heh
[22:33:51] <-- Cable_ has left IRC (Ping timeout: 252 seconds)
[22:47:38] --> Cable_ has joined #gemrb