Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Kyzrati]

As per the announcement, we now have an OSX test package (.dmg) available for Alpha 5c. This is the place to discuss it if you have any feedback.

(Again, thanks to alaska for helping with this!)

[alaska]

I've noticed a potential issue with moving the game in and out of fullscreen, so if anyone runs into it (or anything really), post it here, and we can see if the fix I've found works for you.  I'll roll up another .dmg that incorporates them once I've poked at it a bit more.

[Kyzrati]

For the record, I've gotten some feedback via email that I'll drop here:

It works! Had a few plays and here are my thoughts:

The .dmg file: great job — the hidden files, when visible, are out of sight. Great attention to detail here

The game/winebottle takes an unordinary amount of time to boot up the first time, with no icon in the dock to indicate. It would be good if there was a splash screen telling me it’s going. I had to check Activity Monitor to see if it was running. Subsequent startup times were fine.

The keys in the game say “alt+0-9” to mount items but the game responds to Cmd+0-9 instead. Cmd-C was ignored, it might be getting caught by the winebottle as “Copy to Clipboard".

Several times during a play through, the window minimised or lost focus for no obvious reason.

The game data seems to be being stored within the application, which isn’t good — if I were to upgrade (by replacing the application), I would lose my save games and progress etc. It should be being stored somewhere like ~/Library/Application Support/Cogmind where it can be backed up.

Along with my responses:

The need for Alt key usage is quite problematic on non-Windows systems because Windows has its own special key for system features, while OSX/Linux actually use the Alt key itself, resulting in fewer possible combinations overall.
 

Several times during a play through, the window minimised or lost focus for no obvious reason.

Hm, my guess is this has to do with a particular key command that was also being intercepted by Wine (you were using the keyboard, I presume?). It's possible to change some of these via the Wine settings, I believe, though no attempt has been made to do so yet. Hopefully we can get it to pass Cmd-C along properly.

About storing player data outside the game, this is currently how it's handled even on Windows as well. While the trend is towards storing data in user directories, I personally really hate that method and doing so has drawbacks as well (making it inconvenient or impossible to play via thumb drive, for example). I'm not sure how Wine normally handles that sort of thing, but it might need to become an option :/. I would first have to add it to the Windows version as well.

[alaska]

Let me see if I can go through each of the issues (let me know if I miss anything)

Splash screen
As far as the splash screen, wineskin has had an open issue for this very feature for a LONG time, but it isn't considered very high priority. I could attempt to code it in myself, but that is a lot of trouble (and potentially a lot of unexpected side-effects) for very little gain.  I'll look into some way I might be able to cheat on it instead.

alt vs cmd
I observed this as well.  Strangely, even enabling the option to have wine treat option as alt still saw the game responding to cmd instead.  Curious.

cmd-c
Actually, using my current settings,this seemed to work just fine for me (see window minimization/focus loss below for what these settings are); it unequipped the item in my C slot.  Which is what alt-letter is supposed to do, right?

window minimization/focus loss
I have yet to observe this, though I've been running it in full screen almost exclusively, and have most recently been testing it with the "Use Mac Driver instead of X11" option on under "Screen Options".  The only thing this has won me so far is that the mouse cursor is no longer visible with keyboard mode on (as it should be).  While this used to be experimental, it is now the default driver for Wine, so it should be stable.  Wineskin seems to opt for X11 by default.  I'll confirm this.  In any case, maybe try enabling this instead.

game data stored within .app
As, Kyzrati mentioned, the data is stored within the game directory on Windows.  Having said that, wineskin sets up mappings for Desktop, My Documents, My Pictures, My Videos and My Music by default, so if he some day decided to move them to a folder in My Documents, it should "just work^tm"

[Kyzrati]

I do believe that some of the problems might be unique to this person's system.

I don't think the splash screen is super important, myself, since it apparently only happens the first time, though I wonder how long it takes (in your video I saw it took a bit to start up, but it wasn't that bad--maybe they have a slower CPU). I imagine that the startup time also has to do with the game's own startup time, which can be a short while on old systems (and it's just a black screen), though that amount of time is technically static regardless of the number of plays.

That is precisely what Alt-C/Cmd-C is supposed to do, so that's odd. Wonder if it's something outside of Wine on their end that's doing the capture.

The mouse cursor should definitely remain invisible in keyboard mode--that would be really annoying if it wasn't, since the cursor is actually moved around by the game in that mode due to how it's coded.

About the player data save location, I imagined that would be the case--it should just work if and when I change that on the Windows side.

[alaska]

I wonder how long it takes (in your video I saw it took a bit to start up, but it wasn't that bad

I just tested out the .dmg install on a fresh machine that had never run Cogmind (or even Wine for that matter!) before, and running for the very first time, there was a delay of about 5 seconds before the app came up in full screen, but it worked very well after that, and this is on a dual-screen setup with a new Macbook Pro.  It's worth noting that, in full screen, the other screen is black, while it looks just wonderful in windowed mode (can't even tell it's not a native app).

So the short answer is that, yeah, there's a perceptible startup delay the first time it's run, but I'm not sure there's really a good workaround to letting the user know that something's going on, aside from hand-coding in a splash screen.  Which, incidentally, probably wouldn't be THAT bad, if I can find some prior art.  Apparently wineskin makes it pretty easy to compile your own wine engine in these later versions.  I'd rather not, though

Edit: from what I've been reading so far, swapping the key mappings (such that option is alt and cmd is control for instance) would also require a patch and recompile.

[Kyzrati]

Ha, don't worry about it. Good to know what's possible, though. 5 seconds is a bit long, but if it's only once I don't think it's a big deal. I'm sure I could shorten a bit it if necessary by adding something simple to the standard Cogmind startup screen.

Somewhat odd that the other screen is black when fullscreened. That must be a Wine thing, giving the game both screens for some reason, since it works normally on Windows.

[alaska]

The fullscreen weirdness doesn't happen if I don't have "Use Mac Driver instead of X11" checked, but using X11 causes instability (keys not responding) when switching between fullscreen and windowed unless "Decorate windows" is off, so my recommendation would probably be to run it with both of these off for now.

The only issue that I've been able to regularly recreate with these settings is the issue of the mouse cursor being visible in fullscreen startup if the saved game is in keyboard mode.  Switching to mouse mode and back resolves this AS DOES switching to windowed and back.  Very interesting indeed.  A minor annoyance at this stage, but unacceptable for release. I am currently looking for a workaround. Might try some alternate or older engines.

I am also trying to make it as far as I can in the game to see if I can observe the aforementioned focus stealing/dropping.  Still haven't seen it yet in any configuration.

TL;DR:
- Using OSX drivers results in prettier windowed mode and no cursor at startup if in keyboard mode (yay!), but weird fullscreen behavior on multi-monitor setups (boo!)
- Using X11 without window decorations results in normal fullscreen behavior (yay!), mouse cursor on fullscreen keyboard mode startup (boo!), and uglier windowed mode decoration (shrug).
- Using X11 with window decorations is bad news^tm

[Kyzrati]

The only issue that I've been able to regularly recreate with these settings is the issue of the mouse cursor being visible in fullscreen startup if the saved game is in keyboard mode.  Switching to mouse mode and back resolves this AS DOES switching to windowed and back.  Very interesting indeed.

Huh, I guess the first situation could make sense based on when the game is setting cursor visibility based on the settings, but the latter makes no sense at all :/ (certainly it points to the issue being with whatever Wine is doing...).

Thanks for looking into all this

[alaska]

Huh, I guess the first situation could make sense based on when the game is setting cursor visibility based on the settings

I think that's exactly what's going on.  Further testing has revealed that the situation only occurs if I click on on the (fullscreen) surface sometime after the game has started up and begun to draw the screen.  If I start clicking on the screen during startup, the cursor is grabbed early and then it disappears sometime before the game starts to draw (presumably when the game calls SDL_ShowCursor(0) )

My current thinking is that what happens is that wine does not grab the cursor in fullscreen mode, and doesn't properly keep track of the fact that the app has requested it to be invisible so that, if I click on it late, it grabs the cursor, but it stays visible.  I have seen the not-grabbing-in-fullscreen behavior in other games as well, but this is the only situation in which the cursor has been affected.

[Kyzrati]

Ah, that's interesting. On Windows when fullscreened the app window does capture the cursor immediately by default, regardless whether it's visible or not, so this has never been an issue.

[alaska]

Forcing it to run in fullscreen or a "Virtual desktop" seem to resolve this issue, but neither are adequate.  The former lets you exit fullscreen, but it is only into what appears to be a completely black void of an X environment behind the window, and the latter adds an extra window border that says something like <App name> - Virtual desktop.

[Kyzrati]

Yeah, players like their fullscreen to be fullscreen; they get mad when it's not

[alaska]

Ran into the CMD-C issue. Worked at first, then didn't. Researching fix.  Does NOT occur using the native OSX drivers so far.  At this point the black full screen is the only downside I'm finding to using this option, but I've submitted some issues to see if I can track down a good middle ground.

[Kyzrati]

Black fullscreen isn't a huge downside, but would certainly be annoying to the minority of multi-screen players.