[Back to Index]

  
[00:27] <-- waltervn left irc: Quit: Leaving
[01:25] <Lightkey> http://www.gog.com/forum/general/2014_drmfree_winter_sale_25bbb next sale leaked early, free Age of Wonders, yay~
[01:38] sirlemonhead (bduncan22@95.44.164.183) left #scummvm.
[01:40] <-- Trixar_za left irc: Ping timeout: 244 seconds
[01:43] --> Trixar_za joined #scummvm.
[01:47] --> DOSFreak joined #scummvm.
[01:51] <-- D0SFreak left irc: Ping timeout: 255 seconds
[01:57] <-- borosky left irc: Ping timeout: 255 seconds
[01:57] --> broosky joined #scummvm.
[02:01] <-- broosky left irc: Ping timeout: 240 seconds
[02:02] --> broosky joined #scummvm.
[02:09] --> Vampire0 joined #scummvm.
[02:12] <-- Vampire0_ left irc: Ping timeout: 250 seconds
[02:21] <-- DOSFreak left irc: Quit: If I'm not back in 5 minutes....just wait longer!
[02:29] --> DominusExult joined #scummvm.
[02:32] <-- Dominus left irc: Ping timeout: 240 seconds
[02:32] Nick change: DominusExult -> Dominus
[02:45] <lewellyn> Lightkey: lemme know when they actually put the sale up. they often don't email until the free games are almost gone :P
[02:45] <Lightkey> it's 250000 copies..
[02:46] <lewellyn> and 200K of them will be grabbed by bots :P
[03:33] <-- Angmar26 left irc: Remote host closed the connection
[03:33] --> Angmar26 joined #scummvm.
[03:36] --> Jon_God joined #scummvm.
[03:38] <-- Javacat left irc: Ping timeout: 264 seconds
[03:48] <Lightkey> I feel like there was the same bundle some days ago.. anyway, the current https://www.indiegala.com/friday bundle has a few adventure games for $2.50, including Gold Rush!, The Last Door, Cognition..
[04:45] <-- clone2727 left irc: Quit: later
[05:01] --> Poly-C joined #scummvm.
[05:04] <-- Polynomial-C left irc: Ping timeout: 264 seconds
[05:35] --> GitHub1 joined #scummvm.
[05:35] <GitHub1> [scummvm] segrax opened pull request #539: SCUMM: Maniac V0: Original Walk Code Implementation (master...master) http://git.io/XpMtPw
[05:35] GitHub1 (GitHub1@192.30.252.37) left #scummvm.
[06:24] <-- Lightkey left irc: Ping timeout: 272 seconds
[06:25] --> Cheeseness joined #scummvm.
[06:36] --> Lightkey joined #scummvm.
[07:12] --> t0by joined #scummvm.
[07:12] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[07:25] <-- TAS_2012v left irc: Ping timeout: 264 seconds
[07:32] <-- LordHoto left irc: Quit: leaving
[07:48] <-- geep left irc: Ping timeout: 264 seconds
[07:57] --> TAS_2012v joined #scummvm.
[07:58] <fydo_> Lightkey: thanks, just grabbed it :)
[07:58] Nick change: fydo_ -> fydo
[08:12] --> ajax16384 joined #scummvm.
[08:12] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[08:18] <-- edheldil left irc: Remote host closed the connection
[08:24] --> edheldil joined #scummvm.
[08:28] --> edheldil_ joined #scummvm.
[08:33] --> Robin_Watts_ joined #scummvm.
[08:34] <-- Robin_Watts left irc: Ping timeout: 244 seconds
[08:34] Nick change: Robin_Watts_ -> Robin_Watts
[08:39] <-- TMM left irc: Quit: Ex-Chat
[08:59] --> _marc` joined #scummvm.
[09:15] <-- edheldil left irc: Ping timeout: 272 seconds
[09:31] --> blitter joined #scummvm.
[09:40] <-- Tomaz^W left irc:
[09:42] --> TMM joined #scummvm.
[09:51] <-- TMM left irc: Read error: Connection reset by peer
[09:51] --> TMM joined #scummvm.
[10:33] --> Vanfanel joined #scummvm.
[10:54] <-- Jon_God left irc: Remote host closed the connection
[11:18] <-- t0by left irc: Remote host closed the connection
[11:22] <-- demonimin left irc: Ping timeout: 265 seconds
[11:24] --> demonimin joined #scummvm.
[11:35] <-- edheldil_ left irc: Remote host closed the connection
[11:35] --> t0by joined #scummvm.
[11:35] #scummvm: mode change '+v t0by' by ChanServ!ChanServ@services.
[11:35] <Strangerke> hi Evil one
[11:38] --> edheldil joined #scummvm.
[11:40] <t0by> Hi Strangerke
[11:41] <t0by> how'[s everyone doing in here?
[11:42] <Strangerke> There are obvious sign of apocalypse, such as: I'm working on sound/music code
[11:42] <Strangerke> apart that, it looks OK. It's not raining frogs yet

[11:42] <t0by> Exam december the 3rd.
[11:42] <t0by> Crappin' my pants.
[11:43] <t0by> I got to that point where my brain is completely desensitized.
[11:43] <t0by> So yeah, uber busy.
[11:43] <Strangerke> I envy you
[11:43] <t0by> LOL, don't.
[11:43] <Strangerke> I'd love to have my brain desensitized
[11:45] <t0by> I've spent the past three months on this stuff. The only exam that's more painful than this is a colonoscopy.
[11:45] <Strangerke> So... in 3 days you'll be back in great shape and with brand new pants?
[11:45] <t0by> Not sure about either.
[11:45] <Strangerke> So... in 3 days you'll be back in great shape and with shitty pants? :(
[11:46] <t0by> I kind of, well, neglected physical activity
[11:46] <t0by> so no great shape either.
[11:46] <t0by> More like fat, smelly and with noticeably less hair.
[11:47] <Strangerke> https://www.youtube.com/watch?v=B4oDcsaEvEE
[11:52] <t0by> I think clone2727 mentioned something about rule #1 of #scummvm some time ago
[11:52] <t0by> but I can't remember what it was.
[11:52] <t0by> Meh.
[11:53] <Strangerke> Flame anybody who mentions a potentially non-2D adventure p&c game?
[11:53] <t0by> Oh, right
[11:53] <t0by> [00:55:53] <clone2727> Rule #1 of #scummvm: Don't blindly click on a Strangerke link
[11:54] <Strangerke> Ha yes, that one too :)
[11:54] <Strangerke> Clicking blindly is complicated because usually you don't click on the link
[11:55] <Strangerke> (and this link is safe, it's just a video about a night butterfly)
[12:19] <-- ajax16384 left irc: Ping timeout: 252 seconds
[12:26] --> ajax16384 joined #scummvm.
[12:26] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[12:34] --> NotJavacat joined #scummvm.
[12:34] Nick change: NotJavacat -> Javacat
[12:50] --> h00ligan joined #scummvm.
[12:50] #scummvm: mode change '+o h00ligan' by ChanServ!ChanServ@services.
[12:53] --> ThirdChoice joined #scummvm.
[12:53] <-- ajax16384 left irc: Ping timeout: 265 seconds
[12:55] <-- h00ligan left irc: Ping timeout: 265 seconds
[13:00] <-- rigid left irc: Quit: NO WINE, NO WIFE, NO CARRIER
[13:01] --> rigid joined #scummvm.
[13:12] --> uruk-hai joined #scummvm.
[13:12] #scummvm: mode change '+o uruk-hai' by ChanServ!ChanServ@services.
[13:45] --> GitHub32 joined #scummvm.
[13:45] <GitHub32> [scummvm] urukgit pushed 1 new commit to master: http://git.io/x6GU3A
[13:45] <GitHub32> scummvm/master 0aba59b uruk: CGE2: Add support for Sfinx.
[13:45] GitHub32 (GitHub32@192.30.252.41) left #scummvm.
[13:46] <Strangerke> uruk-hai: congratz :)
[13:47] <uruk-hai> thank you :) it was a fine work, you deserve credit too as well as dreammaster, criezy and digitall :)
[13:47] <Strangerke> :)
[13:57] --> Quatroking joined #scummvm.
[14:10] Action: wjp wonders if we can add git hooks to catch those AUTHORS updates
[14:11] <wjp> probably a bit of a headache to get the logic correct, though
[14:12] --> Raziel^ joined #scummvm.
[14:12] #scummvm: mode change '+v Raziel^' by ChanServ!ChanServ@services.
[14:21] <-- Raziel^ left irc: Quit: AmigaOS 4 (Unregistered copy). Evaluation period is over. Program will now quit. Thank you for using AmigaOS.
[14:28] <-- _marc` left irc: Quit: _marc`
[14:30] <Vanfanel> wjp: I ran scummvm with oprofile on the ARM board with no problems :) And there's no need for profiling options and modules to be enabled on the kernel config either: that's for kernel profiling, not for programs and lib calls profiling
[14:31] <Vanfanel> wjp: running scummvm directly into DreamWeb, and letting it run the SLOW fade-to-black effect in the game's first text gives these results: http://pastebin.com/gA9K8MxE
[14:33] <Vanfanel> I believe the updateTexture() call is the culprit for the 100% CPU usage in that scene. During the game itself, CPU usage is ~50%
[14:33] <Vanfanel> but I could be wrong, I've never done these profilings
[14:42] --> grrk-bzzt_ joined #scummvm.
[14:42] grrk-bzzt_ (grrk-bzzt@universe.emi.u-bordeaux1.fr) left #scummvm ("Leaving").
[14:56] --> GitHub101 joined #scummvm.
[14:56] <GitHub101> [scummvm-web] urukgit pushed 1 new commit to master: http://git.io/6MH3VQ
[14:56] <GitHub101> scummvm-web/master 68e1594 uruk: WEB: Update credits.
[14:56] GitHub101 (GitHub101@192.30.252.39) left #scummvm.
[15:05] <wjp> uruk-hai: um?
[15:06] <uruk-hai> wjp, ? :D
[15:06] <uruk-hai> oh sorry i forgot to push to scummvm-scummvm
[15:07] --> GitHub93 joined #scummvm.
[15:07] <GitHub93> [scummvm] urukgit pushed 1 new commit to master: http://git.io/J39pig
[15:07] <GitHub93> scummvm/master b1f7603 uruk: CGE2: Update credits the right way.
[15:07] GitHub93 (GitHub93@192.30.252.37) left #scummvm.
[15:07] <wjp> thanks
[15:08] <wjp> Vanfanel: _mali_convert_tex32_l_to_tex32_b kind of suggests a suboptimal texture format too
[15:10] <-- Cheeseness left irc: Quit: Leaving.
[15:13] Nick change: Javacat -> NotJavacat
[15:16] <Vanfanel> wjp: yes. Is it possible to change the texture format the GLES2 backend uses? Can you point me to that in the code? Had a look at texture.cpp but didn't see it.
[15:17] <wjp> what is "the GLES2 backend"? I'm not very familiar with our opengl code
[15:18] <-- NotJavacat left irc: Ping timeout: 264 seconds
[15:18] <Vanfanel> But appart from that, I think GLES/GLES2 backend would be MUCH faster if it used a buffer like the Android backend does. I have a SDL 1.2 backend that in turn uses GLES2: rect modifications are done to a memory buffer and then that's uploaded to GLES2, and Scummvm runs perfectly well with that.
[15:19] <Vanfanel> wjp: well, the GLES2 "backend" is an SDL subclass that renders frames as GLES/GLES2 textures
[15:19] <wjp> if it's sdl, then OpenGLSdlGraphicsManager::setupMode() is probably the function to look at
[15:19] <Vanfanel> I say GLES2 but on the official repository only GLES1 code is available. The GLES2 code was an experiment by LordHoto I integrated to try and see if it was any faster.
[15:20] <wjp> but as I said, I'm not particularly familiar with all this code
[15:20] <Vanfanel> Who is? LordHoto?
[15:20] <Vanfanel> You both are mentioned as contribs on the opengl classes
[15:21] <wjp> mentioned where?
[15:21] <somaen> I have some code lying around to make atleast the iOS backend use GLES2, at some point I'll have to clean it up.
[15:22] <somaen> (And add transparent support for GLES1, to make older iPhone-users happy)
[15:22] <wjp> but a large part of the current OpenGL backend is written by LordHoto, yes
[15:22] <Vanfanel> wjp here: https://github.com/scummvm/scummvm/blob/master/backends/graphics/opengl/texture.cpp#blob_contributors_box
[15:23] <Vanfanel> somaen: maybe you can use LordHoto's GLES2: https://github.com/lordhoto/scummvm/commits/opengl-gles2
[15:24] --> _marc` joined #scummvm.
[15:27] <somaen> Vanfanel: The stuff I did was mostly iOS-specific stuff that I wrote for ResidualVM
[15:28] <somaen> But the main outcome of it, that is translateable back to ScummVM, was moving the rendering onto the game thread
[15:28] <somaen> Thus remvoing the need for special-handling of all GL-calls
[15:28] <somaen> removing even
[15:28] <somaen> Which means that a more common code base with Android might be feasible.
[15:28] <wjp> Vanfanel: ah, interesting github feature
[15:29] <wjp> Vanfanel: it seems to list me solely due to this: https://github.com/scummvm/scummvm/commit/fb05395dedfb3098c6b421352da2be3b6fa58db9 :-)
[15:30] <Vanfanel> wjp: oh, ok, hadn't looked at why you were listed
[15:30] <Vanfanel> I'll have to ask LordHoto then
[15:30] <Vanfanel> But I suspect using the memory buffer to update rects is the solution, just like on Android backend
[15:31] <wjp> in this fading scene that'll probably be useless though
[15:31] <Vanfanel> wjp: it's the same in most fading scenes, not just in this game...
[15:31] <wjp> since a palette change will trigger a full redraw
[15:32] <Vanfanel> well, it comes down to those two things: rect updates and texture format conversions.
[15:33] <wjp> if you say so
[15:33] <Vanfanel> what other things could be involved?
[15:33] <wjp> I don't know
[15:33] <Vanfanel> sorry if it was a stupid asumption :)
[15:34] <Vanfanel> but I have the same scummvm running on the same machine, using SDL1.2.x with a solution based on an intermediate buffer and it works right
[15:34] <Vanfanel> while using the GLES2 directly from scummv does not
[15:35] <Vanfanel> both solutions use GLES2
[15:35] <Vanfanel> one uses an intermediate buffer where rects are updated, and the other doesn't
[15:35] <Vanfanel> it's clear to me, but again I could be wrong
[15:35] <wjp> which one doesn't?
[15:35] <Vanfanel> the scummvm directly using GLES/GLES2 does not
[15:36] <wjp> really?
[15:36] <wjp> I find that hard to believe
[15:36] <Vanfanel> https://github.com/scummvm/scummvm/blob/master/backends/graphics/opengl/texture.cpp#L205
[15:37] <wjp> dirtyArea?
[15:37] <Vanfanel> and look comment from https://github.com/scummvm/scummvm/blob/master/backends/graphics/opengl/texture.cpp#L252 onward
[15:38] <wjp> yes, so it's only in the vertical direction
[15:38] <Vanfanel> it updates the texture directly
[15:38] <Vanfanel> while using my SDL1.2 backend that in turn uses GLES2, I let Scummvm update a memory buffer instead
[15:39] <wjp> what updates the texture directly? You've lost me
[15:39] <Vanfanel> GLCALL(glTexSubImage2D(GL_TEXTURE_2D, 0, 0, dirtyArea.top, _textureData.w, dirtyArea.height(),
[15:39] <wjp> our internal screen is not even the same pixel format as the texture...
[15:39] <Vanfanel> _glFormat, _glType, _textureData.getBasePtr(0, dirtyArea.top)));
[15:41] <Vanfanel> The way I understand it, every small change is updated directly to a texture, so glTexSubImage2D() can be called a lot of times per frame
[15:41] <Vanfanel> while in the other solution (Android), it's only called to update the whole screen, one time per frame
[15:42] <wjp> we don't have frames
[15:42] <Vanfanel> well, games must run at a certain pace anyway. Complete updates, I don't know what you call it.
[15:43] <wjp> the name doesn't matter; we just don't have them :-)
[15:43] <Vanfanel> Well, ok, then I don't know what to say :(
[15:44] <Vanfanel> Updating a texture directly seems to be MUCH slower than updating rects on a ram buffer
[15:44] <Vanfanel> but how/when the ram buffer is dumped to a GLES2 texture, I don't know
[15:44] <wjp> I still don't understand what you mean by "directly"
[15:44] <wjp> it goes through at least two memory buffers before getting to a texture
[15:44] --> geep joined #scummvm.
[15:45] <Vanfanel> glTexSubImage2D() makes a partial update of a texture already in video memory
[15:45] <Vanfanel> so the SLOW glTextSubImage2D() function it's called with every small change
[15:46] <wjp> ah, so you want to batch them?
[15:47] <Vanfanel> for some reason (it seems I don't understand how scummvm works internally), that's slower than a solution I have, on which the rect changes are made to a ram buffer, and then, sometime, that buffer is dumped to video RAM with a SINGLE glTexSubImage2D() call
[15:48] <wjp> the ram buffer is completely irrelevant. We already have that.
[15:48] <wjp> You just mean the gl calls
[15:48] <wjp> (TextureCLUT8::updateTexture updates the ram buffer, Texture::updateTexture updates the texture)
[15:49] <wjp> (well, at least for paletted games, that is)
[15:50] <wjp> anyway, I'm really not the person to have in-depth discussions about this with
[15:51] <Vanfanel> don't worry, wjp, I will talk with LordHoto about this when we coincide here
[15:55] <Vanfanel> btw, in OpenGLFBDEVGraphicsManager::setupMode (which subclasses both SDL and opengl, not opengl_sdl), all I can see is pixel format, but not texture format
[15:58] Action: DrMcCoy summons clone2727
[15:59] <Vanfanel> oh, texture format seems to be configured in backend/graphics/opengl/texture.cpp
[16:10] --> dtcrshr joined #scummvm.
[16:14] --> L0ngcat joined #scummvm.
[16:19] <Vanfanel> wjp: look, commenting out the glTexSubImage2D() call in opengl-graphics.cpp and running Dreamweb intro makes the CPU usage down to 15% :D It's 100% with the call uncommented.
[16:22] --> Javacat joined #scummvm.
[16:22] --> droid2727 joined #scummvm.
[16:22] #scummvm: mode change '+o droid2727' by ChanServ!ChanServ@services.
[16:34] <-- TMM left irc: Quit: Ex-Chat
[16:40] <-- geep left irc: Ping timeout: 258 seconds
[16:44] --> frankyboy_ joined #scummvm.
[16:56] --> ny00123 joined #scummvm.
[17:12] <L0ngcat> madmoose: anything new with BR?
[17:27] <-- Vanfanel left irc: Quit: Lost terminal
[17:34] --> Vanfanel joined #scummvm.
[17:34] <-- ThirdChoice left irc: Ping timeout: 258 seconds
[17:47] --> ajax16384 joined #scummvm.
[17:47] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[17:52] <-- ajax16384 left irc: Ping timeout: 264 seconds
[17:53] --> sirlemonhead joined #scummvm.
[17:53] --> WooShell joined #scummvm.
[17:53] --> ajax16384 joined #scummvm.
[17:53] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[17:54] <WooShell> meow =^.^=
[18:09] <-- Vanfanel left irc: Quit: Lost terminal
[18:13] --> m_kiewitz joined #scummvm.
[18:13] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[18:13] <-- ST left irc: Ping timeout: 272 seconds
[18:20] --> ST joined #scummvm.
[18:20] #scummvm: mode change '+o ST' by ChanServ!ChanServ@services.
[18:23] <-- dtcrshr left irc: Quit: Saindo
[18:33] --> dtcrshr joined #scummvm.
[18:33] <-- dtcrshr left irc: Changing host
[18:33] --> dtcrshr joined #scummvm.
[19:08] <-- ajax16384 left irc: Ping timeout: 265 seconds
[19:19] <madmoose> L0ngcat: Nothing big.
[19:21] --> cuymfs joined #scummvm.
[19:36] --> ajax16384 joined #scummvm.
[19:36] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[19:37] --> D0SFreak joined #scummvm.
[19:38] <-- cuymfs left irc:
[19:45] <-- ajax16384 left irc: Ping timeout: 244 seconds
[19:45] --> criezy joined #scummvm.
[19:45] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[19:46] --> ajax16384 joined #scummvm.
[19:46] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[19:51] <-- frankyboy_ left irc: Quit: #E>6C O >B 20A
[19:52] <-- uruk-hai left irc: Ping timeout: 258 seconds
[20:09] <-- Javacat left irc: Ping timeout: 264 seconds
[20:14] --> Javacat joined #scummvm.
[20:15] <-- D0SFreak left irc: Remote host closed the connection
[20:32] --> waltervn joined #scummvm.
[20:53] <-- Quatroking left irc: Read error: Connection reset by peer
[20:53] <-- chkr left irc: Ping timeout: 272 seconds
[20:55] --> chkr joined #scummvm.
[21:02] --> Cheeseness joined #scummvm.
[21:12] <-- Ramal left irc: Ping timeout: 240 seconds
[21:14] --> Ramal joined #scummvm.
[21:19] --> h00ligan joined #scummvm.
[21:19] #scummvm: mode change '+o h00ligan' by ChanServ!ChanServ@services.
[21:19] --> mkiewitz joined #scummvm.
[21:20] --> kurtwr2 joined #scummvm.
[21:21] <-- Jedi_ left irc: Read error: Connection reset by peer
[21:22] --> Jedi_ joined #scummvm.
[21:23] --> GitHub54 joined #scummvm.
[21:23] <GitHub54> [scummvm] skristiansson opened pull request #540: SDL: add support for SDL2 (master...pr/sdl2) http://git.io/2ayvOg
[21:23] GitHub54 (GitHub54@192.30.252.41) left #scummvm.
[21:25] <fuzzie> +#ifndef USE_SDL20
[21:25] --> Gentle` joined #scummvm.
[21:25] <fuzzie> + (Uint16)ev.key.keysym.unicode);
[21:25] --> demonimin_ joined #scummvm.
[21:25] <-- demonimin_ left irc: Changing host
[21:25] --> demonimin_ joined #scummvm.
[21:25] <fuzzie> +#else
[21:25] <fuzzie> + 0);
[21:25] <fuzzie> +#endif
[21:25] <fuzzie> in case anyone else was wondering :-p
[21:26] <wjp> I was just looking at that bit, yes
[21:26] <Sir_Burpalot> Oh, there's going to be support for SDL2?
[21:26] <fuzzie> yes, as soon as someone solves the input problems
[21:26] <fuzzie> which this pull request does not :)
[21:26] <Sir_Burpalot> Well, that's a start.
[21:27] <fuzzie> yes, this is just the easy bit
[21:27] <Sir_Burpalot> At least now there's hope that ScummVM will work properly on Retina. Someday.
[21:27] <fuzzie> it works great on retina!
[21:27] <fuzzie> step one, don't use an OS which randomly breaks APIs :)
[21:27] <stekern> yeah, that bit of the SDL2 incompatibility changes sucks...
[21:27] --> [vEX]- joined #scummvm.
[21:28] <Sir_Burpalot> Sadly, no other desktop or laptop OS comes close to OS X as far as HiDPI support is concerned.
[21:29] <Sir_Burpalot> Although Android's not bad.
[21:30] <Sir_Burpalot> Well, ChromeOS probably has great HiDPI support, too, if you can call that an OS.
[21:30] <fuzzie> but you can *try* to do the event mapping for SDL2 right, you have a bunch of info available and you can do mapping yourself to a large extent
[21:31] <Sir_Burpalot> What is the problem with SDL2 and input?
[21:31] <stekern> yeah, but 'text input' has been completely decoupled from the keycodes
[21:32] <fuzzie> Sir_Burpalot: they made it a lot more difficult to work out what keycodes represent
[21:34] <fuzzie> which, like most of SDL2, makes perfect sense if you're writing a brand new game, and is irritating as hell with legacy things like ScummVM
[21:35] ajax16384 (~User@ip252.net177.n37.ru) got netsplit.
[21:35] m_kiewitz (~m_kiewitz@kons-4d03e2f4.pool.mediaWays.net) got netsplit.
[21:35] demonimin (~demonimin@unaffiliated/demonimin) got netsplit.
[21:35] kurtwr (~kurtwr@c-98-208-17-184.hsd1.ca.comcast.net) got netsplit.
[21:35] [vEX] (~vex@h-85-24-195-9.na.cust.bahnhof.se) got netsplit.
[21:35] Gentle (~tier@quassel/contributors/gentle) got netsplit.
[21:35] <Sir_Burpalot> I hope SDL2 doesn't use DirectInput on Windows, at least.
[21:35] <somaen> Does SDL1?
[21:35] <Sir_Burpalot> Yes.
[21:35] <somaen> What's the problem?
[21:35] <stekern> my intent with the work is mostly to (initially) provide a base for platforms which lacks SDL1 support
[21:36] <somaen> stekern: Like?
[21:36] <stekern> I'm working on a windows phone 8.1 port, and I think jolla phones only have SDL2 as well
[21:36] <fuzzie> so the obvious question is, why use SDL?
[21:36] <somaen> We already have an iOS-port, it doesn't use SDL at all.
[21:37] <somaen> You're likely to want to have a bit of native-ness when doing mobile ports anyhow.
[21:37] <Sir_Burpalot> somaen: the problem with DirectInput is that it forcibly changes the active keyboard layout to the US English one.
[21:37] <fuzzie> not that I think it's a bad idea to have SDL2 support in-tree, with big DO NOT USE warnings
[21:37] <fuzzie> and layering mobile platforms on top of that isn't necessarily a bad idea
[21:37] <somaen> Sir_Burpalot: Ahhh, just as silly as the "keyboard layout per application, NOT globally-change key alt-shift"
[21:38] <Sir_Burpalot> And a rare bug in Windows 8.x (and 10) that occurs when you have the US English layout associated with a display language other than US English.
[21:38] <fuzzie> but I'm wondering what your long-term goals are, again
[21:38] <somaen> fuzzie: I was actually considering going the other way around, and backporting as much as possible from the iOS-port into an OS X port.
[21:38] <stekern> somaen: I considered doing a native port, but adding support for SDL2 seemed like the way with least resistance ;)
[21:38] <somaen> Which probably isn't too much, but hey.
[21:38] <fuzzie> well, I am not impressed with SDL2 at all
[21:38] <Sir_Burpalot> Well, it's rare in the sense that it's probably not a bug that most people run into that often.
[21:38] <fuzzie> especially the render stuff is a mess
[21:39] <somaen> stekern: Can you easily get the unicode character that maps to the keypress event you get in whatever API WinMo exposes for events?
[21:39] <somaen> If yes, then there is less pain in skipping SDL2
[21:39] <fuzzie> but it is a nice base to work from
[21:39] <stekern> ...I'm using the virtual keyboard for input
[21:40] <somaen> ... and?
[21:40] <somaen> Oh, OUR vkeyboard?
[21:40] <stekern> yes
[21:40] <fuzzie> eek :p
[21:40] <somaen> Doesn't WinMo have a usefull one?
[21:40] <fuzzie> although maybe that'll be motivation for someone to fix ours ;)
[21:40] <somaen> Because, IMHO, nativeness is good where it fits in.
[21:41] <somaen> Except for the browse-dialogue we support on OS X, but that's just because it's slow.
[21:41] <stekern> yeah, it does, and switching to that might be a good idea in the future. But I still wanted to use SDL2 for rendering graphics
[21:41] <-- ny00123 left irc: Quit: Leaving
[21:41] <somaen> Why not just GLES?
[21:42] <somaen> (And yes, yes, I know GLES has quite a few painfull details too)
[21:43] <-- mkiewitz left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.
[21:44] --> Vanfanel joined #scummvm.
[21:45] <stekern> path of least resistance again, but the fact that I discovered ANGLE after the wp SDL2 port played a role as well.
[21:46] Gentle (~tier@quassel/contributors/gentle) got lost in the net-split.
[21:46] [vEX] (~vex@h-85-24-195-9.na.cust.bahnhof.se) got lost in the net-split.
[21:46] kurtwr (~kurtwr@c-98-208-17-184.hsd1.ca.comcast.net) got lost in the net-split.
[21:46] demonimin (~demonimin@unaffiliated/demonimin) got lost in the net-split.
[21:46] m_kiewitz (~m_kiewitz@kons-4d03e2f4.pool.mediaWays.net) got lost in the net-split.
[21:46] ajax16384 (~User@ip252.net177.n37.ru) got lost in the net-split.
[21:46] <-- Cheeseness left irc: Quit: Leaving.
[21:47] <somaen> Oh well, if you can reliably fix the unicode field, and make SDL2 entirely opt-in, that's a step in the right direction atleast.
[21:47] <fuzzie> if you bodge the input thing then you get a prize
[21:47] <fuzzie> cake, maybe
[21:48] <stekern> ;)
[21:50] <Vanfanel> ehmmm wait wait. Is there an SDL2 port????
[21:50] <wjp> No
[21:50] <wjp> :-)
[21:50] <Vanfanel> wp SDL2 port, stekern said :D
[21:50] <somaen> wip
[21:51] <somaen> but also wp
[21:51] <somaen> I guess.
[21:51] <stekern> wp = windows phone
[21:51] <somaen> yeah, thus the "also"
[21:51] <wjp> it's a rather interesting situation
[21:52] <Vanfanel> SDL2 would render my GLES2-on-arm efforts useless
[21:52] <somaen> GLES2 on arm?
[21:52] <somaen> How would that be useless?
[21:52] <Vanfanel> I mean...
[21:52] <somaen> And, don't we already have GLES-support?
[21:53] <Vanfanel> somaen: yes, but not proper context initialization for EGL on different ARM Linux boards
[21:53] <Vanfanel> somaen: I have that working for some boards
[21:53] <Vanfanel> but GLES2 is SLOW as a dog
[21:54] <somaen> Well, that depends on how the updates are performed.
[21:54] <Vanfanel> and the texture updating function is taking ~80% of the CPU
[21:54] <somaen> glSubTexImage
[21:54] <Vanfanel> yes
[21:54] --> geep joined #scummvm.
[21:54] <Vanfanel> that's how they are performed but in a way I don't understand
[21:54] <somaen> The iOS-backend skips using that, with a comment about iOS being slower on subteximage than full updates.
[21:54] <Vanfanel> EXTACT, somaen
[21:54] <Vanfanel> full updates should be done
[21:55] <Vanfanel> instead of many glSubTexImage calls
[21:55] <somaen> is texsubimage slower on your stuff too?
[21:55] Action: wjp sighs
[21:55] <Vanfanel> WAY slower
[21:55] <somaen> Oh well, create new textures for a while, draw those on top.
[21:55] <somaen> then refresh every nth cycle
[21:55] <somaen> or something
[21:55] <wjp> either that _or_ texture pixel format conversion
[21:55] <Vanfanel> wjp: no
[21:55] <Vanfanel> I disabled the call
[21:56] <Vanfanel> and got my 80% CPU back
[21:56] <wjp> and the screen was black?
[21:56] <Vanfanel> It is glSubTexImage
[21:56] <Vanfanel> of course it was black :D
[21:56] <Vanfanel> how could it be otherwise if I disabled the texture updating function?
[21:56] <droid2727> if no code is run, it tends to be faster
[21:56] <Vanfanel> no, the games run
[21:56] <Vanfanel> they render internally
[21:57] <Vanfanel> It's just glSunTexImage that was disabled
[21:57] <wjp> if you have a better explanation for _mali_convert_tex32_l_to_tex32_b than texture format conversion, I'd like to hear it :-)
[21:57] <Vanfanel> wjp: of course that's a problem also
[21:58] <Vanfanel> but the CPU is taken by the glSubTexImage calls
[21:58] <fuzzie> I'm confused
[21:58] <Vanfanel> maybe _mali_convert--whaveter is called inside glSubTexImage
[21:58] <fuzzie> what would be calling _mali_convert_tex32_l_to_tex32_b other than glSubTexImage?
[21:58] <Vanfanel> yeah :D
[21:59] <Vanfanel> I have to verify that
[22:03] <somaen> Or, you know, just try to change the texture format passed in
[22:03] <somaen> To whatever the GPU actually likes to eat for dinner.
[22:08] --> D0SFreak joined #scummvm.
[22:08] <Vanfanel> it doesn't seem easy or evident. I have the getSupportedFormats() function in my EGL initialization classes (glesfbdev.cpp, for the Cubie2), but all I see there are pixel formats, not texture formats. I know it's basically the same, but I tried disabling all and enabling one by one, and there's no visible change.
[22:08] <Vanfanel> somaen: does this oprofile trace -> OpenGL::TextureCLUT8::updateTexture() suggest it's using the CLUT8 fallback which I gather it's slow?
[22:11] <somaen> Read the documentation for your board?
[22:11] <somaen> I have no idea what texture format it wants internally
[22:11] <-- geep left irc: Ping timeout: 255 seconds
[22:14] <Vanfanel> somaen: there's no documentation for my board, we have closed binaries from another board as GLES implementation
[22:14] <Vanfanel> I know RetroArch uses RGB565 and works great, if that's of some help. But I tried leaving ONLY RGB565 enabled, and it's still slow.
[22:15] <somaen> What do you mean enabled?
[22:15] <Vanfanel> I mean uncommented
[22:15] <Vanfanel> to disable a format, I comment it out
[22:16] <somaen> Where?
[22:16] <somaen> tex32_l_to_tex32_b sounds like a conversion between two 32bpp formats
[22:16] <somaen> 565 is not a 32bpp format
[22:17] <Vanfanel> I know, I had the hope that using a 16 bit format would improve things and would not trigger conversion
[22:17] <Vanfanel> I disable/enable pixel formats in OpenGLFBDEVGraphicsManager::getSupportedFormats()
[22:18] <Vanfanel> OpenGLFBDEVGraphicsManager is my EGL init class, subclassing from sdl and opengl
[22:18] <fuzzie> do you still get it if you only allow rgb565?
[22:18] <Vanfanel> fuzzie: yes
[22:18] <somaen> Presumably you would get a different mali_conv call?
[22:19] <Vanfanel> I was about to test that :)
[22:19] <fuzzie> yes if you get the same call then you're doing it wrong
[22:19] <Vanfanel> yes, if I get the same call then I'm disabling internal pixel formats and not texture formats
[22:20] <-- waltervn left irc: Ping timeout: 252 seconds
[22:31] --> DOSFreak joined #scummvm.
[22:32] <Vanfanel> fuzzie: I get _mali_convert_tex32_l_to_tex32_b still, with only RGB565 enabled in getSupportedFormats()
[22:33] <Vanfanel> where am I supposed to change the texture format then?? I thought it was in texture.cpp but I don't see it
[22:34] <Vanfanel> oh, and _mali_convert_tex32_l_to_tex32_b is called by glSubTexImage, confirmed also
[22:35] <-- h00ligan left irc: Ping timeout: 252 seconds
[22:35] <-- D0SFreak left irc: Ping timeout: 252 seconds
[22:41] <-- droid2727 left irc: Ping timeout: 258 seconds
[22:49] <-- criezy left irc: Quit: criezy
[22:56] <somaen> What parameters are passed to the various texture-generation functions?
[22:59] <Vanfanel> somaen: seems createTexture uses getGLPixelFormat(), both in opengl-graphics.cpp
[23:00] <Vanfanel> so the key is in getGLPixelFormat(), which seems to determine the GLES texture format enums
[23:04] <-- mrsiggler left irc:
[23:07] --> droid2727 joined #scummvm.
[23:07] #scummvm: mode change '+o droid2727' by ChanServ!ChanServ@services.
[23:11] <-- 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:27] --> RUBICN64 joined #scummvm.
[23:37] --> geep joined #scummvm.
[23:41] <-- t0by left irc: Read error: Connection reset by peer
[23:45] <-- RUBICN64 left irc: Quit: AndroidIrc Disconnecting
[23:59] <Lightkey> http://www.bundlestars.com/all-bundles/humongous-bundle/ self-explanatory
[00:00] --- Tue Dec 2 2014