[Back to Index]
[00:31] <-- SylvainTV left irc: Read error: Connection reset by peer
[01:21] <Grogbot> <rsn8887> Is somebody testing these commits on their actual Switch hardware?
[01:21] <Grogbot> <rsn8887> https://github.com/scummvm/scummvm/commit/ba2bc60043c8a1bbc651ca237783ef5e6883bda0
[01:21] <Grogbot> <rsn8887> @ccawley2011 ^
[01:22] <Grogbot> <rsn8887> Or at least on the Switch emulator?
[01:23] <Grogbot> <rsn8887> Or are these just done blindly?
[01:25] <Grogbot> <ccawley2011> @rsn8887 I haven't tested that on Switch, I'm afraid. There shouldn't be any change in behaviour, though.
[01:25] <-- borosky left irc: Read error: Connection reset by peer
[01:25] --> borosky joined #scummvm.
[01:27] <Grogbot> <rsn8887> Well the original porter (cpasjuste) went through the trouble originally to put an ifdef and use POSIX manager on Switch so my first reaction would be there was probably a reason for that. Anyways I will test it once it hits the buildbot.
[01:27] <Grogbot> <rsn8887> Is there a reason you are touching so many tried and tested backends, apparently without testing on hardware sometimes?
[01:31] <Grogbot> <rsn8887> I am not trying to discourage your work but some of these platforms can be a bit buggy or peculiar.
[01:31] <Grogbot> <rsn8887> So it is usually a good idea to test.
[01:32] <Grogbot> <rsn8887> In my opinion.
[01:34] <Grogbot> <ccawley2011> Using the POSIX save file manager made sense when it implemented checkPath(). When PR #1727 was merged though, the implementation was no longer needed since one was provided in the default save file manager. With that removed, none of the important code in the POSIX save file manager was actually being used on the Switch.
[01:35] <Grogbot> <rsn8887> I see so you are making changes only where you know the actual code being executed is identical or equivalent to what was happening before, aka refactoring
[01:35] <Grogbot> <ccawley2011> I understand your concern, though, and I'm sorry for not requesting your opinion on the relevant PR before it was merged.
[01:36] <Grogbot> <rsn8887> More refactoring than anything else that makes sense
[01:37] <Grogbot> <rsn8887> There are just some... pitfalls. An example: On Switch, pthread_detach exists but is not correctly implemented. Someone who doesnt know the system will use it and it compiles but when it is called will cause crashes at runtime etc.
[01:37] --> DominusExult joined #scummvm.
[01:37] <-- DominusExult left irc: Changing host
[01:37] --> DominusExult joined #scummvm.
[01:38] <Grogbot> <rsn8887> This is just one example, since these platforms (psp, Switch, Vita) are well kind of construction zones when it comes to the amount of stuff that is implemented and functioning correctly. Id say Switch is miles ahead of psp and Vita, but still it has these missing functionalities.
[01:39] <Grogbot> <rsn8887> But of course if you are really doing refactoring than it will all be ok.
[01:39] <Grogbot> <rsn8887> Btw thats fine not asking I would not have had time to test it anyways.
[01:40] <Grogbot> <rsn8887> But pinging me so I have kind of a record when something happens to Vita Switch PSP would be cool. It will make it easier to debug if something actually explodes 😃
[01:41] <Grogbot> <ccawley2011> No problem 😃
[01:41] --> dreammaster joined #scummvm.
[01:41] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[01:41] <-- Dominus left irc: Ping timeout: 245 seconds
[01:41] Nick change: DominusExult -> Dominus
[01:42] <Grogbot> <rsn8887> Honestly I am glad at all the stuff thats happening thanks to you and bluegr because idk but ScummVM seemed to move at a bit of a snails pace for a long time with PRs just stalling for months and years sometime. 😃
[01:42] <Grogbot> <rsn8887> Now it seems to move and progress almost exponentially faster thanks to the active devs 😃
[01:42] <Grogbot> <ccawley2011> As an aside, once PR #1790 is merged, the PSP save file manager won't be needed either for the same reasons mentioned with the Switch version.
[01:44] <Grogbot> <rsn8887> Ok i guess I will trust you on it but if you want you can always ping me on the relevant PR and I can at least to a quick test in a day or two. For example with that background shaking PR it was helpful that I was able to test it on Vita so now I have a fix ready when it should hit.
[01:45] <Grogbot> <rsn8887> I can test on psp vita and switch hardware
[01:46] <Grogbot> <ccawley2011> Since you mentioned that, I'd prefer it if the Vita backend was changed to utilise the active DisplayRect instead of handling the screen shaking in SDL_UpdateRects.
[01:47] <Grogbot> <rsn8887> I dont think it will work with the touch interface
[01:47] <Grogbot> <rsn8887> When active displayrect is used unless I am misunderstanding something
[01:49] <Grogbot> <rsn8887> Also the 4:3 stretching is done completely differently on vita, in hardware
[01:53] <Grogbot> <rsn8887> I might be missing something but we are drawing to a native texture directly on Vita, differently than the other sdl graphicsmanagers
[01:54] <Grogbot> <rsn8887> Because of shaders etc the scaling has to be done in hardware otherwise the shaders wont work
[01:55] <Grogbot> <rsn8887> I mean if you have a solution I am all ears but that should definitely be tested to ensure that direct touch still works in the different game resolutions so that the mouse pointer is not offset from finger pos, that shaders still scale correctly etc
[02:01] <Grogbot> <rsn8887> I mean is the displayrect stretched when 4:3 correction is active? Is it measured in screen pixels?
[02:01] <Grogbot> <rsn8887> Or game pixels?
[02:03] <Grogbot> <rsn8887> If it is in screen pixels it might work to just use the displayrect to cAlculate offset and scale factors in updaterects, but the leftover garbage still has to be removed manually because of the vita2d_draw_tecture call
[02:06] <Grogbot> <rsn8887> Right now it is looking at whether fullscreen is active, whether 2x scaling is active etc. and the draws the texture centered horizontally and vertically. And the code is duplicated in the touch controls to ensure the direct touch works. If this could be simplified that would be cool of purse
[02:06] <Grogbot> <rsn8887> Course
[02:09] <Grogbot> <ccawley2011> The active DisplayRect is already used on Switch, so if it works there, it should be usable on Vita as well with few modifications.
[02:10] <Grogbot> <rsn8887> Well SDL2 on Switch uses a gl backend so it is a fast and complete SDL2 implementation.
[02:12] <Grogbot> <rsn8887> SDL2 ob Vita is just insanely slow when sdl_blit and sdl_surface is used hence the usage of vita2d directly which is fast
[02:12] <Grogbot> <rsn8887> On Vita. Compared to using SDL2 for that crap. Also keep in mind that almost all functions regarding windows etc are just not implemented on Vita SDL2 port
[02:13] <Grogbot> <ccawley2011> The SurfaceSDL graphics manager simply clears the screen each time a new frame is drawn, so the same thing could be done on Vita as well. If necessary, I can add a variable that's set when the active DisplayRect changes, so the screen is only cleared when necessary.
[02:14] <Grogbot> <rsn8887> I am not sure how slow the clear screen is should be fast if vita2d_clear is called.
[02:15] <Grogbot> <rsn8887> So you are saying vita2d_clear should be called in updaterects, and activedisplayrect should be used to determine where to draw the texture e.g. for x y and sx at?
[02:16] <Grogbot> <rsn8887> But how is activedisplayrect determined?
[02:16] <-- cd left irc: Ping timeout: 268 seconds
[02:17] <Grogbot> <rsn8887> It seems to me it has no knowledge of vita screen size even
[02:17] <Grogbot> <rsn8887> So how is x offset determined to ensure the rect is centered
[02:18] <Grogbot> <ccawley2011> The DisplayRect is updated here: https://github.com/scummvm/scummvm/blob/master/backends/graphics/windowed.h
[02:19] <Grogbot> <ccawley2011> You'll need to ensure handleResize() is called when the application starts to inform it of the screen resolution.
[02:22] <Grogbot> <ccawley2011> The DisplayRect itself is calculated in populateDisplayAreaDrawRect(), which is calculated based on the active stretch mode.
[02:23] <Grogbot> <ccawley2011> It doesn't account for aspect ratio, though, which I'll try and take care of soon-ish.
[02:24] <Grogbot> <ccawley2011> Anyway, it's very late, so I should go now.
[02:25] <Grogbot> <rsn8887> Ok yeah I dont think any of these variables are currently actually used in the Vita implementation to draw anything.
[02:26] <Grogbot> <rsn8887> But it might just be a few small changes I am not sure. I remember the hardware aspect ratio correction was a pain to get working on Vita because ScummVM insisted on doing it in software (and crappily) that might have changed since then though.
[02:27] <Grogbot> <rsn8887> That weird software scaling algorithm so bad
[02:28] <Grogbot> <rsn8887> there can be no software scaling way too slow on Vita and also looks much worse than the shaders.
[02:28] <Grogbot> <rsn8887> And vita2d offers hardware scaling for free
[02:29] <Grogbot> <rsn8887> I will take a loom thanks for the link
[02:29] <Grogbot> <rsn8887> Look
[02:30] <-- JohnnyonFlame left irc: Ping timeout: 276 seconds
[02:31] <Grogbot> <rsn8887> Lol a real lucasarts Freudian
[02:35] <Grogbot> <rsn8887> How is it scaling to display rect size? In software?
[02:38] <Grogbot> <SupSuper> i think WindowedGraphicsManager just calculates coordinates, it doesn't do any rendering. so the point is to use those coordinates instead of trying to do it yourself
[02:40] <Grogbot> <SupSuper> you still do the rendering however you prefer
[02:53] --> cd joined #scummvm.
[03:02] <Grogbot> <rsn8887> So I could call handleResize(960, 544) in the constructor.
[03:04] <Grogbot> <SupSuper> right. for example if you look at the base surface renderer: https://github.com/scummvm/scummvm/blob/master/backends/graphics/surfacesdl/surfacesdl-graphics.cpp#L2778
[03:04] <Grogbot> <SupSuper> they pass the "window" size in handleResize in SetVideoMode. then in SDL_UpdateRects they just get the drawRect coordinates (which presumably already did all the math for you) and use that
[03:05] <Grogbot> <SupSuper> this way every backend doesn't need to do their own math for features like screen shaking
[03:07] <Grogbot> <rsn8887> Yes I think this will work almost.
[03:08] <Grogbot> <rsn8887> I think I understand it now.
[03:08] <Grogbot> <rsn8887> However SDL_SetVideoMode should be creating a small texture, not a texture for the whole window?
[03:09] <Grogbot> <rsn8887> I think SDL_SetVIdeoMode must be called with game screen size, to ensure a small texture.
[03:09] <Grogbot> <rsn8887> Then, in updateRects, that texture is scaled to _activeArea size.
[03:09] <Grogbot> <rsn8887> That allows hardware scaling like before, but in a more ScummVM friendly way, actually using _activeArea correctly.
[03:10] <Grogbot> <rsn8887> However it only "almost" workd, becasue aspect ratio correction seems to be a mess.
[03:10] <Grogbot> <rsn8887> ANd not taken into account in _activeArea
[03:11] <Grogbot> <rsn8887> Making hardware aspect ratio correction possible only via hard-coding and adjusting the final rect
[03:11] <Grogbot> <rsn8887> Depending on the aspectcorrection setting.
[03:11] <Grogbot> <rsn8887> Unless I am still missing something.
[03:11] <Grogbot> <SupSuper> yes, SDL_SetVideoMode is called with game size
[03:12] <Grogbot> <SupSuper> i think the end goal is activeArea calculates the final scaled size and coordinates
[03:13] <Grogbot> <SupSuper> so your internal texture is the unscaled game size. and activeArea is the "end goal". and it's to you to hardware render and apply scalers so that the small texture matches the activeArea coordinates in the end
[03:14] <Grogbot> <rsn8887> yes perfect. Another problem apart from aspect correction problem:
[03:14] <Grogbot> <SupSuper> so if you have a 320x200 game running in 960x544 screen with scalers, corrections, etc. activeArea will calculate and tell you the end result should be at x=16 y=30 w=640 h=400 (made up values). and you use that
[03:14] <Grogbot> <rsn8887> How do I access _activeArea from the event manager to make touch work correctly?
[03:14] <Grogbot> <rsn8887> I need to know "where" the user is touching the screen.
[03:15] <Grogbot> <rsn8887> Is there a getter function? I cannot find it.
[03:15] <Grogbot> <rsn8887> I used g_system->getHeight()
[03:15] <Grogbot> <rsn8887> before
[03:15] <-- dreammaster left irc:
[03:16] <Grogbot> <rsn8887> But that is game screen height (in game pixels)
[03:16] <Grogbot> <rsn8887> Not _activeArea height.
[03:18] <Grogbot> <SupSuper> might wanna check warpMouse and convertWindowToVirtual methods in WindowedGraphicsManager
[03:19] <Grogbot> <SupSuper> if you can get to those from eventmanager
[03:21] <Grogbot> <rsn8887> they are protected so no
[03:22] <Grogbot> <rsn8887> getHeight and getWidth worked because they were publix
[03:22] <Grogbot> <rsn8887> public. lol
[03:22] <Grogbot> <rsn8887> Well that's a showstopper then.
[03:22] <Grogbot> <rsn8887> But I was almost there.
[03:23] <Grogbot> <rsn8887> I couldl leave the old kludge for touch, and put the new activeArea stuff for screen, but I am pretty sure there will be many situations where they become out of sync 😃
[03:24] <Grogbot> <rsn8887> I am pretty sure @ccawley2011 wasn't aware that _activeArea is needed to make direct touch work on Vita....
[03:24] <Grogbot> <rsn8887> THat's why I immediately mentioned it earlier.
[03:24] <Grogbot> <SupSuper> yeah probably wait for someone more familiar with backends to explain that, or look at other backends
[03:24] <Grogbot> <SupSuper> there's other touch backends
[03:24] <Grogbot> <rsn8887> Hmm. The Switch does it.
[03:24] <Grogbot> <rsn8887> Let's see.
[03:25] <Grogbot> <rsn8887> Uses the same kludge.
[03:26] <Grogbot> <rsn8887> But looks more logical than the Vita one. Weird.
[03:27] <Grogbot> <rsn8887> Ah because Switch uses ScummVM aspect correction.
[03:27] <Grogbot> <rsn8887> The software implementation I think.
[03:27] <Grogbot> <rsn8887> Unless that has been fixed I am out of the loop
[03:27] <Grogbot> <rsn8887> Is that scale200to240() crap still used?
[03:28] <Grogbot> <rsn8887> I hope not.
[03:28] <Grogbot> <rsn8887> It should be handled by simply adjusting the ActiveArea, but when I last looked, that was kind of stubbed out.
[03:30] <Grogbot> <rsn8887> Ok it compiles
[03:38] <Grogbot> <rsn8887> Almost working perfectly
[03:38] <Grogbot> <SupSuper> seems every backend does its own weird hack to get graphics coordinates into events, since they're two separate managers 🤔
[03:42] <Grogbot> <rsn8887> yeah
[03:42] <Grogbot> <rsn8887> Welcome to C++
[03:42] <Grogbot> <rsn8887> But it works already, same way as on Switch.
[03:43] <Grogbot> <SupSuper> cool
[03:43] <Grogbot> <SupSuper> just have to wait for aspect ratio correction
[03:43] <Grogbot> <rsn8887> Yup even aspect correction
[03:44] <Grogbot> <SupSuper> i guess that's the problem with supporting 999 platforms, it's hard to standardize when you wanna add something new
[03:45] <Grogbot> <SupSuper> i think that's what ccawley is doing, refactoring backends so they use generic methods as much as possible instead of custom code which is hard to maintain
[03:46] <Grogbot> <SupSuper> less code, less bugs
[03:49] <Grogbot> <rsn8887> Yes and his suggestion totally works.
[03:49] <Grogbot> <rsn8887> But I have a suspicion the aspect correction that is happening is a software scaling, but not 100% sure.
[03:56] <Grogbot> <rsn8887> Yup it is using real2aspect and stretch200To240Interpolated
[03:56] <Grogbot> <rsn8887> Why is that still there?
[03:56] <Grogbot> <rsn8887> Or wait
[04:02] <Grogbot> <rsn8887> Yeah. It uses stretch200To240
[04:03] <Grogbot> <rsn8887> Why can I not make an issue in scummvm/scummvm?
[04:12] <Grogbot> <rsn8887> Ok I made an issue: https://bugs.scummvm.org/ticket/11075#ticket
[04:14] <Grogbot> <rsn8887> Is there an easy way I can force Fullscreen mode?
[04:18] <-- BeefEats left irc: Quit: Bye
[04:27] <Grogbot> <rsn8887> I guess I can disable kFeatureFullScreenMode
[05:32] <Grogbot> <rsn8887> So aspect correction in Dreamweb doesn't work at all on any SDL1 or SDl2 platform (using 1x or 2x rendering). Works fine when enabling OpenGL.
[05:32] <Grogbot> <rsn8887> Apart from Vita, where it is currently forced via hardware scaling.
[05:33] --> Begasus joined #scummvm.
[05:36] --> Begas_VBox joined #scummvm.
[05:57] <Grogbot> <Henke37> i am just curious why the scaling didn't work for me on windows.
[05:58] <Grogbot> <Henke37> i would've thought that windows was in the top three most tested platforms
[05:58] <Grogbot> <SupSuper> what scaling?
[05:59] <Grogbot> <Henke37> the mouse cursor scaling.
[05:59] <Grogbot> <Henke37> as i posted a screenshot yesterday, it appears to not be scaled at all
[06:03] <Scummette> [scummvm] rsn8887 opened pull request #1803: Use activeArea rectangle also on Vita (WIP do not merge yet) (master...psp2activeArea) https://git.io/fj5By
[06:16] <Grogbot> <rsn8887> The cursor not scaling is a long-standing issue maybe? I saw it a week ago on Switch, too. When I tested the screen shaking.
[06:17] <Grogbot> <rsn8887> It said the yellow cursor should be same size as red square but instead the red square was much larger than the cursor. So this happens on Switch too not just Windows.
[06:18] <Grogbot> <SupSuper> haven't checked testbed but scaling seems fine in gui and games
[06:18] <Grogbot> <SupSuper> but i'm not sure which games use cursormanager
[06:19] <Grogbot> <SupSuper> possibly the cursor is scaled up to 2x but not 3x?
[06:23] --> jammm joined #scummvm.
[06:24] <-- Drenn left irc: Ping timeout: 246 seconds
[06:25] <Grogbot> <rsn8887> I think it wasn't scaled at all for me on Switch, iirc.
[06:35] <-- jammm left irc: Ping timeout: 245 seconds
[06:45] <Scummette> [scummvm] sluicebox opened pull request #1804: SCI: Fix SQ4CD Unstable ordnance bug (master...sq4bombfix) https://git.io/fj5RZ
[06:47] <Grogbot> <SupSuper> you're right that the cursors in the testbed don't match. but i'm kinda confused about what it's testing
[06:47] <Grogbot> <SupSuper> since there's cursor scale and gfx scale
[06:49] <-- SupSuper left irc: Quit: Rip
[06:50] <Grogbot> <SupSuper> and i only see the problem in testbed
[06:50] <Grogbot> <SupSuper> assuming testbed isn't the problem
[07:02] <Grogbot> <SupSuper> i assume in a game the cursor scale and gfx scale are always the same, and in those cases it matches
[07:11] <-- borosky left irc: Read error: Connection reset by peer
[07:11] --> borosky joined #scummvm.
[07:17] <-- nutron|w left irc: Ping timeout: 244 seconds
[07:17] <-- cd left irc: Ping timeout: 246 seconds
[07:23] --> jamm joined #scummvm.
[07:32] --> nutron|w joined #scummvm.
[07:55] <Scummette> [scummvm] bluegr closed pull request #1804: SCI: Fix SQ4CD Unstable ordnance bug (master...sq4bombfix) https://git.io/fj5RZ
[07:55] <Scummette> [scummvm] bluegr pushed 1 new commits to master: https://git.io/fj50Y
[07:55] <Scummette> scummvm/master f019afa sluicebox: SCI: Fix SQ4CD Unstable ordnance bug
[07:59] <Grogbot> <juicebox> Space quest 4 is an endless supply of interesting bugs meanwhile Space quest 5, which is the one I loved as a kid, has practically none
[08:17] <Scummette> [scummvm] sev- closed pull request #1566: COMMON: Move the Lua code from SWORD25 to COMMON (master...lua-merge) https://git.io/fjkwH
[08:17] <Scummette> [scummvm] sev- pushed 1 new commits to master: https://git.io/fj502
[08:17] <Scummette> scummvm/master c1f029c nipunG314: COMMON: Move Lua into Common and make it into...
[08:24] <Scummette> [scummvm] waltervn pushed 1 new commits to master: https://git.io/fj50i
[08:24] <Scummette> scummvm/master 91c6399 waltervn: NEWS: List ADL changes
[08:36] --> vliaskov joined #scummvm.
[08:42] <ScummBot> Port build status changed with c1f029c6: Failure: master-openpandora
[08:48] --> JohnnyonFlame joined #scummvm.
[09:15] <Grogbot> <md5> Quite a strange build error, and Im not near a PC to check it
[09:16] <Grogbot> <md5> common/libcommon.a(ldblib.o): In function luaopen_debug(lua_State*)': ldblib.cpp:(.text+0x0): multiple definition ofluaopen_debug(lua_State*)' common/libcommon.a(ldblib.o):ldblib.cpp:(.text+0x0): first defined here
[09:20] <-- jamm left irc: Ping timeout: 258 seconds
[09:22] <Grogbot> <criezy> That's because there is a duplicate lua/ldblib.o in common/module.mk
[09:22] <Grogbot> <criezy> But I am not near a PC either, so can't fix that right now.
[09:23] <Scummette> [scummvm] ccawley2011 pushed 1 new commits to master: https://git.io/fj5Er
[09:23] <Scummette> scummvm/master 46adbfa ccawley2011: LUA: Remove duplicate object file from module.mk
[09:23] <Grogbot> <criezy> That was quick 😛
[09:25] <Grogbot> <md5> Indeed 😃 thanks!
[09:32] <ScummBot> Port build status changed with c1f029c6: Failure: master-psp
[10:39] <ScummBot> Port build status changed with c1f029c6: Failure: master-gamecube, master-ps2, master-pspfull, master-gcw0, master-gp2xwiz
[10:59] <ScummBot> Port build status changed with c1f029c6: Failure: master-dc-serial
[11:28] <LePhilousophe> ouch
[11:42] <ScummBot> Port build status changed with c1f029c6: Failure: master-dingux, master-wii
[12:00] <Grogbot> <md5> Yeah, all the port builds will fail, and the succeed
[12:00] <Grogbot> <md5> Then *
[12:12] --> vyzigold joined #scummvm.
[12:31] <ScummBot> Port build status changed with c1f029c6: Failure: master-webos, master-dc
[13:05] <ScummBot> Port build status changed with c1f029c6: Failure: master-caanoo
[13:11] <Grogbot> <Henke37> these builds sure are taking a while to run.
[13:12] <-- tsoliman left irc: Quit: I've been banished!
[13:13] --> tsoliman joined #scummvm.
[13:13] #scummvm: mode change '+o tsoliman' by ChanServ!ChanServ@services.
[13:21] <Grogbot> <md5> Indeed
[13:21] <Grogbot> <md5> There was a way to stop the builds from the web site
[13:22] <Grogbot> <md5> Its password protected
[13:23] --> borasky joined #scummvm.
[13:25] <-- borosky left irc: Ping timeout: 248 seconds
[13:40] <ScummBot> Port build status changed with c1f029c6: Failure: master-ds
[13:51] --> timofonic joined #scummvm.
[14:08] --> Strangerke_ joined #scummvm.
[14:11] <-- Strangerke left irc: Ping timeout: 268 seconds
[14:11] Nick change: Strangerke_ -> Strangerke
[14:15] <Grogbot> <md5> Hm, some builds are still failing
[14:18] <Grogbot> <md5> Probably the ones where sword25 is not enabled?
[14:44] <Grogbot> <criezy> It looks like an incremental build issue.
[14:44] <Grogbot> <criezy> All the builds that were failing are still failing with the same error because libcommon.a is not recompiled/regenerated and still has the duplicate symbols.
[15:00] --> BeefEats joined #scummvm.
[15:12] --> uwjesq joined #scummvm.
[15:12] <uwjesq> Hey guys! Thanks again for Blade Runner. It is amazing!
[15:12] <uwjesq> One of my favorite games of all time.
[15:13] <uwjesq> I've been waiting for it to come to scummvm for years. And now it runs so perfect. Better than the original build.
[15:18] <Grogbot> <md5> Darn :/
[15:18] <Grogbot> <md5> (About the incremental builds)
[15:19] <Grogbot> <md5> And yes, Blade Runner runs beautifully under ScummVM 😃
[15:21] --> Drenn joined #scummvm.
[15:22] <Grogbot> <Trembyle> @juicebox Is QEMU the best emulator to compare behavior for the SCI Mac versions to ScummVM?
[15:23] <Grogbot> <rsn8887> Shall I restart the buildbot?
[15:23] <Grogbot> <rsn8887> I feel like that might help the failing builds, but not sure.
[15:24] <Grogbot> <juicebox> maybe? if you can get the game to run in either, from there you're fine
[15:26] <Grogbot> <juicebox> for me, i needed qemu to get around the 1993 timebomb, because sheepsaver doesn't let you set system time and i wouldn't change my host system clock
[15:26] <Scummette> [scummvm] bluegr closed pull request #736: SCUMM,GUI: Add checkbox to toggle COMI's object_labels (Do not merge) (master...comi_object_labels) https://git.io/vVGIl
[15:27] <Grogbot> <juicebox> but setting up qemu is a bit of work, so if you can get the game to run on something else easier and it works, i'd use that
[15:27] <Grogbot> <Trembyle> You just need to change the system clock when the game starts, then you can change it back
[15:28] <Grogbot> <Trembyle> I was thinking that QEMU might have better QuickTime performance, but I guess that's a small part of the game
[15:28] <Grogbot> <juicebox> i didn't see any speed differences
[15:28] <Grogbot> <Trembyle> Anyway, I found a bug (can't get the peppermint), but I wanted to be sure that I'm comparing it against an emulator so we know whether that's real behavior
[15:29] <Grogbot> <juicebox> oh! for a high level bug like that, go ahead and report it
[15:29] <Grogbot> <juicebox> or i mean, tell me about it now and send me a save 😃
[15:30] <Grogbot> <juicebox> oh, or do you mean that you're not sure if it's mac vs pc behavior?
[15:31] <Grogbot> <Trembyle> I checked with a KQ6 expert who claims he's seen this before in PC, but I'm not sure.
[15:31] <Grogbot> <juicebox> ah, okay
[15:31] <Grogbot> <juicebox> i don't remember the peppermint rules off the top of my head
[15:31] <Grogbot> <Trembyle> Basically, rm390 (cave) doesn't change state properly from Cave1 to Cave2
[15:31] <Grogbot> <Trembyle> You can get the peppermint, but then you can't leave the cave
[15:31] <Grogbot> <Trembyle> there is no clickable exit
[15:32] <Grogbot> <juicebox> is it always happening to you or only sometimes? that would be bad if you're trapped in that room
[15:33] <Grogbot> <Trembyle> https://cdn.discordapp.com/attachments/581224061091446795/610858672784146432/unknown.png
[15:34] <Grogbot> <Trembyle> You can see the exit from Cave1 on the left
[15:34] <Grogbot> <Trembyle> but this is in Cave2
[15:34] <Grogbot> <Trembyle> Getting a save. I haven't restarted the game to see if I can trigger it again.
[15:35] <Grogbot> <Trembyle> But it always happens from this save at least
[15:44] <Scummette> [scummvm] ccawley2011 pushed 1 new commits to master: https://git.io/fj5r8
[15:44] <Scummette> scummvm/master e609d02 ccawley2011: LUA: Fix end of namespace comment
[15:49] --> jammm joined #scummvm.
[15:49] <-- jammm left irc: Changing host
[15:49] --> jammm joined #scummvm.
[15:53] <Grogbot> <md5> I remember this bug with the peppermint. We had fixed it years ago
[15:54] <Grogbot> <juicebox> i can reproduce it in mac
[15:55] <Grogbot> <juicebox> the peppermint itself isn't the problem, you can see on that screenshot that it's drawing the entrance for the first room (on the left) on the right
[15:59] <Grogbot> <md5> https://bugs.scummvm.org/ticket/5383
[16:01] <Grogbot> <juicebox> maybe, i'm making tea before jumping in, but the palette seems fine, and i don't see mention of the wrong entrance graphic being drawn
[16:03] <-- Begas_VBox left irc: Quit: Vision[0.10.3]: i've been blurred!
[16:03] <Grogbot> <juicebox> how does resolve a subversion revision number from ye olde days to a git commit?
[16:05] <Grogbot> <ccawley2011> @juicebox All commits from before we moved to git should have the Subversion revision included in the commit message.
[16:06] <Grogbot> <juicebox> ah, thank you!
[16:12] <ScummBot> Port build status changed with e609d024: Success: master-openpandora, master-psp, master-gamecube, master-ps2, master-pspfull, master-gcw0, master-gp2xwiz, master-dc-serial, master-dingux, master-wii, master-webos, master-dc, master-caanoo
[16:12] <LePhilousophe> great!
[16:13] <Grogbot> <md5> Thanks @ccawley2011
[16:13] <LePhilousophe> btw about docker buildbot, is there a track of bugs met?
[16:20] --> ny00123 joined #scummvm.
[16:28] <Grogbot> <md5> @Lephilousophe: not AFAIK
[16:43] <Grogbot> <ccawley2011> LePhilousophe: Could you share what you've done with the buildbot so far?
[16:44] --> ccawley2011 joined #scummvm.
[16:44] #scummvm: mode change '+o ccawley2011' by ChanServ!ChanServ@services.
[16:47] <Scummette> [scummvm] nipunG314 opened pull request #1805: HDB: Add engine for Hyperspace Delivery Boy (master...hyperspace-delivery-boy) https://git.io/fj5oK
[17:02] --> SupSuper joined #scummvm.
[17:10] uwjesq (henry@w3-net.de) left #scummvm.
[17:19] --> criezy joined #scummvm.
[17:19] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[17:20] <Grogbot> <Henke37> that's a lot of complaint in the resulting report. looks automated. and some of those rules doesn't feel scummvm like
[17:20] <Grogbot> <Henke37> complaining about null termination?
[17:25] <-- BeefEats left irc: Ping timeout: 264 seconds
[17:26] --> BeefEats joined #scummvm.
[17:29] --> ccawley2011_ joined #scummvm.
[17:29] #scummvm: mode change '+o ccawley2011_' by ChanServ!ChanServ@services.
[17:32] <-- ccawley2011 left irc: Ping timeout: 258 seconds
[17:34] --> Strangerke_ joined #scummvm.
[17:36] <-- Strangerke left irc: Ping timeout: 245 seconds
[17:36] Nick change: Strangerke_ -> Strangerke
[17:40] <-- vliaskov left irc: Remote host closed the connection
[17:41] <Grogbot> <SupSuper> i think it's just a static analyzer yeah
[17:49] --> ajax16384 joined #scummvm.
[17:49] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[18:15] <Scummette> [scummvm] antoniou79 pushed 1 new commits to master: https://git.io/fj562
[18:15] <Scummette> scummvm/master 67fd0ca antoniou79: BLADERUNNER: Prevent Replicants from despawning from the moonbus
[18:19] --> SylvainTV joined #scummvm.
[18:19] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[18:25] <Grogbot> <Strangerke> @nipung yeah! Congrats
[18:27] <LePhilousophe> ccawley2011: I have not that much and I would like to have some cross compilation worker ready before sharing
[18:27] <LePhilousophe> to ensure I am confident with the choices I did
[18:28] <LePhilousophe> I think I will have time till the end of week to work on it (15th of august is a holiday in France)
[18:28] <LePhilousophe> I hope to be able to share a beginning there
[18:29] <Grogbot> <nipung> @Strangerke Thanks!
[18:44] <-- Lightkey left irc: Ping timeout: 250 seconds
[18:56] --> Lightkey joined #scummvm.
[18:58] <-- jammm left irc: Ping timeout: 244 seconds
[19:18] <-- Begasus left irc: Quit: Ex-Chat
[19:52] <-- SupSuper left irc: Read error: Connection reset by peer
[19:55] <-- borasky left irc: Read error: Connection reset by peer
[19:55] --> borosky joined #scummvm.
[20:33] <-- ajax16384 left irc: Read error: Connection reset by peer
[20:51] <-- BeefEats left irc: Quit: Bye
[21:12] <-- _sev left irc: Ping timeout: 245 seconds
[21:16] <Scummette> [scummvm] ScummVM-Translations pushed 2 new commits to master: https://git.io/fj51n
[21:16] <Scummette> scummvm/master 4453f3c criezy: I18N: Regenerate translations data file
[21:16] <Scummette> scummvm/master 440f5bd criezy: I18N: Update translations templates
[21:16] <-- ny00123 left irc: Quit: Leaving
[21:19] --> _sev joined #scummvm.
[21:19] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[21:20] <-- delacroix left irc: Read error: Connection reset by peer
[21:24] <Scummette> [scummvm] ScummVM-Translations pushed 2 new commits to master: https://git.io/fj51V
[21:24] <Scummette> scummvm/master 7224974 lotharsm: I18N: Update translation (German)
[21:24] <Scummette> scummvm/master 9c78fbd criezy: I18N: Update translation (French)
[21:25] --> delacroix joined #scummvm.
[21:31] <Scummette> [scummvm] ScummVM-Translations pushed 1 new commits to master: https://git.io/fj51S
[21:32] <Scummette> scummvm/master 69f02ce criezy: I18N: Update translation (French)
[21:32] <Scummette> [scummvm] ScummVM-Translations pushed 1 new commits to master: https://git.io/fj51Q
[21:32] <Scummette> scummvm/master 145f5c1 lotharsm: I18N: Update translation (German)
[21:38] <-- JohnnyonFlame left irc: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.
[21:46] <-- criezy left irc: Quit: criezy
[21:46] --> cd joined #scummvm.
[21:48] <Scummette> [scummvm] ScummVM-Translations pushed 1 new commits to master: https://git.io/fj5Mt
[21:48] <Scummette> scummvm/master a414165 lotharsm: I18N: Update translation (German)
[21:58] <Scummette> [scummvm] ScummVM-Translations pushed 1 new commits to master: https://git.io/fj5MG
[21:58] <Scummette> scummvm/master 59cff4b lotharsm: I18N: Update translation (German)
[22:10] <-- ccawley2011_ left irc: Quit: Leaving
[22:12] <Grogbot> <rsn8887> @ccawley2011 : I think populateDisplayAreaDrawRect already takes aspect ratio into account when calculating _activeArea
[22:13] <Grogbot> <rsn8887> So I think the solution is simply to remove all the calls to 200to240* functions and almost all calls to real2aspect() in surfacesdl-graphics.cpp
[22:13] <Grogbot> <rsn8887> The only ones that should remain I think are these if (_videoMode.aspectRatioCorrection) { _videoMode.overlayHeight = real2Aspect(_videoMode.overlayHeight); _videoMode.hardwareHeight = real2Aspect(_videoMode.hardwareHeight); }
[22:14] <Grogbot> <rsn8887> Then _activeArea will magically take care of aspect ratio correction.
[22:14] <Grogbot> <rsn8887> I will test it on Vita, and then add another commit to my PR.
[22:18] <Grogbot> <rsn8887> Actually I think even those last two should go away 😃
[22:19] <Grogbot> <rsn8887> I will see if I can make it work.
[22:19] <Grogbot> <rsn8887> On Vita, then go from there to look at other platforms.
[22:22] <Grogbot> <rsn8887> One downside to this is that the overlay will be stretched a bit, just like the hardware aspect correction on Vita was before.
[22:22] <Grogbot> <rsn8887> E.g. the fonts will appear more tall and skinny when AR is enabled.
[22:23] <Grogbot> <rsn8887> Since the drawing surface and resolution doesn't change when changing AR correction on/off. Only the way it is blitted to the screen to the _activeArea changes.
[22:23] <Grogbot> <rsn8887> But the same happens currently when changing stretch mode.
[22:24] <Grogbot> <rsn8887> In fact the way I envision it, AR correction is not really different than adding extra stretch modes.
[22:25] <Grogbot> <rsn8887> That's how it is handles basically in all other emulators.
[22:25] <Grogbot> <rsn8887> By allowing "4:3 fit, 16:9 fit, 16:10 fit, Stretch, etc."
[22:26] <Grogbot> <rsn8887> as stretch modes.
[22:26] <Grogbot> <rsn8887> I guess stretch modes were added to ScummVM after AR correction, that's why they are treated separately now.
[22:27] <Grogbot> <rsn8887> So a quick workaround to enable hardware aspect ratio correction without any disruption of existing functionality would be to add a few extra stretch modes.
[22:28] <Grogbot> <rsn8887> In addition to {"center", _s("Center"), STRETCH_CENTER}, {"pixel-perfect", _s("Pixel-perfect scaling"), STRETCH_INTEGRAL}, {"fit", _s("Fit to window"), STRETCH_FIT}, {"stretch", _s("Stretch to window"), STRETCH_STRETCH}, {nullptr, nullptr, 0}
[22:29] <Grogbot> <rsn8887> One could add cpp fit 4:3
[22:29] <Grogbot> <rsn8887> That would be the aspect correction stretch mode.
[22:48] <Grogbot> <ccawley2011> One thing to remember is that the old aspect ratio code is still needed by SDL1, since that port doesn't have arbitrary scalers.
[22:49] <Grogbot> <rsn8887> Yeah. I think adding a stretch mode is the best at the moment.
[22:50] <Grogbot> <rsn8887> Why not require SDL2?
[22:50] <Grogbot> <ccawley2011> SDL1 is still required by a number of platforms. RISC OS is one of them.
[22:50] <Grogbot> <rsn8887> Ok Stretch mode it is then.
[22:51] <Grogbot> <rsn8887> Can I add to the middle of the enum without breaking everybody's ini?
[22:51] <Grogbot> <rsn8887> enum { STRETCH_CENTER = 0, STRETCH_INTEGRAL = 1, STRETCH_FIT = 2, STRETCH_FIT_FORCE_ASPECT = 3, STRETCH_STRETCH = 4, };
[22:51] <Grogbot> <rsn8887> Or are these options stored as numbers?
[22:51] <Grogbot> <ccawley2011> Doesn't the .ini file use names for stretch modes?
[22:51] <Grogbot> <rsn8887> I think so.
[22:52] <Grogbot> <SupSuper> why not just add to the end?
[22:54] <Grogbot> <rsn8887> ok
[22:56] <Grogbot> <rsn8887> Why is float being avoided in favor of frac_t everywhere?!?
[22:57] <Grogbot> <ccawley2011> Floating point arithmetic isn't guaranteed to be fast on all systems.
[23:01] <Grogbot> <rsn8887> Ok
[23:01] <Grogbot> <rsn8887> Shall I call it "Fit 4:3" or "Fit to window (force 4:3)" I cannot decide
[23:02] <Grogbot> <rsn8887> Fit 4:3 it is short and sweet
[23:03] <Dark-Star> I'd use "Force 4:3". "Fit 4:3" is ambiguous I think ("Fit 4:3 [content to something else]" vs. "Fit [to] 4:3 [aspect ratio]")
[23:10] <Grogbot> <SupSuper> i would just use "fit to window (4:3)" (the "force" is implicit)
[23:11] <Grogbot> <SupSuper> assuming you are combining "fit to window" + "4:3 aspect correction"
[23:14] <Scummette> [scummvm] rsn8887 opened pull request #1806: BACKENDS: add Fit 4:3 stretch mode to SDL2 backend (master...stretchmode) https://git.io/fj5D5
[23:16] <Grogbot> <rsn8887> Ok I will change the name
[23:18] <Grogbot> <rsn8887> This is almost trivial.
[23:18] <Grogbot> <rsn8887> And hopefully will give hardware aspect ratio correction on all SDL2 platforms.
[23:20] <Grogbot> <ccawley2011> Cool. I'll give it a try on Android tomorrow.
[23:21] <Grogbot> <rsn8887> Ok I will also test it tonight.
[23:22] <Grogbot> <rsn8887> I mean if the other stretch modes work, this one should too.
[23:23] <Grogbot> <SupSuper> might need some gui clarity, if there's now an aspect correction mode separate from the aspect correction checkbox
[23:24] <Grogbot> <rsn8887> Oh I made a mistake too need to force push
[23:28] <Grogbot> <rsn8887> Ok now it should be good.
[23:28] <Grogbot> <rsn8887> yeah maybe.
[23:28] <Grogbot> <rsn8887> I mean the checkbox does the software thing, and the stretchmode the hardware thing.
[23:29] <Grogbot> <rsn8887> But if the checkbox is ticked and the stretch mode is used, the stretch mode will do the same as Fit to window, because aspect will already be 4:#
[23:29] <Grogbot> <rsn8887> Hmm, I think it is clear.
[23:29] <Grogbot> <rsn8887> Aspect Ratio Correction only corrects some games.
[23:30] <Grogbot> <rsn8887> The stretch mode always enforces 4:3 regardless of game
[23:30] <Grogbot> <SupSuper> oh ok
[23:31] <Grogbot> <SupSuper> then you'd want aspect correction checkbox to use hardware stretch internally if possible, otherwise software stretch
[23:31] <Grogbot> <rsn8887> Yes that would be the ideal, but that's a whole can of worms really. For another time.
[23:31] <Grogbot> <rsn8887> Also I don't know, some old systems might not do the hardware stretch so well, but the software one better.
[23:32] <Grogbot> <rsn8887> And SDL1 can only do the software stretch.
[23:32] <Grogbot> <SupSuper> true, it should be a backend decision
[23:32] <Grogbot> <SupSuper> backends are too vast for me to wrap my head around right now
[23:32] <Grogbot> <SupSuper> but i know they'll come for me eventually
[23:34] <Grogbot> <rsn8887> Backends I find much more logical than the engines 😃
[23:35] <Grogbot> <rsn8887> @ccawley2011 : Did you think of stretch modes in that screen shake PR?
[23:36] <Grogbot> <rsn8887> Because the old way of shaking was done "internally" to the game screen, so would be stretched correctly by all the stretch modes. But the new way, if I understand is done "externally" to the game screen, so maybe would not be stretched correctly by all the stretch modes?
[23:41] <Grogbot> <rsn8887> For example, if I use the new 4:3 stretch mode compared to say "center" mode, the old screen shake would automatically shake the screen further down, because it is now taller.
[23:41] <Grogbot> <rsn8887> Because it was done in game pixels.
[23:43] <Grogbot> <rsn8887> I guess maybe your PR works correctly anyways because it is using the activeArea height to find the scale by which to multiply the shaking amount. So, I guess it will work ok with all modes.
[23:44] <Grogbot> <rsn8887> So never mind it is all good 😃
[23:45] <Grogbot> <rsn8887> Now I just need to test and maybe try to find what the problem is with the Vita activeArea PR, why the AR correction checkbox causes so many problems there.
[23:45] <Grogbot> <rsn8887> Because you were right, it is much cleaner to do it with activeArea.
[23:57] --> Deledrius_ joined #scummvm.
[00:00] --- Wed Aug 14 2019