[Back to Index]

[00:18] <-- dreammaster left irc:
[01:01] <-- SylvainTV left irc: Quit: User pushed the X - because it's Xtra, baby
[01:38] <Scummette> [scummvm] sluicebox opened pull request #1667: SCI: Fix SQ4 Monolith Burger door message, bug #10976 (master...sq4burgerdoormsg) https://git.io/fjakq
[01:38] --> DominusExult joined #scummvm.
[01:38] <-- DominusExult left irc: Changing host
[01:38] --> DominusExult joined #scummvm.
[01:39] <-- Dominus left irc: Ping timeout: 248 seconds
[01:39] Nick change: DominusExult -> Dominus
[02:04] <-- Drenn left irc: Ping timeout: 245 seconds
[02:06] --> yuv422 joined #scummvm.
[02:10] <-- yuv422 left irc: Ping timeout: 245 seconds
[02:27] --> dreammaster joined #scummvm.
[02:27] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[02:38] <-- cd left irc: Quit: cd
[02:49] --> borasky joined #scummvm.
[02:51] <-- borosky left irc: Ping timeout: 272 seconds
[03:21] <-- Lightkey left irc: Ping timeout: 248 seconds
[03:34] --> Lightkey joined #scummvm.
[03:49] --> Drenn joined #scummvm.
[03:57] --> yuv422 joined #scummvm.
[04:02] <-- yuv422 left irc: Ping timeout: 246 seconds
[04:50] <-- SupSuper left irc: Quit: Rip
[05:05] <Scummette> [scummvm] bluegr closed pull request #1667: SCI: Fix SQ4 Monolith Burger door message, bug #10976 (master...sq4burgerdoormsg) https://git.io/fjakq
[05:05] <Scummette> [scummvm] bluegr pushed 1 new commits to master: https://git.io/fjaI7
[05:05] <Scummette> scummvm/master f80c11c sluicebox: SCI: Fix SQ4 Monolith Burger door message, bug #10976
[05:24] --> Begasus joined #scummvm.
[05:32] <Scummette> [scummvm] dreammaster pushed 7 new commits to master: https://git.io/fjaLY
[05:32] <Scummette> scummvm/master acc9000 dreammaster: GLK: ADVSYS: Added code for loading savegames from launcher
[05:32] <Scummette> scummvm/master b6542b7 dreammaster: GLK: Fix debug channels setup
[05:32] <Scummette> scummvm/master 1b6ac1a dreammaster: GLK: ADVSYS: Fix variable range checks
[05:32] --> jammm joined #scummvm.
[05:32] <-- jammm left irc: Changing host
[05:32] --> jammm joined #scummvm.
[05:33] <-- dreammaster left irc:
[05:58] <-- Drenn left irc: Ping timeout: 268 seconds
[06:26] --> Begas_VBox joined #scummvm.
[06:33] --> _sev_ joined #scummvm.
[06:33] #scummvm: mode change '+o _sev_' by ChanServ!ChanServ@services.
[06:37] Nick change: _sev_ -> _sev
[06:49] <-- _sev left irc: Quit: This computer has gone to sleep
[07:02] --> _sev joined #scummvm.
[07:02] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[07:06] <-- _sev left irc: Client Quit
[07:18] --> _sev joined #scummvm.
[07:18] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[07:25] <-- _sev left irc: Quit: This computer has gone to sleep
[07:29] --> _sev joined #scummvm.
[07:29] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[07:30] <-- _sev left irc: Client Quit
[07:39] --> _sev joined #scummvm.
[07:39] <-- _sev left irc: Changing host
[07:39] --> _sev joined #scummvm.
[07:39] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[07:59] --> yuv422 joined #scummvm.
[08:02] --> m_kiewitz joined #scummvm.
[08:02] #scummvm: mode change '+o m_kiewitz' by ChanServ!ChanServ@services.
[08:03] <-- yuv422 left irc: Ping timeout: 245 seconds
[08:14] --> Stormkeeper joined #scummvm.
[08:53] <Grogbot> <Praetorian> good mornings
[09:03] <Grogbot> <rootfather> hi @Praetorian
[09:04] <Grogbot> <Joefish> morning 👋
[09:09] <Grogbot> <rootfather> hi @Joefish
[09:33] <Grogbot> <Praetorian> hey @rootfather!
[09:42] <Grogbot> <SiXX> Morning 👋
[09:49] <Grogbot> <rootfather> 👋
[09:59] <Scummette> [scummvm] sluicebox pushed 1 new commits to master: https://git.io/fjaqp
[09:59] <Scummette> scummvm/master 5bb9174 sluicebox: SCI: Fix regression in message workarounds
[10:00] --> yuv422 joined #scummvm.
[10:05] <-- yuv422 left irc: Ping timeout: 246 seconds
[10:31] --> Praetorian|str joined #scummvm.
[11:24] --> cd joined #scummvm.
[11:24] --> whiterandrek joined #scummvm.
[11:24] #scummvm: mode change '+o whiterandrek' by ChanServ!ChanServ@services.
[11:40] --> SylvainTV joined #scummvm.
[11:40] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[12:02] --> criezy joined #scummvm.
[12:02] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[12:26] <-- Begas_VBox left irc: Read error: No route to host
[12:27] <-- Begasus left irc: Ping timeout: 258 seconds
[12:28] --> Begasus joined #scummvm.
[12:32] --> Begas_VBox joined #scummvm.
[13:42] --> ldevulder_ joined #scummvm.
[13:45] <-- default__ left irc: Ping timeout: 245 seconds
[14:02] --> yuv422 joined #scummvm.
[14:07] <-- yuv422 left irc: Ping timeout: 272 seconds
[14:35] --> girafe3 joined #scummvm.
[14:38] <-- girafe2 left irc: Ping timeout: 248 seconds
[15:15] --> Drenn joined #scummvm.
[15:33] <-- noobineer left irc: Ping timeout: 248 seconds
[15:40] <-- _sev left irc: Read error: Connection reset by peer
[15:41] --> _sev joined #scummvm.
[15:41] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[15:43] --> whiterandrek_ joined #scummvm.
[15:43] #scummvm: mode change '+o whiterandrek_' by ChanServ!ChanServ@services.
[15:47] --> SupSuper joined #scummvm.
[15:48] <-- whiterandrek left irc: Ping timeout: 268 seconds
[15:52] --> ny00123 joined #scummvm.
[15:59] <Grogbot> <rsn8887> I am tempted to merge my first person control PR. I tested it some more and it works fine. Are there any objections? https://github.com/scummvm/scummvm/pull/1663
[16:00] <Grogbot> <rsn8887> I shouldnt have made a PR I guess and just committed. It is pretty straightforward after all.
[16:04] <Grogbot> <rootfather> Due to lack of knowledge I cannot comment on the code itself - but the change you propose seems useful. no objections from my side.
[16:33] <Grogbot> <Shockwave_S08> Has anyone tried porting this game to ScummVM yet? Game: Armed & Delirious (Dementia in UK, Granny in Germany) Developers and Publishers: Telstar Electronic Studios, Sirtech, Makhshevet ESRB Rating: Teen Disc Count: 5 Intended Platform: Windows 95 Known issues, based on the Ross's Game Dungeon videos: Uneven sound output in stereo mode, Disc 5 crashes often. Things that may be hard to implement: A dedicated Bra-ventory window, which
[16:33] <Grogbot> was a Win95 box originally. https://m.youtube.com/watch?v=3qRCzIj9QEo https://youtu.be/loBiZjo186Q
[16:36] --> ccawley2011 joined #scummvm.
[16:36] #scummvm: mode change '+o ccawley2011' by ChanServ!ChanServ@services.
[16:37] <Grogbot> <sev> @rsn8887 here?
[16:46] <-- ny00123 left irc: Quit: Leaving
[16:46] <Grogbot> <Strangerke> @Shockwave_S08: Writing an engine for a game is a huge task, you know. I never heard about this game before, nor about anybody who tried to reverse it
[16:46] --> ny00123 joined #scummvm.
[16:47] <Grogbot> <SupSuper> i forsee a lot of video decoding in that game 😛
[16:48] <Grogbot> <rootfather> This game seems to be outright crazy 😄
[16:48] <LePhilousophe> it doesn't seem to be good quality either
[16:48] <LePhilousophe> or the video is bad, I don't understand actions chaining
[16:50] <LePhilousophe> hum it seems player just cuts all transitions
[16:51] <Grogbot> <SupSuper> yeah i've seen a Let's Play of this, it's pretty crazy. there's no traditional walking, you just click on stuff and an animation may or may not happen. lots of timing puzzles, deaths and absolute nonsense. probably intentional
[16:52] <Grogbot> <SupSuper> and the review is just clips, i'm not sure you wanna see the full thing, it's like 6 cds 😛 ah the multimedia era
[16:55] <Grogbot> <rootfather> sounds interesting 😛
[16:58] <-- jammm left irc: Ping timeout: 244 seconds
[17:06] <Grogbot> <rsn8887> @sev : yes
[17:06] <Grogbot> <sev> @rsn8887 pls check your direct messages
[17:37] <-- Begas_VBox left irc: Quit: Vision[0.10.3]: i've been blurred!
[17:38] <-- Begasus left irc: Quit: Ex-Chat
[17:42] <Grogbot> <Mataniko> its pretty terrible
[17:43] <Grogbot> <Mataniko> had it growing up
[17:44] <Grogbot> <Mataniko> Mahkshevet was like 10 minute drive from my hometown growning up, they let me work a couple of times at their support lines
[17:44] <Grogbot> <rootfather> That sounds pretty cool
[18:03] <Grogbot> <rootfather> @rsn8887, I wonder if there is any chance to get absolute cursor movement in the Switch port?
[18:03] <Grogbot> <rootfather> as in "position the cursor exactly where I tap the screen"
[18:04] <Grogbot> <Shockwave_S08> Has the ScummVM team considered allowing custom keybinds per game on the Android port, if the user is playing with a controller? Might come in handy for games with extensive control schemes like Myst/Riven and Starship Titanic, or within specific in-game events.
[18:06] <-- Praetorian|str left irc: Quit: Leaving
[18:12] <-- girafe3 left irc: Read error: Connection reset by peer
[18:13] --> dreammaster joined #scummvm.
[18:13] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[18:15] --> girafe joined #scummvm.
[18:28] <Grogbot> <rootfather> I just made a casual search for new "ScummVM" related footage on YouTube. And well: https://www.youtube.com/results?search_query=scummvm&sp=CAI%253D
[18:28] <Grogbot> <rootfather> it seems that someone started porting scummvm to the MiSTer FPGA computer thingy
[18:34] --> borosky joined #scummvm.
[18:35] <Grogbot> <rsn8887> @rootfather : already implemented on Switch. Just go to options controls and turn touchpad mouse mode off.
[18:35] <-- borasky left irc: Ping timeout: 248 seconds
[18:35] <Grogbot> <rsn8887> https://github.com/scummvm/scummvm/commit/536521d356571be803461b8fc74db84e977f23d8
[18:36] <Grogbot> <rsn8887> Then the pointer touch input is direct
[18:36] <Grogbot> <rsn8887> Shall I make it default?
[18:40] <Grogbot> <rsn8887> @Shockwave_S08 : this is being discussed but not implemented yet (I made a PR allowing an alternative mapping for lands of lore, but nothing else yet)
[18:55] <Grogbot> <rsn8887> I guess I agree we should provide sensible default game controller button maps for engines like Xeen, Lol etc. the virtual mouse pointer control including the slow down hotkey could remain the same always, as could the Menu and Game menu buttons. But the other controller buttons and dpad could be mapped on a per engine basis or so. This is a bigger project than my little lands of lore fox and PR
[18:56] <Grogbot> <rsn8887> In addition this will finally allow us to map dpad to sensible fighting controls in Indy while still working as movement controls in Sierra etc.
[18:57] <Grogbot> <rsn8887> So the game controller input would just automatically work well in all types of games not just point and click adventures like it is now.
[18:58] <Grogbot> <rootfather> @rsn8887 oh great, must have overlooked this setting
[18:58] <Grogbot> <rsn8887> I will make the direct touch the default later today, it seems people expect it to work that way.
[18:58] <Grogbot> <rootfather> that would be great!
[18:58] <Grogbot> <rsn8887> It was the same on Vita everybody complained until I made direct touch the default
[18:59] <Deledrius> "extensive control schemes like Myst/Riven" What do you mean?
[19:00] <Grogbot> <Shockwave_S08> So those with Bluetooth controllers can perform certain in-game actions without needing to bring up the virtual keyboard.
[19:04] <Grogbot> <peterkohaut> @everyone Hello! Please, can somebody help me English proofread next announcement? Send me a private message
[19:04] <Deledrius> the controls in Myst are almost exclusively "click" with a couple of places you "drag". What keyboard interactions am I forgetting?
[19:08] <Scummette> [scummvm] rsn8887 pushed 1 new commits to master: https://git.io/fjaco
[19:10] <Grogbot> <Shockwave_S08> @Deledrius Bringing up the menu in both Myst and Riven, looking up and down in Riven, solving the final starchart puzzle in Starship Titanic, and these are a few examples.
[19:11] <Grogbot> <rsn8887> @rootfather : Direct touch is now the default on Switch, should be in next nightly.
[19:11] <Grogbot> <rootfather> thanks a lot!
[19:13] <Grogbot> <rsn8887> This control scheme stuff I think it really needs to send "EVENT_GAMECONTROLLER_X" etc. to the engine or menu event remapping. Then the engine (or menu) remapping should map this to whatever action is required.
[19:15] <-- dreammaster left irc:
[19:17] <Grogbot> <ccawley2011> @rsn8887 I had a go at implementing this a long time ago. I never finished it, but what I did can be found here if you're interested: https://github.com/ccawley2011/scummvm/tree/joystick-wip
[19:25] <Grogbot> <rsn8887> I see code for Pegasus I suppose something like this has to be done for every engine? What about the menu control remapping? Is the menu just another engine or is it special somehow?
[19:31] <Grogbot> <rsn8887> I see the engine stuff should be easy to do but lead to a lot of code duplication since almost all engines will react to the same controller_button events in the same way.
[19:31] <Grogbot> <ccawley2011> It's not necessary to add joystick mappings for every single engine. If an engine doesn't report that it supports joystick input, then ScummVM will simply use the default mapping.
[19:33] <Grogbot> <ccawley2011> Admittedly, there may still be duplication between engines that use similar control schemes, such as Kyra and Xeen, but that shouldn't be too many cases like that.
[19:35] <Grogbot> <SupSuper> i wonder if an action system would make sense for something like scummvm
[19:35] <Grogbot> <rsn8887> Theres no default mapping for game controller inputs atm because they are remapped to key events in the sdl backend.
[19:35] <Grogbot> <rsn8887> But I understand how it can work
[19:36] <Grogbot> <rsn8887> It will be much simpler than your code because game controllers dont have hat input etc, and the mouse is already cared for in the sdl backend.
[19:37] <Grogbot> <rsn8887> All I have to do is define the controller button down and up events and then add the mapping to inputdevicemanager and then add the default mapping to wherever the menu input mapping is done
[19:38] <Grogbot> <rsn8887> But every engine has its own inputdevicemanager so that will be a lot of code
[19:38] <Grogbot> <SupSuper> currently everything from backends to engines deals in raw events, with various conversion layers, mapping layers and more to try to retrofit whatever raw events the backend sends into something the engines expect (usually desktop-style events)
[19:39] <Grogbot> <rsn8887> The engine reporting joystick input support is not necessary. Since game controller events are always mapped to keyboard events, all engines will support controllers.
[19:40] <Grogbot> <rsn8887> Of course for some engines it will just be the standard mapping of dpad to keypad x to . etc.
[19:41] <Grogbot> <rsn8887> Is InputDeviceManager the standard interface to take the ScummVM common events and map them to engine specific stuff or keys used in EVERY engine? Or is each engine doing its own thing?
[19:42] <Grogbot> <rsn8887> Is _keymap present in all inputeventmanagers in all engines?
[19:42] <Grogbot> <SupSuper> every engine does its own thing
[19:42] <Grogbot> <rsn8887> Oh well, no thanks then 😃
[19:44] <Grogbot> <rsn8887> Is there a way from within SDL_EventManager to find out which engine is running and adapt the mapping there?
[19:45] <Grogbot> <rsn8887> We could define have all the mappings (and one default) there and choose the right one depending on the engine that is running.
[19:45] <Grogbot> <SupSuper> there seems to be a lot of duplicate code on scummvm on who does what regarding input. given the large scale of platforms , devices and engines scummvm supports now, a possible refactor might be to reduce input to events>mappings>actions. engines expose actions they use and do with as they see fit, like "CursorUp", "Inventory", "QuickSave", etc. backends convert their platform-specific events into standardized sdl input events. mappers
[19:45] <Grogbot> map any combination of input into an action
[19:45] <Grogbot> <rsn8887> That would be a minimal change to the existing PR.
[19:46] --> Littleboy joined #scummvm.
[19:46] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.
[19:46] <Grogbot> <SupSuper> this would avoid engines having to worry about specific input and having to be patched later for more devices, backends would only have to worry about standardizing their specific platform, and common mappers like mouse emulators, controller input, etc, could be generalized
[19:46] <Grogbot> <rsn8887> There are already standardized sdl events they are the ScummVM common events I think.
[19:47] <Grogbot> <rsn8887> The backend already concert internal events to those
[19:47] <Grogbot> <rsn8887> backends I mean
[19:48] <Grogbot> <rsn8887> The engines just respond to ScummVM common events already I think.
[19:48] <Grogbot> <rsn8887> So theres no problem. The only question is where the remapping should be done. I think I agree with Cawley that the best way to remap button inputs is within each Engine. So we can make it Engine specific
[19:50] <Grogbot> <rsn8887> My current approach was to do it in the sdl backend. Which would keep all mappings in a single place, which is also nice. Escpeciallynif in the future we want to allow a user definable custom remapping of buttons to keys. But I think this simpler approach relies on the backend being aware which engine is currently active.
[19:51] <Grogbot> <rsn8887> Since all engines support keys, I think the only thing to worry about is mappings from controller button to key event.
[19:51] <Grogbot> <rsn8887> Mouse and mouse buttons are already working great using controller in all engines
[19:53] <Grogbot> <rsn8887> Game controllers are already standaradised in sdl, so theres no ambiguity which button is x or y anymore.
[19:54] <Grogbot> <rsn8887> I think mapping non-SDL_gamecontrollers is useless Endeavour since each controller has different layout different button nr, different hat or no hat etc. I would leave that as is (kind of obsolete anyways)
[19:55] <Grogbot> <rsn8887> To support non-SDL_gamecontrollers, people would just have to download the latest controller db that works with sdl and or create their own entry to define their controller as sdl gamecontroller compatible input.
[20:03] <Grogbot> <Henke37> and then you get fun engines like scumm that give raw access to the user input to scripting.
[20:03] <Grogbot> <Henke37> want to know if the left mouse button is down? there is a var for that
[20:04] <Grogbot> <Henke37> or why not scroll the screen when the mouse cursor is close to the edge of the screen?
[20:05] <Grogbot> <SupSuper> my sentiment was more towards avoiding backends doing duplicate work and avoiding engines doing redundant work. looking at the issue of supporting window tablets, which is basically a "backend" which can simultaneously be a mouse/touch/controller/keyboard device, throwing every scummvm assumption out the window 😛
[20:05] <Grogbot> <SupSuper> and the user might wanna customize any of those
[20:12] <Grogbot> <rsn8887> I guess so. I guess the backend, SDL or not, should be able to queue GameController_Button_Down and Up events. Then the engine will respond to those. Then nothing is really tied to the SDL backend. It will just be the first one to be queueing those events.
[20:12] <Grogbot> <rsn8887> If some other backend decides to map events to keys directly, that would also still work.
[20:13] <Grogbot> <rsn8887> The button numbering for these events could follow thenSDL gamecontroller standard so we would now that button x would be the left button etc.
[20:13] <Grogbot> <rsn8887> Button A would be the bottom button
[20:14] <Grogbot> <rsn8887> Those could have numbers or better defined by an enum in common.h or wherever
[20:19] <Grogbot> <rsn8887> The only problem is the slow mouse modifier (currently R) and mapping In game menu event. I suppose this might be handled earlier but not sure
[20:24] <Grogbot> <rsn8887> I agree it requires a very close look at current input mapping but a quick first stab at a PR shouldnt be so hard. I will look at it later
[20:24] <Grogbot> <rsn8887> Thanks @ccawley2011 for the code
[20:24] <Grogbot> <rsn8887> Hint
[20:25] <Grogbot> <ccawley2011> @rsn8887 I've decided to have another go at implementing this. I'll let you know how I get on.
[20:25] <Grogbot> <rsn8887> Ok Perfect!
[20:27] --> dreammaster joined #scummvm.
[20:27] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[20:27] <Grogbot> <rsn8887> Id just request, since we have controlller input that works already quite well on Vita Switch and PSP (with analog deadzone and analog pointer speed setting etc), maybe make a PR so i can check whatever you do wont break existing functionality.
[20:29] <Grogbot> <rsn8887> And if it breaks something, at least I would have time to fix it for those platforms.
[21:01] <-- whiterandrek_ left irc: Ping timeout: 248 seconds
[21:01] <-- Deledrius left irc: Quit: App.Exit
[21:15] --> Deledrius joined #scummvm.
[21:46] <Grogbot> <peterkohaut> @everyone Blade Runners Needed! https://www.scummvm.org/news/20190616/
[21:46] <Deledrius> Hoooray!!!!
[21:46] <Grogbot> <sev> we already have keymapper
[21:47] <Grogbot> <sev> just it is not compiled on every platform, and was not finished to the very end
[21:47] <Grogbot> <sev> original idea was that the engine reports which keys it expects, and how they're called
[21:47] <Grogbot> <sev> and then the keymapper shows them on the screen
[21:48] <Grogbot> <sev> btw, an engine may have several layouts, and then switch between them
[21:48] <Grogbot> <sev> https://github.com/scummvm/scummvm/blob/master/gui/KeysDialog.cpp
[21:55] <-- ny00123 left irc: Quit: Leaving
[21:56] <Grogbot> <SupSuper> @sev does that work for any event or just keyboard keys?
[21:57] <Grogbot> <tsoliman> @SupSuper the idea is that all hardware events would be converted to regular events but there's currently no clear separation between both kinds of events
[21:59] <Grogbot> <tsoliman> imagine a world where all events generated in the backend would enter the event system as (for lack of a better name) HardwareEvent .. then go through whatever EventMapper is configured and be converted to (for lack of a better term) SoftwareEvent
[21:59] <Scummette> scummvm/master dbc0a5f rsn8887: SWITCH: Make direct touch (pointer jumps to finger) the default
[21:59] <Scummette> [scummvm] dreammaster pushed 6 new commits to master: https://git.io/fjalO
[21:59] <Scummette> scummvm/master 3acba22 dreammaster: GLK: FROTZ: Move creation of Quetzal ANNO chunk into base Quetzal writer
[21:59] <Scummette> scummvm/master 3876fb6 dreammaster: GLK: In progress transition to all sub-engines using Quetzal save files
[21:59] <Scummette> scummvm/master 553bb74 dreammaster: GLK: Further changeover of sub-engines to use new savegame code
[22:00] <Grogbot> <tsoliman> the thing doing the conversion (EventMapper) needs to know about both the available hardware events and the expected engine/whatever software events
[22:01] <Grogbot> <SupSuper> @tsoliman that's what i was thinking of when i mentioned events>mappers>actions
[22:01] <Grogbot> <tsoliman> KeyMapper is an early attempt at this - it doesn't explicitly handle keys only
[22:02] <Grogbot> <tsoliman> there's challenges with further implementing this (which is why I haven't done it) without breaking existing backends/frontends
[22:02] <Grogbot> <rsn8887> I think an Eventmapper should simply map all possible hardware events (not limited to currently active hardware)?!? So it only needs to know about all possible hardware events that could come in.
[22:02] <Grogbot> <tsoliman> (I use frontend and engine interchangably btw .. the GUI is a weird kind of backend)
[22:02] <Grogbot> <SupSuper> i was digging through the old touchmapper pr and it seemed to have some good ideas (exposing touch events to the gui etc) but also some pitfalls, like only one mapper can be in use
[22:03] <Grogbot> <rsn8887> The software events AFAIK are always mouse or keyboard, right, so that is also known?!?
[22:03] <Grogbot> <SupSuper> and again, more duplication of touch and mouse emulation which is probably in 10 different backends by now
[22:03] <Grogbot> <tsoliman> @rsn8887 not really
[22:03] <Grogbot> <tsoliman> an engine can decide that its events are "open inventory" rather than "tab"
[22:04] <Grogbot> <rsn8887> The only thing remaining is which possible hardware events to map to which possible keys or mouse events.
[22:04] <Grogbot> <tsoliman> further the backend itself can sometimes have software events
[22:04] <Grogbot> <rsn8887> Hmm but at some point currently those are already translated to keyboard
[22:04] <Grogbot> <tsoliman> this naming is crappy and confusing
[22:04] <Grogbot> <rsn8887> I dont understand the problem really. All engines can be controlled solely by mouse and keyboard.
[22:05] <Grogbot> <tsoliman> but engines aren't the only consumers of events
[22:05] <Grogbot> <rsn8887> All hardware events are: joystick, gamecontroller, touch, mouse, keyboard. Thats it
[22:05] <Grogbot> <rsn8887> So map from any hardware event to any mouse/keyboard event. In principle that should work.
[22:05] <Grogbot> <rsn8887> And is already done in sdl backend plus switch input backend
[22:06] <Grogbot> <rsn8887> However, that mapping is backend and platform dependent at the moment
[22:06] <Grogbot> <tsoliman> so for example, in the Maemo platform there's touchpad mode vs trackpad mode .. the backend itself listens to the outgoing events to be able to switch
[22:06] <Grogbot> <tsoliman> that way the user can decide what hardware action toggles modes
[22:07] <Grogbot> <tsoliman> so it isn't just engines as the only consumer
[22:07] <Grogbot> <rsn8887> I think that is fine... allow backends to do whatever they want.
[22:08] <Grogbot> <rsn8887> However in the engine, we need to map ALL possible hardware events. If the backend translates them before thats fine. But if not, then the engine should be able to deal with them on its own.
[22:08] <Grogbot> <tsoliman> right that's what the default event mapper does currently - it was a stepping stone to introduce that translation layer
[22:08] <Grogbot> <rsn8887> Eg if backend decides to map touch event to keyboard ok. But if not, Engine should respond to the touch events too
[22:09] <Grogbot> <tsoliman> it has some special rules but everything else is pass-through by default
[22:09] <Grogbot> <tsoliman> so for example, this will let the user pick and choose what key is used for things like "mouse capture toggle" and "fullscreen toggle" and so on
[22:10] <Grogbot> <rsn8887> It sounds good to me. Since @ccawley2011 said he would look into it, I hope with his insight that could be fixed. It think the only problem is the following: if backend does NOT map controller buttons to keyboard, it should pass on those events. The engine should then map them the best way possible.
[22:11] <Grogbot> <tsoliman> I think the engine shouldn't respond to the touch events before they pass through event mapper because then how would you implement special-function-touch areas in mobile?
[22:11] <Grogbot> <rsn8887> If you want user adjustable mapping I think thats a whole another can of worms. Theres currently nothing for that afaik.
[22:11] <-- _sev left irc: Quit: This computer has gone to sleep
[22:12] <Grogbot> <tsoliman> that was sev's point .. there is currently the keymapper which is a proto-state of what is possible .. it isn't enabled by default because it isn't robust 😃
[22:12] <Grogbot> <rsn8887> I am thinking the event mapper you talk about is done in the backend before the engine sees any event. So your touch zones can be implemented there.
[22:12] --> _sev joined #scummvm.
[22:12] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[22:12] <Grogbot> <rsn8887> Eg your touch zones would rest j side the Android backend.
[22:12] <Grogbot> <tsoliman> right this is one of those topics that requires knowledge (and confidence) in all parts of ScummVM not just engine or backend - which is why it hasn't been done for so long
[22:12] <Grogbot> <rsn8887> Then the engine wont see the touch events because the backend is translating them. If the backend doesnt, then it should pass the events on to the engine.
[22:13] <Grogbot> <tsoliman> I'm failing at explaining it 😦
[22:13] <-- _sev left irc: Client Quit
[22:13] <Grogbot> <tsoliman> the mapper layer isn't in the backend and it isn't in the engine - it is in between

[22:14] <Grogbot> <rsn8887> If the mapper layer is in between thats also fine.
[22:14] <Grogbot> <rsn8887> However it needs to act differently depending on engine. So basically it will have a different instance for each engine anyways.
[22:14] <Grogbot> <tsoliman> yeah the stuff I am describing is pretty conceptual and is about opinions about software design/architecture not what will or won't work 😃
[22:15] <Grogbot> <rsn8887> Each engine needs to instantiafe ita own mapper. The mapper can have defaults.
[22:15] <Grogbot> <ccawley2011> @tsoliman Is it possible to activate the keymapper on desktop platforms, or is it only available on specific platforms?
[22:15] <Grogbot> <rsn8887> I think this is already done.
[22:15] --> _sev joined #scummvm.
[22:15] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[22:15] <Grogbot> <tsoliman> @ccawley2011 yeah just enable it at configure time and then press its shortcut (F8?)
[22:16] <Grogbot> <tsoliman> @ccawley2011 it is on-by-default on some platforms (at least maemo) but not on by default on most
[22:16] <-- _sev left irc: Client Quit
[22:19] <-- Littleboy left irc: Ping timeout: 246 seconds
[22:20] <Grogbot> <tsoliman> I made it so that when the KeyMapper is compiled out, then there is still an EventMapper layer, it is just filled with the default mapper - this allowed the special default keys to be handed in it rather than all over the place
[22:20] --> _sev joined #scummvm.
[22:20] #scummvm: mode change '+o _sev' by ChanServ!ChanServ@services.
[22:25] <Grogbot> <tsoliman> just realized that discord is being mirrored to IRC
[22:26] <Strangerke> This works in both directions
[22:27] <Grogbot> <Henke37> for some definition of "works"
[22:27] <Grogbot> <Henke37> irc certainly isn't going to see any avatars
[22:28] <Grogbot> <SupSuper> inb4 someone says "that's a feature"
[22:28] <-- m_kiewitz left irc: Quit: technology isn't intrinsically good or evil. It's how it's used. Like the Death Ray.
[22:31] <Grogbot> <ccawley2011> OK, here's what I've got so far: https://github.com/ccawley2011/scummvm/tree/joystick
[22:34] <tsoliman> I like this mirroring. Discord doesn't think I'm a dev.
[22:34] <tsoliman> Those are two unrelated statements.
[22:35] <Grogbot> <Henke37> well, come over to this side and the second issue can be remedies
[22:36] <Grogbot> <tsoliman> here I am on this side
[22:37] <Grogbot> <Henke37> that was quick
[22:49] <Grogbot> <rsn8887> How do you cause a joystick button to bring up the ScummVM menu?
[22:49] <Grogbot> <tsoliman> @peterkohaut You may want to change the ADGF flags on the detection table to ADGF_TESTING for blade runner entries
[22:49] <Grogbot> <Henke37> do a 180 degree turn while holding the third button and pressing the second button exactly two times
[22:50] <Grogbot> <rsn8887> Also I would probably rename JOYSTICK to GAMECONTROLLER or CONTROLLER or GAMEPAD because modern controlllers have a left and right joystick.
[22:50] <Grogbot> <Henke37> except when they don't.
[22:51] <Grogbot> <Henke37> the wii is a supported platform and it has the wii remote which has no joysticks at all without extensions
[22:52] <Grogbot> <SupSuper> controller is probably the universal term, and consistent with sdl2
[22:57] <Grogbot> <tsoliman> 😃
[22:58] <Grogbot> <tsoliman> I've successfully excluded grogbot from my bouncer's notifications - so much spam was happening when I discord
[23:02] <Grogbot> <SupSuper> thanks for the tip, i was wondering if that was possible
[23:08] <Scummette> [scummvm] tsoliman opened pull request #1668: BLADERUNNER: Switch to ADGF_TESTING (master...bladerunner) https://git.io/fja8f
[23:09] <Grogbot> <tsoliman> wow .. failure to realize the template was literally in the text box
[23:23] <-- criezy left irc: Quit: criezy
[23:24] <-- ludde left irc: Ping timeout: 258 seconds
[23:52] <-- ccawley2011 left irc: Quit: Page closed
[00:00] --- Mon Jun 17 2019