ScummVM IRC Log - 02 Dec 2017

[Back to Index]

[00:21] <snover> for whatever reason i totally forgot how awful the other desktop platform buildbot builds are also going to be. whoops. well, sorting those in the new buildbot is the next thing on my list as soon as i unwind some stuff from my working branch from the last couple of days.
[00:21] <snover> then i guess i will write some release news draft to get that out of the way and ready.
[00:24] <criezy> There is still some time before release. But I guess it's better to get it done early that too late. ;)
[00:26] <snover> https://github.com/scummvm/scummvm/commit/ea0fb987e042a86b8da683cafa7b9cf04d1636e6 ???
[00:28] --> dreammaster joined #scummvm.
[00:28] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[00:28] <dreammaster> Has anyone else noticed that logs.scummvm.org is down? I can't exactly check the channel logs to find out if it's already been noticed or not :)
[00:29] <snover> Endy: fix it. ^
[00:29] <criezy> I would be worried about the code that was using NULL strings if the fix was just to sweep it under the carpet...
[00:29] <snover> exactly, invoking anything on a null object is UB
[00:30] --> vv221 joined #scummvm.
[00:30] <-- vv221 left irc: Client Quit
[00:30] <snover> clang was warning about this a while ago when i did a build with all engines enabled, i removed it and didnt look until now where it came from
[00:30] <-- vv222 left irc: Ping timeout: 250 seconds
[00:31] <snover> null pointer*
[00:33] --> Mataniko joined #scummvm.
[00:34] <criezy> Interestingly LeChuck is still in the chanel, so maybe it is still being logged, and only the server to access the logs is down.
[00:34] <snover> this seems fine.
[00:35] <dreammaster> Well, that's something, at least
[00:37] <snover> dreammaster: we only badmouthed you a little bit since the last time you were here, dont worry about it
[00:40] <dreammaster> Pshaw. That's okay, then :)
[00:43] <-- Farmboy0 left irc: Remote host closed the connection
[00:43] <snover> it really is turning into a bad month for the bots. githubbot is flaking out constantly now.
[00:44] <dreammaster> Agreed. I hardly ever see my commits listed in channel anymore
[00:47] <snover> lets just do a quick check of the banlist to make sure someone didnt accidentally ban some of the github bots&
[00:48] <criezy> snover: I supposed you included the SCI commit by mistake in that PR to revert the wage commit?
[00:48] <dreammaster> Heh. It'd be amusing if that turned out to be the case
[00:48] <snover> criezy: whoops, yes i did. watch as i miraculously fix it by commiting the sci commit to master though :)
[00:48] <Deledrius> The bots are quietly going to meetings where they are planning their uprising.
[00:49] <Deledrius> Makes them late for work.
[00:49] --> GitHub41 joined #scummvm.
[00:49] <GitHub41> [scummvm] csnover pushed 1 new commit to master: https://git.io/vbmPp
[00:49] <GitHub41> scummvm/master 57db3f7 Colin Snover: SCI: Partially clean up SCI16 video playback code
[00:49] GitHub41 (GitHub41@192.30.252.45) left #scummvm.
[00:49] <criezy> That's at least one bot that is neither banned nor participating to the uprising meeting.
[00:50] <criezy> Unless that meeting has already finished.
[00:51] <snover> it would also be useful if someone with admin access to the scummvm org could check the hooks to make sure theres not some big flashing red light that says there is some configuration problem or this hook is outdated or& something
[00:51] <criezy> That commit to master had an interesting effect on the PR: I still see the SCI commit, but now I see two commits to revert the WAGE one.
[00:52] <snover> hit reload :)
[00:52] <criezy> Oh, refreshing the page fixed that. Now I only see one commit to rever the wage commit (and the SCI commit is gone)
[00:52] <snover> the live-updating ui doesnt always live-update &good
[00:53] <criezy> Yep. I noticed that.
[00:56] <snover> i found two mentions on twitter from users complaining about the irc webhooks timing out
[01:16] <rsn8887> I found an extremely simple fix for the gui on Vita that was distorted when AR was enabled. Shall I just push directly to master?
[01:16] <snover> rsn8887: is it in vita backend code or GUI code?
[01:16] <rsn8887> Only Vita backend.
[01:16] <snover> you may do that, you may also send it via PR if you want feedback.
[01:16] <snover> or are unsure about it in some way.
[01:17] <rsn8887> it is just 3 lines or so so I will push it directly after testing some more on my Vita. Thanks.
[01:17] <snover> even a one line fix is worth making a pull request if you are unsure about it.
[01:18] <rsn8887> True :)
[01:19] <tsoliman_> the gcc5 maemo cross compiler is actually resulting in smaller stripped binaires than the "official" ancient one ... 24.5MB (without titanic) vs 20MB (with titanic)
[01:19] Nick change: tsoliman_ -> tsoliman
[01:20] <tsoliman> it's almost as if newer software is better or something
[01:26] <snover> tsoliman: -Os?
[01:26] <tsoliman> both yeah
[01:27] <tsoliman> it isn't apples to apples because of different sha1s .. so I am redoing the test now
[01:27] <snover> one of the upcoming patches i have for the build scripts is to replace -O2/-O3 with -Os
[01:27] <tsoliman> even for desktops?
[01:27] <snover> yes. there is basically no system which does not benefit.
[01:27] <snover> smaller code = more fits in cache = faster
[01:28] <tsoliman> I remember on my old linux laptop (dual core 800-1800mhz) munt would really hate it without -O2/-O3 in certain build configs .. but that's comparing no optimization with -O2/-O3 rather than vs -Os
[01:29] <snover> modern cpus are so fast and have good branch prediction so that, as a general optimisation strategy, the worst thing you can do create more code so more stuff gets pushed out of cache and it has to stall requesting data from main memory
[01:29] <tsoliman> yep .. my nokia n810 ran like crap with -O3 (single core 400mhz ARM)
[01:29] <tsoliman> -Os was the only way to go on that platform
[01:30] <tsoliman> it also took ages to compile with -O2/-O3 compared to -Os but that's because of stupid layers of emulation .. scratchbox *shudder*
[01:30] <tsoliman> my top TODO item right now is to get android to not suck
[01:31] <snover> oh shit, yours too? :)
[01:31] <snover> well lets do this together then!
[01:31] <tsoliman> :D
[01:31] <tsoliman> I'm a java guy in my dayjob but I've never developed for android .. I figure why not start now
[01:32] <snover> (i actually have to do some release and buildbot stuff thats more urgent first, so please get a head-start!)
[01:32] <snover> theres stuff on branch-1-9-0 for androidsdl that im not sure if it actually got landed into master, so that was near the top of my list of things to look at
[01:32] <snover> since people keep talking about this mystical 1.9.0.1 build that has everything working
[01:32] <tsoliman> :D
[01:32] <snover> i have no idea if that build was android or androidsdl. one of them has to die.
[01:32] <snover> we should not be maintaining two backends for one port.
[01:33] <tsoliman> I want to just have the 640 theme for a start ... so I can actually use it properly
[01:33] <snover> whats wrong with 320x200 blown up to 4K with no filtering? it looks FINE OK
[01:33] <tsoliman> I also need to set up a toolchain that isn't "cheating"
[01:33] <snover> tsoliman: use the buildbot worker images, thats (kind of) what theyre there for.
[01:34] <tsoliman> nice .. that was my cheat in 2012
[01:34] <snover> https://github.com/csnover/scummvm-docker / https://hub.docker.com/r/scummvm/buildbot-android
[01:35] <tsoliman> I wonder if I should dockerize the gcc5 maemo
[01:35] <tsoliman> and then finally have a buildbot .. just in time for it being super obsolete
[01:35] <snover> yes, you should, as i plan on trying to force all the porters to give these moving forward
[01:36] <tsoliman> can it contain arbitrary blobs or does it have it buildable from a dockerfile?
[01:37] <snover> ideally it would be buildable, its up to you. it doesnt matter to me one way or another, as long as its up-to-date and meeting all the build requirements.
[01:39] <snover> theres some urgency to getting the buildbot situation resolved since vm2 keeps running out of disk space during builds so this distributable system needs to get going. after that im going to do a better job of clearly communicating my desires and plans moving forward.
[01:40] <tsoliman> requires: Some patience :D
[01:41] <snover> docker is great, and boy do you spend some time sitting around when youre getting all the dependencies to build right. at least the support script for building libraries is pretty mature now so it isnt going to fail on you all the time like it did when i was working on it.
[01:45] <rsn8887> BTW: Did Lucasarts Adventures ever really look like they do with AR on? I know that at least on my Amiga back then, they never filled out the full vertical screen like that. I seem to remember even on PC, there was usually a black border on the bottom...
[01:46] <tsoliman> snover: this docker image is gonna be slightly different for now .. the toolchain requires Debian 8 "jessie" (the latest is 9) .. that's better than trying to create a container off of old Debian 5/6 .. I hope you're ok with doing it that way for now and then maybe eventually doing it "right" ... I figure delivering value first and then making it future proof later is a good iterative sort of approach
[01:46] <tsoliman> which game specifically (as an example), rsn8887
[01:47] <snover> tsoliman: yes, thats ok for now, youll have to perform some extra gymnastics since fakeinit (or whatever its called) isnt packaged for 8
[01:47] <rsn8887> tsoliman: I am thinking of Monkey Island 1 on the Amiga. I think it always had a black empty bar at the bottom of the screen.
[01:49] <snover> the biggest problem with that is that docker images are layers, so N images can use the same base image and it only takes up 1 base images worth of disk space. if one port is using some outdated base image thats not a big deal, but if 8 different ports are using 8 different outdated base images then were using up an extra gig of space for nothing
[01:49] <tsoliman> rsn8887: I remember our CRTs were always adjustable .. so you'd stretch them however you wanted for a given resolution
[01:49] <snover> well there was the inventory/action bar at the bottom&
[01:49] <tsoliman> snover: right .. unionfs it used to use back in 2015
[01:51] <tsoliman> rsn8887, I'd look at a game like full throttle or similar because it is truly fullscreen
[01:52] <criezy> With that shake commit I am now wondering what happens when loading a save game while the shake offset is not 0...
[01:52] <tsoliman> snover I don't know what the free space is like .. or even what the hosting is
[01:52] <snover> dreamweb is the only game i am aware of that uses 320x200 with a 1:1 PAR. i do not know much of amiga so it is possible the amiga ports also used a 1:1 PAR, if that was a thing that amigas had to do
[01:53] <tsoliman> I dunno .. I just always adjusted the CRTs whenever they didn't "fill"
[01:53] <snover> criezy: yeah, i thought about that too. i thought i did a good job of testing that and i just realised i actually did a crummy job of testing that :)
[01:54] <snover> i tested to make sure that upon loading a save game the shake didnt build up on itself, and i didnt actually check that loading a save game that wasnt shaking would reset the shaking
[01:54] <snover> im not sure there is a generalisable solution for that problem
[01:54] --> ignalina joined #scummvm.
[01:54] <rsn8887> I cannot find a good video of somebody playing on an actual amiga monitor. But since they were setup to display 320*256 in Europe, any game showing 320*200 had a big black bar. The screenmode did not switch between 320*256 and 320*200 it was just a smaller game screen on the Amiga.
[01:54] <snover> it would be nice if there was a little more event-driven design going on so that there was an automatic notification about a save restore.
[01:55] <criezy> I just tested that loading a non-shaking save game in DOTT does reset the shaking.
[01:56] <snover> ok, good. sci32 might be broken in that way, though unless QFG4 does something weird (this is possible, it is the only sci32 game that also uses *horizontal* shake) its less likely to be seen since shakes are otherwise short and transient so it would be possible, and unlikely, for someone to try to load during a shake.
[02:07] <snover> is there some thing not as heavyweight as valgrind that gcc users can use to automatically detect coding errors during development? the clang sanitizers have been amazing and id like to be able to provide suggestions for folks that dont use clang. i know vaguely of Application Verifier for folks using Visual Studio, and nothing in particular for gcc.
[02:07] <snover> maybe i should just proselytise for clang instead :)
[02:10] <-- criezy left irc: Quit: criezy
[02:11] <tsoliman> I am transferring titanic gamedata over to the n810 .. snover what's your prediction? Will it blend?
[02:11] <tsoliman> the "latest" game I ran on there was SQ6
[02:14] <tsoliman> it had a lot of trouble with mohawk not having dirty rectangle (full screen refreshes every frame?) ... so unless titanic has that too, there's a chance it would be playable maybe
[02:15] <snover> well, most of the screen changes every frame during transitions because its a big ole movie, so.
[02:15] <tsoliman> I mean I used to play youtube on it .. so I am not sure what mohawk's problem was .. the audio thread was just lagging
[02:16] <tsoliman> *cough* single core *cough*
[02:16] <snover> at your own risk, i guess.
[02:18] <-- ignalina left irc: Quit: ignalina
[02:18] <snover> man, i am just all over the place tonight.
[02:22] <tsoliman> I started building images before creating a secrets.cfg .. am I in trouble?
[02:22] <tsoliman> I hope secrets.cfg is only used when running the container
[02:22] <snover> secrets.cfg is used only by the buildmaster
[02:25] <tsoliman> shouldn't we have some kind of artifact repo to store the built images in? that way people won't have to "compile from source" the containers so to speak
[02:25] <snover> there is. i gave it to you. you dont have to build all the images yourself.
[02:25] <snover> hub pull scummvm/buildbot-whatever:latest
[02:25] <snover> er
[02:25] <snover> docker pull*
[02:25] <tsoliman> facepalm
[02:25] <snover> if you run docker-compose up, it will auto-pull too, so you dont even need to pull.
[02:26] <snover> i will make this extra clear in the readme. i tried to excise this old information and apparently was not entirely successful.
[02:26] <-- Dominus left irc: Ping timeout: 260 seconds
[02:26] --> Dominus joined #scummvm.
[02:31] <tsoliman> nope it was my fault .. I would leave it as it is now
[02:32] <snover> if you are working on android you will also need to make sure to use my master and/or buildbot branch (they are currently the same for the sake of testing this thing)
[02:33] <snover> since a lot of the configure setups are just broken for newer toolchains
[02:33] <snover> android is no exception
[02:36] <-- Joefish left irc: Ping timeout: 258 seconds
[02:36] <tsoliman> ok so how do I disable all workers except for android (I don't want to pull all of them) .. edit the yml file?
[02:36] --> Joefish joined #scummvm.
[02:36] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[02:37] <snover> you may just run `docker-compose up -d buildbot-android`
[02:54] <tsoliman> is it ok if I "start a manual build" from my local buildmaster?
[02:54] <tsoliman> I want to make sure that I don't affect the world outside my machine :)
[02:54] <snover> yep, do whatever you want, you cannot affect anything anywhere else
[02:55] <snover> i appreciate your caution.
[02:56] <tsoliman> hmm I am not authorized .. I need to login .. basic auth
[02:57] <snover> user/pass
[02:58] <tsoliman> thanks!
[02:58] <snover> 53cUre
[02:59] <tsoliman> well I tried admin/admin and admin/password first and then gave up so it beat my supersekritpasswordskillz
[03:04] <tsoliman> build failed .. linker errors .. hmm
[03:04] <tsoliman> kyra and sherlock
[03:09] <snover> not sure what might have broken in that regard, havent tried running a full build for a bit.
[03:11] <rsn8887> I have a strange bug on Vita with Phantasmagoria Demo. I think it is related to that particular game's strange resolution. Screenshots are here: http://forums.scummvm.org/viewtopic.php?t=14394
[03:11] <rsn8887> Could it be that there is something special going on to allow other ports of ScummVM to render that particular game correctly?
[03:12] <rsn8887> I mean the resolution is 630x450. No clue why that would pose a problem in SurfaceSDL with SDL2.
[03:13] <snover> it doesnt pose a problem on desktop
[03:15] <snover> its possible that there is some additional memory padding on that platform and this game is just exposing a bug in the backend where it is ignoring the stride of the rows so is drawing the new line staring in the padding area
[03:16] <snover> starting*
[03:17] <snover> maybe someone knows of another game that uses a non-multiple-of-8/16 width
[03:21] <snover> in any case, i am pretty sure that is going to be the bug, i just dont know whether thats a bug in SDL or a bug in the SDL backend or a bug in the Vita backend
[03:26] <-- dreammaster left irc:
[03:41] <snover> tsoliman: i just pushed an update to the readme which contains a section about using workers as stand-alone compilers, which you may be interested in.
[03:41] <tsoliman> nice
[03:42] <tsoliman> I am brushing off my 2 year old docker skills
[03:42] <tsoliman> things have moved on with docker-compose since 2015 but a lot of stuff still applies
[03:42] <-- Joefish left irc: Ping timeout: 240 seconds
[03:42] <snover> it is better now too :)
[03:43] <snover> https://github.com/csnover/scummvm-docker/#using-workers-as-stand-alone-compilers is the section.
[03:44] <snover> im still fighting non-containerised-service fatigue where i think that sounds too complicated and risky to actually test quickly and then have to remind myself that it is both trivial and risk-free
[03:45] <snover> like with this section, i thought i wouldnt bother to actually test it because that sounded like a hassle
[03:45] <snover> and then remembered it is easy so did.
[03:54] <rsn8887> snover: how often is each Dockerfile executed? Is it just a single manual execution, or automatic for every build?
[03:58] <snover> Dockerfiles are used to build Docker images in the same way that a Makefile is used to build an executable. you only use them when you are building updated service images.
[03:59] <snover> so if you are updating the OS or the compiler for a worker, then you use the Dockerfile.
[03:59] <rsn8887> There's libflac for Vita which would be great to link.
[03:59] <rsn8887> But it seems to be missing. I have no experience with docker, but I have the build instructions that I used on the old buildbot.
[04:02] <rsn8887> it is this: https://pastebin.com/J7DsuELM
[04:02] <snover> yeah, i know, i had to reference the stuff on the old buildbot to get a working vita compilation.
[04:03] <rsn8887> Most of the dependencies are there. It seems only libflac is missing from your Docker file, and freetype2 might complain about that missing freetype config.
[04:03] <rsn8887> But flac is kind of important because it is very common.
[04:04] <snover> it is? as far as i know the only thing flac is optionally used for is as a compression format for cd-audio games
[04:04] <snover> i dont think there is any engine that has a dependency on flac
[04:05] <rsn8887> I mean common among users it is often used as a compression. I compressed many games with it myself. Anyways it wouldn't hurt to include libflac. THe old buildbot has it I think. And I think the commands under #flac in the pastebin should work verbatim to get libflac for vita to run.
[04:06] <rsn8887> run -> link
[04:06] <snover> there may or may not have been a reason why it did not get used
[04:06] <snover> please go ahead and figure out why :)
[04:09] <rsn8887> snover: has this new buildbot already been building the daily builds, or is currently still the old buildbot?
[04:09] <snover> old one.
[04:21] <-- dafioram left irc: Quit: Leaving
[04:33] <tsoliman> snover: the docker image is 789MB and counting :(
[04:33] <tsoliman> the maemo cross compiler - because it is based on debian:8
[04:33] <tsoliman> do we have a spare GB of space?
[04:34] <snover> no, and we will once we can split the workers across multiple machiens.
[04:36] <-- SylvainTV left irc: Read error: Connection reset by peer
[04:36] <tsoliman> I think I will keep this docker image instead of VMWare :)
[04:36] <snover> the other images range in size between 421MiB and 2.45GiB
[04:37] <snover> so 789 is like&pretty average.
[04:38] --> macdude22 joined #scummvm.
[04:39] <tsoliman> well debian:8 is only 123MB
[04:39] <tsoliman> so most of the space is actually the maemo rootstrap
[04:41] <tsoliman> the VMWare image is 3.8GB even though it is just the base debian8 install (no gui) & the toolchain & the scummvm tree - I guess the docker images are pretty barebones
[04:42] <snover> yes, intentionally so
[04:42] <snover> hm, my source for the iOS 7.1 SDK has apparently been deleted from GitHub and all the other ones are newer.
[04:42] <snover> guess ill be building that myself&
[04:43] <snover> and probably splitting the macos and ios buildbots so i can deal with these independently
[04:44] <tsoliman> s/GitHub/Dockerhub?
[04:44] <snover> no
[04:44] <snover> github
[04:45] <snover> supporting old systems is really burdensome and annoying.
[04:45] <tsoliman> I am actually debating splitting maemo and maemo-gcc5 (naming things is hard)
[04:47] <tsoliman> right now I am just editing stuff in-place in a branch to get it to work .. I'll be glad to get rid of the stupid workarounds
[04:49] <snover> xcode 9 does not even allow an ios deployment target lower than 8.0
[04:50] --> Joefish joined #scummvm.
[04:50] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[04:50] <snover> and since they ended support this year, i imagine xcode 10 will support nothing lower than ios 9
[04:50] <tsoliman> yeah - in theory you can make a VM of OS X Yosemite and install XCode 7 on it
[04:51] <snover> everything is doable in theory, and i have a long list of things that need to get done and theres only one of me
[04:52] <tsoliman> let's just say that most people who have ios devices don't have macs
[04:52] <snover> most people dont compile software
[04:53] <tsoliman> very true
[04:54] <tsoliman> I was one of the people who had access to windows/linux and a few ios devices and no way to compile scummvm without cross compiling to ios from linux .. that would be the ios backend not ios7
[04:54] <tsoliman> I guess the question I am asking is .. is the ios7 backend for xcode only?
[04:56] <tsoliman> wow .. I underestimated how bare the docker images were
[04:56] <tsoliman> /lib/ld-linux.so.3: No such file or directory
[05:01] <snover> thats not a bareness issue, thats a debian is multiarch, things dont exist in /lib issue
[05:01] <snover> and/or a this is a 64-bit linux image issue
[05:02] <snover> it would be hard to do anything without a dynamic linker, after all
[05:03] <snover> if the compiler needs a 32-bit version then you will need to use a 32-bit image
[05:03] <snover> 32-bit OS version*
[05:03] <snover> anyway, good luck. im grumpy now so i am going to leave and relax and go to bed :)
[05:06] <tsoliman> yep it was a missing "make" (and the rootstrap's make took over)
[05:06] <tsoliman> thanks for all the help snover :)
[05:06] <snover> yes, thank you for your help with the android
[05:06] <snover> grr android grr.
[05:07] <snover> i just saw a meteor so im feeling suitably humbled now. leaving now, really. good night!
[05:08] <tsoliman> good night :)
[05:29] <-- Joefish left irc: Ping timeout: 250 seconds
[05:33] <-- |Cable| left irc: Ping timeout: 240 seconds
[05:35] --> Joefish joined #scummvm.
[05:35] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[05:46] --> |Cable| joined #scummvm.
[06:02] <-- Mataniko left irc: Quit: Connection closed for inactivity
[06:11] <rsn8887> building scummvm in docker sure takes a while
[06:34] <-- kurtwr2 left irc:
[06:36] --> kurtwr joined #scummvm.
[07:16] <tsoliman> the n810 actually ran titanic .. color me surprised
[07:27] --> ajax16384 joined #scummvm.
[07:27] #scummvm: mode change '+o ajax16384' by ChanServ!ChanServ@services.
[07:31] <rsn8887> Nice! is there a help file for configure I need to disable all engines but one...
[07:40] <tsoliman> rsn8887: --disable-all-engines --enable-engines=engine1,engine2,....
[07:40] <rsn8887> Ah now I remember. Thanks. Sadly, the new buildbot-generated vita executable crashes on launch. The old buildbot is fine... so I need to debu
[07:40] <rsn8887> g
[07:42] <tsoliman> you might want to disable all engines until you fix the crash on launch ... that way the build goes faster
[07:42] --> Strangerke_ joined #scummvm.
[07:43] <tsoliman> it's 1:45 AM here .. good night and good luck :)
[07:44] <-- Strangerke left irc: Ping timeout: 248 seconds
[07:44] Nick change: Strangerke_ -> Strangerke
[07:56] <rsn8887> good night
[08:03] <-- Asterisk_ left irc: Ping timeout: 240 seconds
[08:06] --> Asterisk joined #scummvm.
[08:18] --> ignalina joined #scummvm.
[08:21] --> Begasus joined #scummvm.
[08:28] --> Begas_VBox joined #scummvm.
[08:30] <-- Begas_VBox left irc: Client Quit
[08:31] --> Begas_VBox joined #scummvm.
[08:32] --> jamm joined #scummvm.
[08:32] <-- jamm left irc: Changing host
[08:32] --> jamm joined #scummvm.
[09:01] <-- Joefish left irc: Ping timeout: 240 seconds
[09:06] <-- LittleToonCat left irc: Remote host closed the connection
[09:08] <-- Begas_VBox left irc: Quit: Vision[0.10.2]: i've been blurred!
[09:11] --> Begas_VBox joined #scummvm.
[09:13] --> Joefish joined #scummvm.
[09:13] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[09:38] --> Strangerke_ joined #scummvm.
[09:40] <-- Strangerke left irc: Ping timeout: 248 seconds
[09:40] Nick change: Strangerke_ -> Strangerke
[10:16] --> nast joined #scummvm.
[10:17] --> waltervn joined #scummvm.
[10:17] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[10:22] <-- nast left irc: Remote host closed the connection
[10:36] <-- Begas_VBox left irc: Quit: Vision[0.10.2]: i've been blurred!
[10:58] <-- Joefish left irc: Ping timeout: 250 seconds
[11:12] <wjp> whee, new mouse
[11:13] <wjp> very nice to be able to switch cursors reliably again in SCI :-)
[11:23] <waltervn> what did you end up getting?
[11:24] <wjp> cheap logitech
[11:24] <wjp> seems fine, although the amount of friction on the scroll wheel is going to take some getting used to
[11:25] <wjp> (it's the ... B100)
[11:34] --> Begas_VBox joined #scummvm.
[11:36] <-- Begas_VBox left irc: Client Quit
[12:05] --> Begas_VBox joined #scummvm.
[13:15] --> dafioram joined #scummvm.
[13:35] --> criezy joined #scummvm.
[13:35] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[13:52] <waltervn> Am I pendatic for wanting a "PC Booter" platform?
[13:53] --> Joefish joined #scummvm.
[13:53] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[13:53] <logix> I'm not sure if "pedantic" is the right term
[13:54] --> Farmboy0 joined #scummvm.
[13:54] <-- Farmboy0 left irc: Changing host
[13:54] --> Farmboy0 joined #scummvm.
[13:54] <logix> weird or eccentric perhaps :)
[13:57] <waltervn> right, *pedantic
[13:57] <logix> err, wait... you mean for things like the black cauldron pc booter
[13:57] <waltervn> right
[13:58] <logix> I thought you meant a "bare metal x86" version of scummvm, i.e., an image that you boot and that doesn't run a standard OS
[13:58] <waltervn> or like Adventure in Serenia that I'm working on now. There's no DOS here, but I guess that's the closest platform to assign it.
[13:58] <logix> ok, then "pedantic" suddenly makes more sense - but no, I see nothing wrong with it
[14:03] <logix> technically something like "x86 bios" might be the underlying "platform" the game runs on
[14:05] <waltervn> right, but I think "PC Booter" or something like that is a little more... hmm.. user-friendly?
[14:05] <logix> true
[14:06] <waltervn> I wonder how many booters we support right now, at least a couple I believe
[14:07] <logix> I just realized that PC booter games won't run on future raw hardware once legacy bios is phased out - I think intel will stop supporting it in 2020 or so
[14:07] <logix> not that it's relevant in practice, I only mean that this just occurred to me
[14:08] --> ccawley2011 joined #scummvm.
[14:09] <logix> waltervn: other booters? do you mean things like amiga versions?
[14:10] <waltervn> no, just wondering how many PC booter games we support at the moment
[14:10] <waltervn> if it's more than 1 or 2 that might strengthen my case ;)
[14:10] <logix> oh, right
[14:11] <waltervn> but yeah, I guess for Amiga there's a similar situation, but our platform there is "Amiga", not "Workbench"
[14:14] <waltervn> I'm not overly familiar with the Amiga boot process though
[14:14] <logix> https://en.wikipedia.org/wiki/List_of_PC_booter_games - at least black cauldron, donald duck's playground, KQ1, KQ2, troll's tale
[14:15] <logix> I mean - those are games that scummvm supports and that exist as PC booter versions
[14:15] <logix> I don't know if you can play the PC booter version in scummvm (how does that work, do you have to extract the files first - how does *THAT* work?!)
[14:15] <waltervn> well, usually there are no files
[14:16] <waltervn> so you need to point scummvm to a disk image instead
[14:16] <logix> right, "files" was a bit of a misnomer
[14:17] <waltervn> black cauldron booter needs bc-d1.img and bc-d2.img for example
[14:17] <waltervn> and then all the "file" reading is done by scummvm internally
[14:18] <waltervn> I don't know how AGI does things, but in ADL there are disk/sector/offset tuples that point to data blocks
[14:19] <waltervn> or disk/track/sector/offset
[14:19] <waltervn> there's no custom filesystem or anything like that in ADL
[14:41] <logix> right, something like that was my other guess
[14:56] <Lightkey> there is a "Making of Tex Murphy Documentary & Special Event" with streamer and Tesla Effect developer ChronoWolf at 20 UTC on twitch.tv/gogcom
[15:04] <-- Begasus left irc: Quit: Ex-Chat
[15:04] --> Begasus joined #scummvm.
[15:21] --> Littleboy joined #scummvm.
[15:21] #scummvm: mode change '+o Littleboy' by ChanServ!ChanServ@services.

[15:38] <-- Joefish left irc: Ping timeout: 255 seconds
[16:22] --> Joefish joined #scummvm.
[16:22] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[16:27] <-- Joefish left irc: Ping timeout: 258 seconds
[16:37] --> SylvainTV joined #scummvm.
[16:37] #scummvm: mode change '+o SylvainTV' by ChanServ!ChanServ@services.
[16:45] <-- Begas_VBox left irc: Quit: Vision[0.10.2]: i've been blurred!
[16:46] <-- Begasus left irc: Quit: Ex-Chat
[16:57] <waltervn> great, another Cranston Manor auction popped up.. https://www.ebay.com/itm/Cranston-Manor-Sierra-On-Line-Systems-Apple-II-small-color-folder-version/132419705304
[16:57] <waltervn> only $550 this time, and bonus, it's partially working
[16:59] <logix> hm, what about that other one, $250
[17:00] <logix> the seller doesn't specifically say that the disk works *now* however...
[17:02] <logix> I mean https://www.ebay.com/itm/331792889376
[17:08] --> LittleToonCat joined #scummvm.
[17:22] <dafioram> tsoliman: the last android stable version, 1.9.0.1, was created after work from lubomyr, it uses android-sdl. See PR758, and PR829 which have both been merged. I don't see a "Control" tab in 1.9.0.1 which PR905 would of added, which would allow for the touch pad mode, direct vs. touchpad to be specified.
[17:37] <rsn8887> I fixed Phantasmagoria on Vita port. pushing commit...
[17:43] --> Joefish joined #scummvm.
[17:43] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[17:44] --> ny00123 joined #scummvm.
[17:55] <rsn8887> done
[18:02] <-- dafioram left irc: Quit: Leaving
[18:02] <wjp> what mode was it trying to set?
[18:05] <snover> its 630x450. i question whether this is a correct fix since the system is just returning a texture with a pitch larger than the width
[18:05] <snover> hacking the width to match the pitch doesnt fix the problem that the code is ignoring the pitch
[18:08] <snover> PSP2SdlGraphicsManager::SDL_SetVideoMode is also just leaking whatever memory SDL already allocated for the surface
[18:10] <snover> oh no, sorry, it is storing those before it replaces the pointer
[18:12] <snover> my original comment about the pitch still applies though, you cant just replace the pixels of a surface once it has been allocated without making sure the rest of the struct is valid for the newly allocated pixels
[18:12] <snover> memory
[18:13] <snover> all this change is doing is making sdl allocate more pixel memory so that it happens to align with the pitch of the pixel data returned by vita2d_create_empty_texture_format
[18:14] <wjp> s/more/less/ ?
[18:15] <snover> er, yeah. i should not try to pay attention to two things at once.
[18:15] <wjp> that would also mean adjusting the height is pointless?
[18:16] <snover> so this is also clipping off the right edge i guess?
[18:16] <snover> right and bottom edges.
[18:16] <snover> i would assume so
[18:17] <snover> i mean, i am just hypothesising since i dont have a vita to actually look at, but i am pretty sure this is what is going on.
[18:17] <snover> rsn8887: are you reading this?
[18:19] <rsn8887> snover: Yes, it is the only fix for this problem I could come up with. All it does is clip a few pixels on the right and bottom, just for that one game (Phantasmagoria). I think it is a good compromise.
[18:19] <snover> rsn8887: i just said what the actual probably probably is, please read again what i just wrote and if you dont understand then ask questions
[18:22] <snover> actual problem*
[18:23] <snover> sorry about all the typos, i am really trying to get these buildbot workers working this weekend and so am mostly focusing on that.
[18:24] <rsn8887> snover: I don't think this is the problem. The code is not ignoring the pitch. The code is written to use SDL to draw directly onto the Vita Texture memory for speed. The Vita texture memory only support sizes mod 8. Since the memory is 1:1 the same, we have to adjust the SDL_Texture size.
[18:26] <rsn8887> snover: I agree the clipping on the right and bottom is a little unfortunate but it allows to write directly to the Vita texture memory.
[18:26] <rsn8887> snover: Note there's only one game I know of where this is an issue, and that is Phant1
[18:27] <snover> rsn8887: do you see in internUpdateScreen where it is using _hwScreen->pitch?
[18:28] <snover> you are replacing _hwScreen->pixels and not updating _hwScreen->pitch
[18:29] <snover> if the pitch of the new pixel memory is not the same as the pitch of the pixel memory that SDL allocated then you are going to get exactly what you describe, pixel data drawing into the wrong lines because there are N bytes of padding in the pixel memory and you havent told the rest of the system that there are N bytes of padding in the pixel memory
[18:29] <snover> because you have not updated pitch
[18:32] <snover> so internUpdateScreen happily draws into the padding memory thinking it is the start of the next line, and now youve got misalignment in the output.
[18:33] <snover> pitch = width; r = width % 8; if (r) pitch += 8 - r;
[18:35] <rsn8887> snover: hmmm I think you are right. I was hesitant to overwrite _hwScreen->pitch since I thought SDL would take care of such things...
[18:39] <wjp> It goes together with updating pixels this way
[18:39] <rsn8887> So the correct fix is to set _hwScreen->pitch+=_hwScreen->pitch%8
[18:39] <wjp> that seems unlikely
[18:39] <snover> no, i gave you the equation a few line sago. please, please, read what i write.
[18:40] <snover> pretty please.
[18:41] <snover> if there is some way i can communicate this information more clearly please let me know so i can try to do that in future.
[18:41] <rsn8887> Ah of couse.
[18:42] <rsn8887> No I get it, we need to add the remainder. I will try it and test it now.
[18:43] <wjp> vita2d_texture_get_stride will probably also return pitch
[18:43] <wjp> that might be safer than trying to compute it ourselves
[18:45] <wjp> (I would strongly recommend using that)
[18:45] <snover> oh, yes, if there is already an api to do any of these calculations, do that instead
[18:50] <rsn8887> Yes I think this will now be very elegant. Need to test, but good to learn from the masters :)
[18:51] <rsn8887> e.g. screen->pixels = vita2d_texture_get_datap(_vitatex_hwscreen);
[18:51] <rsn8887> now becomes
[18:51] <rsn8887> screen->pixels = vita2d_texture_get_datap(_vitatex_hwscreen);
[18:51] <rsn8887> screen->pitch = vita2d_texture_get_stride(_vitatex_hwscreen);
[18:51] <wjp> right
[18:52] <rsn8887> and none of that funny width and height hack anymore.
[18:57] <rsn8887> Yup works perfectly
[18:57] <rsn8887> No clipping anymore.
[18:59] <rsn8887> I will make a new commit
[18:59] <wjp> excellent
[19:07] <rsn8887> btw I think the Vita is one of the best platforms for ScummVM, because it beats most other ports in terms of display quality. That sharp-bilinear shader ("sharp") gives sharp pixels without distortion and minimum blur. I wrote a little post about the benefits of it here: https://github.com/rsn8887/Sharp-Bilinear-Shaders
[19:10] <rsn8887> ScummVM is so great thanks for all your and snover's hard work on it.
[19:13] <rsn8887> And everybody else's of course it is a huge project.
[19:22] <-- Joefish left irc: Read error: Connection reset by peer
[19:22] --> Joefish joined #scummvm.
[19:22] #scummvm: mode change '+v Joefish' by ChanServ!ChanServ@services.
[19:37] <-- jamm left irc: Ping timeout: 240 seconds
[20:07] --> girafe joined #scummvm.
[20:29] <wjp> snover: FYI, I merged master into my sci_rgb branch
[20:30] <snover> wjp: ooh. are you going to work on it again? :)
[20:30] <snover> does that mean you are*
[20:30] <wjp> whole bunch of merge conflicts, it's back into a working proof-of-concept state now again
[20:31] <wjp> at some point I want to re-do the whole GfxScreen(16) thing
[20:36] <snover> i understand that impulse.
[20:37] <snover> am i correct in remembering that the sci16 graphics code also has some rounding errors because it was not designed to follow the inclusive-rects design of the original engine?
[20:38] <wjp> shouldn't be more than a few
[20:38] --> dafioram joined #scummvm.
[20:39] <wjp> although I suppose the port code could still be fishy
[20:39] <snover> i definitely ran into ports bugs when i ran through LSL2
[20:40] <snover> (when testing Span)
[20:40] <snover> though those looked less like rounding errors than just broken positioning code
[20:41] <snover> there was some QFG ticket recently about text wrapping onto the next line when it wasnt supposed to which looked like a rounding error to me
[20:41] <wjp> the titlebar/menubar also causes a bit of a mess with positioning IIRC
[20:41] <wjp> yeah, the TerrorSaurus
[20:41] <snover> i wish all dinosaurs were named like that
[20:41] <wjp> that could certainly be an off-by-one
[20:42] <wjp> hrm, did I already ask you if you have qfg1vga/mac ?
[20:42] <snover> ScareaTops
[20:42] <snover> i think so, yes.
[20:42] <snover> i have only the qfg collection CD, alas.
[21:00] <Lightkey> https://www.twitch.tv/chronowolflive showing off the next Tex Murphy game, in Unity.. no more outdated graphics :-(
[21:07] <criezy> rsn8887: I assume those changes to the vita port should go to branch-2-0 as well?
[21:08] <rsn8887> criezy: definitely will you move them or shall I commit?
[21:08] <rsn8887> *move->duplicate whatever
[21:09] <criezy> If you can do it and know how to do it go ahead.
[21:10] <rsn8887> criezy: Cherry pick each one of my commits from master into 2.0?
[21:10] <criezy> Yes.
[21:10] <rsn8887> I think I can manage that.
[21:11] <snover> please use git cherry-pick -x so the original commit id is referenced in the cherry-pick
[21:11] <snover> rsn8887: ^
[21:11] <rsn8887> ok
[21:11] <snover> thanks
[21:19] <-- rootfather left irc:
[21:23] --> rootfather joined #scummvm.
[21:23] #scummvm: mode change '+o rootfather' by ChanServ!ChanServ@services.
[21:23] <rsn8887> ok done
[21:24] <criezy> Thank you
[21:24] <-- ajax16384 left irc: Read error: Connection reset by peer
[21:24] <rsn8887> It always makes me nervous because it is so easy to really mess up git. Luckily there's always reflog
[21:51] <rsn8887> I think Windows and OSX build should default to the OpenGL renderer. It is the only one that behaves *as expected* in fullscreen mode, e.g. renders the game fullscreen with bars on the side, but not top and bottom. All other renderers display a centered "window" surrounded by black bars, even in fullscreen mode.
[21:52] <snover> rsn8887: i think you are using sdl1 again :)
[21:54] <rsn8887> snover: How is it possible, I deleted my SDL.framework, and only have SDL2.framework left! (Apple magic?)
[21:55] <snover> sdl is statically linked in buildbot.
[21:55] <rsn8887> Ah I see.
[21:59] <rsn8887> Also, neither SDL1 (too old) nor OpenGL give me an option to turn filtering on or off. I think 1.9.0 had that option.
[22:00] <wjp> there should be a "Filter graphics" option
[22:01] <rsn8887> Yes because kFeatureFilteringMode is true. But I cannot see it. This is on OSX latest buildbot, switched to opengl.
[22:01] <rsn8887> Ah now it is there. It required a restart to appear.
[22:02] <snover> hum.
[22:02] Action: snover adds another bug to the list&
[22:02] <snover> :)
[22:03] <rsn8887> yes. It seems to be checked on startup. If starting with OpenGL it is there and remains there, even when switching to SDL1. If starting with SDL, it is not there and does not appear when switching to OpenGL.
[22:10] <-- waltervn left irc: Read error: Connection reset by peer
[22:17] --> dreammaster joined #scummvm.
[22:17] #scummvm: mode change '+o dreammaster' by ChanServ!ChanServ@services.
[22:19] <Lightkey> https://www.twitch.tv/videos/206167294 here is the VoD
[22:19] <Lightkey> https://www.youtube.com/watch?v=tooF40ktbdM and here just the documentary
[22:19] <snover> Lightkey: nice, thanks!
[22:20] --> Strangerke_ joined #scummvm.
[22:21] <criezy> Yes, the "Filter graphics" option is only visible when the current graphics manager supports the option.
[22:21] <criezy> And with SDL 1.2, the issue is that the SurfaceSdl one doesn't support it.
[22:21] <criezy> So when you switch from SurfaceSdl to OpenGL you need to close the options dialog and reopen it to get the option visible.
[22:21] <criezy> Fortunately with SDL2 no such issue occurs because both the SurfaceSdl and OpenGL graphics manager support the option.
[22:22] <criezy> That's a know issye when we use SDL 1.2, and I never found the motivation to fix it since SDL 1.2 is going away.
[22:22] <snover> tsoliman: i havent reran the full build of android lately to see whatever linker errors you were encountering, though i can at least say it does build successfully (and the builds actually work) with only scumm, sci, and mohawk engines. i did also push a new image now since i have been rebuilding images with some library tweaks.
[22:23] <-- Joefish left irc: Ping timeout: 276 seconds
[22:23] <-- Strangerke left irc: Ping timeout: 248 seconds
[22:23] Nick change: Strangerke_ -> Strangerke
[22:25] --> waltervn joined #scummvm.
[22:25] #scummvm: mode change '+o waltervn' by ChanServ!ChanServ@services.
[22:50] <tsoliman> yep the linker errors were related to kyra and sherlock
[22:50] <rsn8887> criezy: I see, I agree it doesn't need to be fixed. I just wish the buildbot wasn't still building OSX targets only using SDL12
[22:51] <tsoliman> logs.scummvm.org is down btw
[22:51] <tsoliman> well now it is up - nevermind
[22:51] <criezy> Yes, it has been down since yesterday.
[22:51] <criezy> Oh, it is back up now?
[22:52] <criezy> It is! Yeah!
[23:23] <-- ny00123 left irc: Quit: Leaving
[23:26] <-- girafe left irc: Read error: Connection reset by peer
[23:28] <-- criezy left irc: Quit: criezy
[23:52] <snover> tsoliman: since i am curious and i am in the middle of building a bunch of other stuff right now, what were the failures about?
[23:54] --> criezy joined #scummvm.
[23:54] #scummvm: mode change '+o criezy' by ChanServ!ChanServ@services.
[23:59] <snover> (like pastebin some errors at me babby!)
[00:00] --- Sun Dec 3 2017