ScummVM IRC Log - 02 Jan 2015

[Back to Index]

[00:19] --> demonimin_ joined #scummvm.
[00:22] <-- demonimin left irc: Ping timeout: 245 seconds
[00:22] --> t0by joined #scummvm.
[00:22] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[00:35] --> demonimin joined #scummvm.
[00:38] <-- demonimin_ left irc: Ping timeout: 265 seconds
[00:39] <-- _sev|work_ left irc: Quit: This computer has gone to sleep
[00:42] <-- t0by left irc: Quit: Leaving
[00:50] --> demonimin_ joined #scummvm.
[00:53] <-- demonimin left irc: Ping timeout: 256 seconds
[01:15] sirlemonhead (bduncan22@95.44.164.183) left #scummvm.
[02:04] <-- Vanfanel left irc: Ping timeout: 240 seconds
[02:13] --> ___marc` joined #scummvm.
[02:13] Nick change: ___marc` -> _marc`
[02:13] <-- __marc` left irc: Ping timeout: 240 seconds
[02:31] --> Vampire0 joined #scummvm.
[02:33] <-- Dominus left irc: Ping timeout: 240 seconds
[02:33] <-- Vampire0_ left irc: Ping timeout: 250 seconds
[02:36] --> Dominus joined #scummvm.
[02:58] --> balrog joined #scummvm.
[03:29] --> Jon_God joined #scummvm.
[04:29] <-- Javacat left irc: Ping timeout: 276 seconds
[05:09] sloof (sloof@pdpc/supporter/student/sloof3) left #scummvm.
[05:21] <ScummBot_> Port build status changed with 34ec4ed6: Failure: master-osx_ppc
[05:38] <-- gapan left irc: Ping timeout: 244 seconds
[06:14] <-- Lightkey left irc: Ping timeout: 244 seconds
[06:27] --> Lightkey joined #scummvm.
[06:38] <-- SugarCube left irc: Ping timeout: 244 seconds
[06:41] <-- ScummBot_ left irc: Ping timeout: 256 seconds
[06:42] --> ScummBot joined #scummvm.
[06:50] --> SugarCube joined #scummvm.
[06:50] --> bgK joined #scummvm.
[06:50] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[07:00] <-- _marc` left irc: Quit: _marc`
[07:33] --> frankyboy_ joined #scummvm.
[07:55] <-- clone2727 left irc: Quit: later
[08:04] --> _marc` joined #scummvm.
[08:04] --> ny00123 joined #scummvm.
[08:54] --> salty-horse joined #scummvm.
[08:54] #scummvm: mode change '+o salty-horse' by ChanServ!ChanServ@services.
[09:06] <-- pigeon left irc: Read error: No route to host
[09:26] --> _sev|work joined #scummvm.
[09:26] <-- _sev|work left irc: Changing host
[09:26] --> _sev|work joined #scummvm.
[09:26] #scummvm: mode change '+o _sev|work' by ChanServ!ChanServ@services.
[09:38] --> edheldil joined #scummvm.
[09:40] <-- bgK left irc: Ping timeout: 264 seconds
[09:51] --> bgK joined #scummvm.
[09:51] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[09:56] <-- LordHoto left irc: Ping timeout: 250 seconds
[09:58] --> LordHoto joined #scummvm.
[09:58] #scummvm: mode change '+o LordHoto' by ChanServ!ChanServ@services.
[10:10] <fuzzie> g'morning
[10:10] <fuzzie> maybe someone should disable some engines on buildbot for osx_ppc?
[10:27] <-- Jon_God left irc: Remote host closed the connection
[10:37] --> t0by joined #scummvm.
[10:37] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[11:08] <Strangerke> http://www.youtube.com/watch?v=sU-XsgJJRyg
[11:16] <salty-horse> Strangerke, :D
[11:16] <salty-horse> moon walk!
[11:17] <Strangerke> Yep ;)
[11:20] --> Vanfanel joined #scummvm.
[11:21] <Vanfanel> fuzzie: fixed the debug problems I had. Do you know where's the code that's supposed to limit the cursor area when aspect ratio is respected and game area is smaller than output area?
[11:27] --> NotJavacat joined #scummvm.
[11:28] Nick change: NotJavacat -> Javacat
[11:28] <fuzzie> Vanfanel: in SDL.
[11:28] --> rootfather joined #scummvm.
[11:28] <fuzzie> no?
[11:30] <fuzzie> I mean, as in, in our SDL code. for opengl it delegates to OpenGLGraphicsManager::adjustMousePosition
[11:33] --> SylvainTV joined #scummvm.
[11:33] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[11:39] <Vanfanel> fuzzie: my backend uses opengl-graphics classs. So yes, OpenGLGraphicsManager::adjustMousePosition is used, but it doesn't work as expected, since cursor can go outside the game are. It's only limited by the phisical screen area, which is a wrong behaviour.
[11:41] <Vanfanel> fuzzie: I understan this CLIP macro is what limits the cursor area? --> https://github.com/vanfanel/scummvm/blob/gles_contexts/backends/graphics/opengl/opengl-graphics.cpp#L898
[11:43] <fuzzie> do you perhaps not set _displayWidth/_displayHeight correctly?
[11:46] <fuzzie> although I guess in that case you'd be drawing at the wrong coords..
[11:47] --> Quatroking joined #scummvm.
[11:51] <Vanfanel> fuzzie: _displayWidth is set inside the opengl-graphics class, in the recalculate screen area function.
[11:51] <Vanfanel> fuzzie: that's not what I am supposed to adjust.
[11:52] <fuzzie> _displayWidth is the actual width of the display, which your mouse coords should be in
[11:53] <Vanfanel> _displayWidth for example, it's value is copied from _outputScreenWidth (of the phisical screen size), then adjusted for te correct ratio
[11:53] <fuzzie> and then the code there transforms the coordinates to the width/height of the gameScreen
[11:53] <Vanfanel> both things are done correctly
[11:53] <fuzzie> if your _displayWidth isn't the actual width then that is your problem
[11:55] <fuzzie> are you doing this aspect correction manually, not using OpenGLGraphicsManager::recalculateDisplayArea? I'm confused here
[11:58] <Vanfanel> fuzzie: I'm using OpenGLGraphicsManager::recalculateDisplayArea. Well, it's used I mean. I don't call it from glesrpi.cpp, but the function is used.
[11:59] <Vanfanel> Also, _displayWidth is 1360 after _displayWidth = _outputScreenWidth in OpenGLGraphicsManager::recalculateDisplayArea()
[11:59] <Vanfanel> and 1360 is the phisical screen area
[12:00] <Vanfanel> the mouse does NOT leave the screen are
[12:00] <Vanfanel> the problem is that it leaves the "game" area
[12:00] <Vanfanel> maybe I didn't explain the issue well
[12:00] <Vanfanel> The mouse should be limited to the "game" area, shouldn't it?
[12:01] <Vanfanel> the mouse does NOT leave the screen area <--I was missing an "a"
[12:07] <fuzzie> as long as the overlay isn't present, yes
[12:08] <fuzzie> so the code in adjustMousePosition converts from _displayWidth/_displayHeight (adjusted by _displayX/_displayY) to _screenWidth/_screenHeight
[12:08] <fuzzie> erm, not _screenWidth/etc. the game width/height.
[12:09] <fuzzie> as long as you don't mess with the variables outside of OpenGLGraphicsManager::recalculateDisplayArea(), and you're not displaying an overlay, and you don't fiddle with the _gameScreen texture, it seems like the only thing which can go wrong is that your incoming mouse events are in the wrong coordinate system. did you try printing them?
[12:15] --> GitHub36 joined #scummvm.
[12:15] <GitHub36> [scummvm] sev- pushed 2 new commits to master: http://git.io/G-Dcvg
[12:15] <GitHub36> scummvm/master f4a9965 Eugene Sandulenko: FULLPIPE: Fix bug with spring in scene04
[12:15] <GitHub36> scummvm/master 76b71ca Eugene Sandulenko: FULLPIPE: Fix bug with unmovable jar in scene04
[12:15] GitHub36 (GitHub36@192.30.252.34) left #scummvm.
[12:19] <Vanfanel> fuzzie: coordinates seem to be correct, I mean, they change as expected if I print them in adjustMousePosition() when moving the mouse
[12:20] <fuzzie> I'm just confused though
[12:20] <fuzzie> let's go back to the start
[12:21] <Vanfanel> fuzzie: the problem is that when coords are x=0, y=0, the mouse is in the upper right side of the phisical screen, and it should be on the upper right side of the game screen
[12:21] <fuzzie> right
[12:21] <Vanfanel> that's precissely the problem
[12:21] <fuzzie> but that's not a clipping issue, right?
[12:21] <fuzzie> adjustMousePosition will adjust that to (0,0)
[12:22] <fuzzie> (I assume you mean upper-left)
[12:23] <Vanfanel> yeah, upper-left... sorry, I have a small problem with left and right.. :(
[12:23] <fuzzie> so you'll end up with the mouse being at 0,0, which is correct
[12:24] <Vanfanel> yes
[12:24] <fuzzie> is all your code on github?
[12:24] <Vanfanel> yes it is
[12:26] <Vanfanel> ah, i'm stepping through adjustMousePosition() and I see lines inside "if (_overlay) {" are executed? maybe that's part of the problem? I'm not using an overlay, I don't even know what it is in this context
[12:26] <fuzzie> scummvm UI
[12:27] <fuzzie> i.e. the launcher or the GMM
[12:27] <Vanfanel> but scummvm UI isn't visible unless I press F5
[12:27] <fuzzie> well, that code is wrapped in a _overlayVisible check
[12:27] <Vanfanel> I mean, once a game has started, nothing from scummvm UI is visible
[12:28] <Vanfanel> oh, so I shouln't worry then?
[12:28] <fuzzie> well, is _overlayVisible true?
[12:29] --> gapan joined #scummvm.
[12:29] <Vanfanel> fuzzie: it's false. (gdb) p _overlayVisible
[12:29] <Vanfanel> $10 = false
[12:30] <fuzzie> Vanfanel: so how can you reach those lines when stepping?
[12:30] <Vanfanel> that's strange! a moment...
[12:32] <-- ScummBot left irc: Ping timeout: 250 seconds
[12:32] <fuzzie> if _overlayVisible is set, then yes, the game screen clipping will be ignored :)
[12:33] <fuzzie> otherwise, I see on github that you didn't change any of these functions, so they're not relevant
[12:35] --> ScummBot joined #scummvm.
[12:39] <Vanfanel> fuzzie: sorry, my executable was newer than my code so gdb was wrong. lines inside "if (_overlayVisible)" are not executed when moving the mouse.
[12:41] <Vanfanel> fuzzie: look this is a debug session of adjustMousePosition when moving to x=0, y=0 --> http://pastebin.com/YinyK4bK
[12:42] <Vanfanel> x and y are adjusted: I don't end with 0,0, but with x=319, y=0
[12:42] <Vanfanel> but the cursor is outside the game area, on the upper-left side of the physical screen
[12:43] <fuzzie> I mean
[12:43] <fuzzie> when do you get x=319 and y=0?
[12:43] <fuzzie> (and which game is this? you're not seeing the cursor *drawn* there, right?)
[12:44] <fuzzie> maybe also try printing width and height and _displayWidth and _displayHeight and the intermediate values of x/y inside adjustMousePosition, but I don't think there's any chance it can be that function at fault, since the CLIP will constrain it to the width/height of the game screen
[12:45] <fuzzie> x=319 sounds suspiciously like you're hitting the maximum clip there
[12:46] <Vanfanel> I get x=319 and y=0 when I move the mouse letf and up EVEN if it's already at the upper-left point of the phisical screen. That way, x is 0 and y is 0 at the beggining of adjustMousePosition().
[12:46] <Vanfanel> But at the end of adjustMousePosition, x=319 and y=0
[12:46] <Vanfanel> the game is Monkey Island EGA
[12:47] <-- Kirben left irc:
[12:47] <fuzzie> so if you go from x=-66 to x=319, then either width or _displayWidth is wrong (negative), presumably?
[12:49] <fuzzie> but I am deeply suspicious of the use of int16 in this code
[12:50] <fuzzie> I don't see why it doesn't overflow in all circumstances
[12:51] <-- Cheeseness left irc: Quit: Leaving.
[12:52] <fuzzie> erm, almost all
[12:53] <fuzzie> does _displayWidth being a uint promote the whole expression?
[12:53] <Vanfanel> if that's a question for me, I don't know what "promote the whole expression" mean
[12:53] <fuzzie> but if so then it will promote it to a uint I guess
[12:54] <fuzzie> Vanfanel: did you try printing the intermediate values in gdb?
[12:55] <fuzzie> I think probably the x value immediately before the clip will be ridiculously high
[12:55] <Vanfanel> but look, x -= _displayX;, so x is initially 0 and after this it's 66.
[12:55] <fuzzie> before the clip :)
[12:56] <Vanfanel> yes, before the clip
[12:56] <fuzzie> -66 is too early
[12:56] <fuzzie> there are other calculations done between there and the clipping
[12:56] <fuzzie> and I'd like to know what it's like immediately before the clip
[12:57] <Vanfanel> ok I will print every variable there
[13:01] <-- frankyboy_ left irc: Remote host closed the connection
[13:08] <Vanfanel> fuzzie: here's a mostly complete debug session of the adjustMousePosition() function: http://pastebin.com/NseqTkNv
[13:09] <Vanfanel> I printed all the implied variables
[13:09] <-- bgK left irc: Ping timeout: 250 seconds
[13:09] <Vanfanel> *implicated I mean :)
[13:10] <fuzzie> so yes, x is overflowing
[13:12] <Vanfanel> so it's not my code then?
[13:12] <fuzzie> nope
[13:12] <fuzzie> change the _displayWidth to be '(int)_displayWidth'? and similarly for _displayHeight
[13:13] <Vanfanel> ok
[13:13] --> bgK joined #scummvm.
[13:13] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[13:13] <fuzzie> -66*320 = -21120, which is then converted to an unsigned int, the division then results in 0x355e29 which is truncated to 0x5e29 which is 24105, and then that's clipped to 319
[13:15] <fuzzie> but the whole calculation should be done in integers anyway, since an int16 can overflow in just the multiplication step. so fail on the part of whoever wrote that :P
[13:16] <ScummBot> Port build status changed with 76b71cab: Success: master-osx_ppc
[13:16] <fuzzie> which I guess is LordHoto
[13:16] <fuzzie> who can probably fix it more elegantly than I can.
[13:17] <-- bgK left irc: Ping timeout: 256 seconds
[13:19] <Vanfanel> fuzzie: the cursor can still leave the game are after the int cast
[13:19] <Vanfanel> game area
[13:20] <Vanfanel> the cursor can still leave the game area
[13:20] <fuzzie> it's still broken at (0,0)?
[13:20] <Vanfanel> yes, 0,0 is still the limit of the physical screen, and it should be the limit of the game area
[13:21] <fuzzie> yes, but I mean, it still gets the wrong results for that coordinate? no difference from the cast?
[13:22] <fuzzie> I'm kind of exhausted and integer multiplication is hard
[13:24] <Vanfanel> yes, there's difference with the cast, just before the clipping values now make more sense, no more absurdly high x
[13:24] <Vanfanel> http://pastebin.com/TBbjQy7s
[13:27] --> bgK joined #scummvm.
[13:27] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[13:28] <-- edheldil left irc: Remote host closed the connection
[13:29] <fuzzie> Vanfanel: so it should end up at (0,0) there, right?
[13:29] <fuzzie> the mouse coordinates are in *game* coordinates, so that is the right answer
[13:30] <Vanfanel> the mouse coordinates are correct, I think, because I can click on things with precission
[13:31] <Vanfanel> the only problem is that the cursor can go outside the game area
[13:31] <fuzzie> and still in the top-left also?
[13:32] <Vanfanel> yes, in the top left of the phisical screen
[13:32] <fuzzie> maybe there are multiple problems
[13:32] <-- bgK left irc: Ping timeout: 240 seconds
[13:33] <fuzzie> what's the _cursorX/_cursorY?
[13:33] <-- Ramal left irc: Ping timeout: 265 seconds
[13:35] --> Ramal joined #scummvm.
[13:35] <fuzzie> and does your mouse move in the *whole* game area?
[13:36] <fuzzie> OpenGLGraphicsManager::updateScreen() doesn't add _displayX to _cursorX which seems wrong for the non-overlay case, but that should just result in the cursor offset being wrong (so it starts at physical (0,0) but you can't go any further than (320,240))
[13:41] <fuzzie> oh, but then maybe your multiplication will overflow
[13:41] <fuzzie> too tired to think about this. try adding (int) casts also before the width/height, in the lines you already added casts to.
[13:41] <Vanfanel> fuzzie: http://pastebin.com/3mJ0kDNC
[13:41] <Vanfanel> _cursorX is 0
[13:41] <fuzzie> right
[13:42] <fuzzie> so I think maybe *one* problem is that you need to add _displayX/_displayY there, in the case where _overlayVisible is false?
[13:42] <fuzzie> but I'm so confused because I don't see how this works for desktop
[13:43] <fuzzie> ok, so it doesn't :-P
[13:43] <Vanfanel> it's not exactly desktop, there's no desktop at all when using GLES on the ARM boards I have here :)
[13:44] <fuzzie> so this is broken on desktop opengl :)
[13:44] <fuzzie> yay
[13:45] <Vanfanel> on linux desktop opengl-sdl is used
[13:45] <Vanfanel> and it's not broken there I think :P
[13:46] <fuzzie> it is
[13:46] <Vanfanel> well, it works fine here on my x86 laptop
[13:46] <fuzzie> well, maybe we're talking about different things
[13:46] <fuzzie> but if I run scummvm in full-screen in opengl mode, I can move the cursor outside the game area
[13:46] <Vanfanel> the cursor is confined to the game area, I mean
[13:47] <Vanfanel> can you??
[13:47] <fuzzie> the notifyMousePos in SdlEventSource::processMouseEvent happens before the transformMouseCoordinates so this is not surprising
[13:48] <fuzzie> maybe that bit is intentional
[13:48] <fuzzie> although it seems bad to me
[13:49] <salty-horse> I'm trying to access a playing AudioStream's _pos, and can't find an accessor. am I missing something?
[13:49] <fuzzie> salty-horse: yes, you're not meant to do that :)
[13:50] <fuzzie> what exactly are you looking for?
[13:50] <fuzzie> I mean, AudioStream itself has no notion of a position, for obvious reasons
[13:52] <fuzzie> the mixer has a function called getElapsedTime which will estimate how long a handle has been playing (purely by multiplying time-per-sample by samples-played and then subtracting an estimate of what's currently in the buffer)
[13:52] <salty-horse> fuzzie, I'll describe my problem, then. kom conversation have a lip-moving animation. it calculates which lip frame (1-8) to draw by the current position of the talk sample. it has a function called getAverage (for some reason) that figures how far along the sample is. I guess I could use my own timer, but I'd still need to know how long a sample is.
[13:53] <salty-horse> fuzzie, maybe I'm missing something. the samples are compressed and I can't still play them correctly without noise. maybe they have more metadata inside them
[13:54] <fuzzie> so, yes, use getElapsedTime on the mixer :)
[13:54] <salty-horse> getSoundElapsedTime just returns getElapsedTime in millis? that's a bad name
[13:55] <salty-horse> fuzzie, so I can't tell how long the sample is, right?
[13:57] <fuzzie> not unless it's a SeekableAudioStream
[14:02] <fuzzie> Vanfanel: 04ab0e58b4142bf58db2180a2bac6897821d069f changed things to do it this way, I guess not intentionally
[14:23] <Vanfanel> fuzzie: so it has nothing to do with my code, I understan
[14:23] <fuzzie> Vanfanel: doesn't look like it!
[14:24] <Vanfanel> hmm...so is someone going to fix it or should I go for it?
[14:25] <Vanfanel> I would like to announce the well-integrated Rpi version of scummvm (it's currently running on the broken fbdev SDL backend)
[14:25] <Vanfanel> and being able to go outside the game area is a major aesthetic problem, isn't it? :D
[14:31] <LordHoto> I think we can think about limiting it for fullscreen, but in windowed mode it would be crazy.
[14:33] <Vanfanel> LordHoto: for Linux/GLES machines, it's going to be fullscreen always I believe
[14:34] <Vanfanel> LordHoto: as for desktop machines, in windowed mode, window size = game area, isn't it?
[14:34] <LordHoto> nope
[14:34] <Vanfanel> oh
[14:35] <Vanfanel> wouldn't it make sense anyway?
[14:35] <LordHoto> what?
[14:35] <LordHoto> so you can't leave the window at some places anymore?
[14:35] <LordHoto> can't see how that makes sense
[14:35] <Vanfanel> I mean, what's the use of having the empty area between game screen and phisical window size in windowed mode?
[14:36] <LordHoto> correct aspect?
[14:36] <LordHoto> same thing as in fullscreen mode...
[14:37] <Vanfanel> yes, but I mean, windows can be of any size and proportion! no need to have a window with a different ratio than the one the game uses
[14:37] <LordHoto> nope, we need that
[14:37] <LordHoto> tiling window managers are usually not happy with you forcing a window size after they try to resize your window
[14:38] <Vanfanel> ok, ok, I don't know this well, so I take you are right as I don't know much about this
[14:38] <Vanfanel> sorry
[14:39] <fuzzie> LordHoto: the cursor doesn't get warped though, right? so this is just about the internal bookkeeping
[14:39] <LordHoto> that depends on how you implement it I guess
[14:39] <fuzzie> well, I was wondering just about swapping transformMouseCoordinates and notifyMousePos in SdlEventSource::processMouseEvent
[14:40] <fuzzie> but I didn't even try it, I thought I'd see if you'd be around
[14:40] <-- _marc` left irc: Quit: _marc`
[14:41] <LordHoto> I'm not sure why you would want to swap those?
[14:42] <fuzzie> because I'm slow and stupid
[14:43] <fuzzie> I mean, then you'd update x/y from the mouse.event after the transformMouseCoordinates call
[14:43] <fuzzie> which modifies its param
[14:44] <LordHoto> yeah but, what's the difference?
[14:44] <fuzzie> because then the coordinates get adjusted before the notifyMousePos
[14:44] <fuzzie> which makes the clipping work
[14:44] <fuzzie> (then you'd also have to modify the drawing code to add _displayX/_displayY to the cursor pos)
[14:44] <LordHoto> but the coordinates from mouse.event aren't used?
[14:45] <fuzzie> like I said, you'd update x/y from the mouse.event after the call :)
[14:45] <LordHoto> well, one could think of adding _displayX etc. conditionally
[14:45] <LordHoto> but it seems all pretty odd
[14:45] <fuzzie> does it?
[14:45] <fuzzie> there are various games where you get e.g. a 'turn' cursor at the side of a screen
[14:46] <fuzzie> it's pretty weird to draw the cursor in a place where it isn't..
[14:46] <fuzzie> especially since the game cursor position *is* still updated
[14:46] <LordHoto> I mean why don't we just setup fake coordinates inside notifyMousePos when it's game screen mode?
[14:46] <fuzzie> setup?
[14:46] <LordHoto> anyway, food
[14:47] <fuzzie> I mean, you could call transformMouseCoordinates from there
[14:47] <fuzzie> you wrote the code, I'm just thinking of the most obvious change :P
[14:55] <LordHoto> Isn't the most obvious change just to make sure the cursor is in the game area for drawing?
[15:11] --> clone2727 joined #scummvm.
[15:11] #scummvm: mode change '+o clone2727' by ChanServ!ChanServ@services.
[15:11] <LordHoto> clone2727!
[15:12] <clone2727> LordHoto!
[15:17] <-- demonimin_ left irc: Remote host closed the connection
[15:18] --> demonimin joined #scummvm.
[15:32] <-- kurtwr left irc: Ping timeout: 240 seconds
[15:37] <-- rootfather left irc: Quit: Page closed
[15:56] --> _marc` joined #scummvm.
[15:58] <-- clone2727 left irc: Quit: brb
[15:59] --> clone2727 joined #scummvm.
[15:59] #scummvm: mode change '+o clone2727' by ChanServ!ChanServ@services.
[16:04] --> m_kiewitz joined #scummvm.
[16:04] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[16:31] --> edheldil joined #scummvm.
[16:35] --> kurtwr joined #scummvm.
[16:40] <salty-horse> fuzzie, turns out the kom code doesn't look at WHERE the sample is, it actually looks at the values of the decompressed adpcm samples. when the sample is quiet (0), the lips are closed. when it's loud, they are open. it looks at the next sample (a few bytes), and returns the largest byte in it
[16:45] <fuzzie> heh :)
[16:47] <salty-horse> fuzzie, so no API for that, right :D
[16:48] --> salty-bot joined #scummvm.
[16:48] <salty-bot> [kom] salty-horse force-pushed conv from 10d62d6 to 07233c6: http://git.io/6ppbzA
[16:48] <salty-bot> kom/conv 1a7d6c3 Ori Avtalion: WIP conv
[16:48] <salty-bot> kom/conv f4ef109 Ori Avtalion: WIP
[16:48] <salty-bot> kom/conv d5f1862 Ori Avtalion: Fix uninitialized value when fighting during a conversation
[16:48] salty-bot (salty-bot@192.30.252.46) left #scummvm.
[16:48] <salty-horse> fuzzie, something like this: https://github.com/salty-horse/kom/blob/conv/conv.cpp#L525
[16:52] <clone2727> salty-horse: Those commit messages, ugh :P
[16:52] <salty-horse> clone2727, it's a temp branch
[16:53] <salty-horse> I'm pushing it for backup purposes
[16:53] <salty-horse> DON'T JUDGE ME
[16:55] <salty-horse> turns out I had the wrong ADPCM format - audio sounds best in ADPCMMSIma. I found magic values in the code that corresponded with CLIP(predictor, -32768, 32767), so I guessed it should be one of those
[16:55] <clone2727> eeek
[16:55] <clone2727> Don't guess!
[16:55] <salty-horse> clone2727, ok, here's t he code :P
[16:56] <salty-horse> http://pastebin.com/071uBh0V
[16:56] <salty-horse> have fun, and all that
[16:57] <clone2727> It looks like raw DVI
[16:58] <clone2727> (a1 + 24) holding the output position
[16:58] <clone2727> reading more input every other sample
[17:00] <salty-horse> it used to be kADPCMDVI, but that didn't sound as well. also, the DVI code doesn't use CLIP(predictor, -32768, 32767), which is in that function
[17:00] <salty-horse> (I suck at audio stuff, so it's mostly guesswork for me)
[17:01] <salty-horse> I'm also not sure how to do the "peek into the ADPCM bytes" - since lipsync isn't that important, the game can work without it
[17:01] <clone2727> decodeIMA handles the clip
[17:02] <clone2727> So, they all clip.
[17:03] <clone2727> The MS IMA one is *very* specific to Microsoft's crap
[17:03] <salty-horse> right. I missed that
[17:03] <clone2727> The "last" and "stepIndex" are not read in by your decoder
[17:04] <clone2727> (a1 + 36) holds the full ADPCM byte
[17:04] <clone2727> (a1 + 38) holds the current nibble
[17:04] <clone2727> It starts with the low nibble
[17:05] <clone2727> The DVI one starts with the high nibble
[17:05] <clone2727> You'll need to subclass ADPCM to handle it; pretty much what the DVI one does, but with the decodes swapped
[17:06] <clone2727> As for your lipsync handling, this is your chance to handle it, I guess. Have fun with mutexes and whatnot :P
[17:06] <salty-horse> trying the DVI stuff
[17:07] <salty-horse> not sure what you mean about mutexes. you mean hack into the mixer code?
[17:07] <clone2727> no
[17:07] <clone2727> into the AudioStream
[17:08] <clone2727> You'll already have to subclass ADPCMStream, so there's your access to the raw ADPCM bytes
[17:08] <clone2727> Since the mixer runs on another thread (on sane platforms), it's hard to avoid mutexes ;)
[17:09] <salty-horse> noted
[17:48] --> sirlemonhead joined #scummvm.
[18:14] --> bgK joined #scummvm.
[18:14] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[18:41] <-- bgK left irc: Ping timeout: 245 seconds
[18:45] --> bgK joined #scummvm.
[18:45] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[18:56] <-- bgK left irc: Ping timeout: 245 seconds
[18:58] --> bgK joined #scummvm.
[18:58] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[18:58] <-- t0by left irc: Quit: Leaving
[19:06] <-- bgK left irc: Ping timeout: 240 seconds
[19:08] --> t0by joined #scummvm.
[19:08] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[19:09] --> bgK joined #scummvm.
[19:09] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[19:18] <-- bgK left irc: Ping timeout: 240 seconds
[19:26] --> bgK joined #scummvm.
[19:26] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[19:43] --> waltervn joined #scummvm.
[19:48] --> Cheeseness joined #scummvm.
[19:57] --> WooShell joined #scummvm.
[20:00] <WooShell> meow =^.^=
[20:26] <-- clone2727 left irc: Quit: bbl
[20:39] --> RichieSams joined #scummvm.
[20:39] #scummvm: mode change '+o RichieSams' by ChanServ!ChanServ@services.
[20:42] <RichieSams> Good afternoon/evening everyone
[20:42] <Strangerke> tzag RichieSams
[20:47] Action: waltervn summons back clone2727
[20:51] <salty-horse> anyone wants to answer some basic PCM questions? :)
[20:53] <RichieSams> I can't guarantee I will be able to answer, but I'll add my brainpower to yours
[20:53] <RichieSams> ZVision used PCM
[20:54] <salty-horse> so, I have a "raw" PCM stream. I feed ScummVM's playFile a rate of "11025" -- what is that value? how many bytes per second is that?
[20:54] <salty-horse> err.. not playFile
[20:55] <salty-horse> makeRawStream
[20:55] <fuzzie> that's the sample rate. 16-bits per sample is typical, i.e. 2 bytes. but is it stereo?
[20:56] <salty-horse> mono. I only use the UNSIGNED flag
[20:56] <salty-horse> how did you get to 16bps?
[20:56] <fuzzie> because 8 bits sounds terrible
[20:56] <salty-horse> wait, it's not a fixed number of bits per second?
[20:57] <fuzzie> it depends on the source :)
[20:57] <salty-horse> please explain :)
[20:57] <fuzzie> I mean, is your source an 8-bit or a 16-bit one?
[20:57] <fuzzie> It's like mono vs stereo, the author gets to pick.
[20:58] <fuzzie> is this Blade Runner?
[20:58] <salty-horse> the game plays it as mono. is that what you're asking? it's kom
[20:58] <fuzzie> no
[20:58] <fuzzie> I mean, a "raw" PCM stream can contain either 8-bit or 16-bit samples. or 24-bit! or some random other number of bits!
[20:58] <LordHoto> 0 bits?
[20:59] <fuzzie> LordHoto: no, silly, infinite compression technology is patented.
[20:59] <salty-horse> I'm guessing it's 8-bit, since I didn't pass the 16BITS flag to ScummVM :)
[20:59] <fuzzie> salty-horse: oh right, you mean it actually plays already?
[20:59] <fuzzie> then yes, the default is 8-bit :p
[20:59] <salty-horse> fuzzie, yes. it's a lean-in question
[21:00] <fuzzie> so you're looking at 11020 bytes a second.
[21:00] <salty-horse> lead-in
[21:00] <salty-horse> ok
[21:00] <fuzzie> 11025.
[21:00] --> RUBICN64 joined #scummvm.
[21:01] <salty-horse> so it's fixed. does this mean that using things like MixerImpl::getElapsedTime() I can calculate an accurate byte position?
[21:01] <LordHoto> nope
[21:01] <salty-horse> "accurate" enough by +- a few bytes
[21:01] <fuzzie> no
[21:01] <fuzzie> sound card latency is way higher than that
[21:02] <salty-horse> accurate enough by 250+- bytes?
[21:02] <fuzzie> and the mixer processing is done in buffers
[21:02] <LordHoto> buffer's might be like 2048 or 4096 samples
[21:02] <salty-horse> samples == bytes?
[21:02] <LordHoto> and then there's sometimes also double buffering
[21:02] <fuzzie> in your case, yes, bytes.
[21:03] <Vanfanel> fuzzie: should't the "Adjust one dimension for mantaining the aspect ratio" code be wrapped in a "if (_currentState.aspectRatioCorrection)" check? If it's not, aspect ratio correcting is applied always, even if it's not activated in the options.
[21:03] <salty-horse> was it different in the DOS days? perhaps I can manage with whatever delay there is
[21:04] <fuzzie> Vanfanel: aspect ratio correction means something else
[21:04] <LordHoto> Vanfanel: nope, that aspectRatioCorrection flag is to make 320x200 games maintain a 4:3 aspect
[21:05] <LordHoto> Vanfanel: We still maintain the overall aspect for games when we scale its output resolution
[21:05] <Vanfanel> LordHoto: ok, ok, understood
[21:05] <LordHoto> Vanfanel: So, if that flag is enabled it'll always scale to 4:3, while without it it'll just use width/height as AR
[21:06] <Vanfanel> ok, ok, now I see
[21:06] <LordHoto> Vanfanel: That's also why it's called "correction" because it adjusts for the fact that screens have square pixels nowadays
[21:06] <salty-horse> ok, Q2: Is ADPCM compression rate always 16-bits to 4-bits? (I want to decompress it on my own and want to understand the code)
[21:07] <Vanfanel> LordHoto: any idea on where/how to limit the cursor area? I've tried different solutions but I don't know what would be the best place
[21:07] <LordHoto> Vanfanel: back in the days you had a 4:3 monitor and a resolution of 320x200 which would make pixels not square
[21:10] <fuzzie> salty-horse: no, but for your purposes probably yes :p
[21:10] <fuzzie> (ignoring block headers/etc which may be present)
[21:10] <fuzzie> but there's plenty of different ADPCM formats
[21:11] <LordHoto> Vanfanel: I would've set just clip based on whether the overlay is visible or not
[21:11] <salty-horse> fuzzie, ok. will try
[21:11] <LordHoto> Vanfanel: maybe even just while drawing the cursor...
[21:12] <fuzzie> it seems so inelegant not to just clip it at move event time
[21:12] <LordHoto> yeah or what
[21:12] <LordHoto> *that
[21:12] <LordHoto> but it's a bit annoying for overlay on/off if we don't store the actual position
[21:15] <Vanfanel> LordHoto: do you mean that executing the "Make sure we only supply valid coordinates" in adjustMousePosition() should depend on _overlayVisible?
[21:16] <LordHoto> Vanfanel: it should already do that?
[21:17] <Vanfanel> LordHoto: yes, that's why I don't understand what you mean
[21:17] <Vanfanel> "clip based on whether the overlay is visible or not"
[21:17] <LordHoto> I don't understand why you look into adjustMousePosition at all
[21:17] <Vanfanel> because that's where "internal" mouse coordinates are adjusted, if I'm not wrong
[21:18] <LordHoto> yeah but it's not related to drawing
[21:18] <Vanfanel> for where the mouse is actually drawn, I should look at updateScreen()
[21:18] <LordHoto> it's for the event system and related bits
[21:18] <LordHoto> the really simple and stupid idea would be to clip in setMousePosition
[21:18] <-- RUBICN64 left irc: Quit: AndroidIrc Disconnecting
[21:19] <Vanfanel> LordHoto: then maybe a non-stupid idea would be welcome :D
[21:19] <Vanfanel> I've tried many of the stupid ones already
[21:19] <LordHoto> save the input to setMousePosition and create a (possibly) clipped one for drawing
[21:20] <LordHoto> and on overlay enable/display update the clipped one based on the original one
[21:20] <LordHoto> (should be just a matter of calling setMousePosition with the saved one again after it's enabled then)
[21:20] <LordHoto> (or disabled)
[21:24] <LordHoto> it's probably also annoying when the overlay is enabled/disabled
[21:24] <Vanfanel> LordHoto: when you say setMousePosition() you mean this small fn in opengl-graphics.h ?
[21:25] <LordHoto> but oh well, that's the homework problem you have to solve
[21:25] <LordHoto> pretty much, yeah
[21:40] <-- ny00123 left irc: Quit: Leaving
[21:45] <-- Vanfanel left irc: Ping timeout: 240 seconds
[22:03] --> droid2727 joined #scummvm.
[22:03] #scummvm: mode change '+o droid2727' by ChanServ!ChanServ@services.
[22:14] sirlemonhead (bduncan22@95.44.164.183) left #scummvm.
[22:15] <-- SylvainTV left irc: Ping timeout: 245 seconds
[22:25] --> DominusExult joined #scummvm.
[22:27] <-- ced117 left irc: Ping timeout: 244 seconds
[22:27] <-- bgK left irc: Ping timeout: 240 seconds
[22:27] <-- Dominus left irc: Ping timeout: 240 seconds
[22:27] Nick change: DominusExult -> Dominus
[22:30] --> bgK joined #scummvm.
[22:30] #scummvm: mode change '+o bgK' by ChanServ!ChanServ@services.
[22:40] --> Kirben joined #scummvm.
[22:40] #scummvm: mode change '+o Kirben' by ChanServ!ChanServ@services.
[22:41] --> ced117 joined #scummvm.
[22:51] <-- waltervn left irc: Quit: Ik ga weg
[23:07] <-- bgK left irc: Ping timeout: 240 seconds
[23:16] [md5] <-- (~md5@unaffiliated/md5/x-729473) left irc: Ping timeout: 255 seconds
[23:20] [md5] --> (~md5@ppp-94-66-27-199.home.otenet.gr) joined #scummvm.
[23:20] [md5] <-- (~md5@ppp-94-66-27-199.home.otenet.gr) left irc: Changing host
[23:20] [md5] --> (~md5@unaffiliated/md5/x-729473) joined #scummvm.
[23:20] #scummvm: mode change '+o [md5]' by ChanServ!ChanServ@services.
[23:30] <-- WooShell left irc: Quit: Walking upside down in the sky, between the satellites passing by. Gliding along the black rainbow, I fly away with my shadow. Scratching the moon like a DJ, the night follows its odyssey.
[23:33] <-- salty-horse left irc: Quit: Leaving
[23:39] --> [md5]_ joined #scummvm.
[23:39] <-- [md5]_ left irc: Changing host
[23:39] --> [md5]_ joined #scummvm.
[23:39] #scummvm: mode change '+o [md5]_' by ChanServ!ChanServ@services.
[23:40] [md5] <-- (~md5@unaffiliated/md5/x-729473) left irc: Ping timeout: 255 seconds
[23:50] <-- t0by left irc: Quit: Leaving
[23:57] --> Vanfanel joined #scummvm.
[00:00] --- Sat Jan 3 2015