Wine

Matrix Games Forums

Forums Register Login Photo Gallery Member List Search Calendars FAQ

My Profile Inbox Address Book My Subscription My Forums Log Out

Wine

View related threads: (in this forum | in all forums)

Logged in as: Guest

Users viewing this topic: none

Printable Version

All Forums >> [Current Games From Matrix.] >> [World War II] >> Norm Koger's The Operational Art Of War III >> Wine

Page: [1]

Message

<< Older Topic Newer Topic >>

Wine - 7/31/2006 11:09:36 PM

superdave56

Posts: 22
Joined: 4/17/2005
Status: offline

I don't know if this belongs in general or support, but I'm putting it here 'cause it has nothing to do with any official support issue.

Has anybody had any luck getting TOAW III running in Linux under Wine?

I've got the game on Windows (dual-boot) but I'm primarily a Linux user for various reasons probably beyond the scope of this thread.

On a side thought, there's at least one person here willing to pay for PC wargames developed for the Linux platform.

Post #: 1

RE: Wine - 8/1/2006 2:12:50 AM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

I haven't tried it yet but intend to do so. Ralph T. (TOAD dev chief) said that he thought it might work, since it is essentially old code with not much DirectX. Or at least that's how I remember it, apologies if wrong.

BTW on your side thought, there's at least of two of us. LOL. There's no chance IMHO, considering it's something of a miracle anything gets developed for Windows even.

< Message edited by Captain Cruft -- 8/1/2006 2:13:16 AM >

(in reply to superdave56)

Post #: 2

RE: Wine - 8/1/2006 4:07:34 PM

JMass

Posts: 2364
Joined: 6/3/2006
From: Italy
Status: offline

quote:

ORIGINAL: superdave56
Has anybody had any luck getting TOAW III running in Linux under Wine?

You can use QEMU and install windows (and toaw) in it, if you want have access to usb devices use ME, no 98, perhaps xp is better (2000 have some problems) but use more space on hd. I have test this solution with talonsoft and hps games (better copy windows games installations to qemu and use nocd): games run a bit slower but you can play in Linux! I have no tested qemu accelerator because my problem is the same: I'm short of time.

_____________________________

"Klotzen, nicht Kleckern!"Generaloberst Heinz Wilhelm Guderian

My boardgames collection: http://www.boardgamegeek.com/collection/user/JMass?own=1&subtype=boardgame&ff=1

(in reply to superdave56)

Post #: 3

So close yet so far - 8/1/2006 4:09:01 PM

superdave56

Posts: 22
Joined: 4/17/2005
Status: offline

I gave it a whirl last night.
The install came off without a hitch, and opart 3.exe will come up to the first screen.
There's a problem with the buttons (start a new scenario, etc.) though. Whenever a button is pressed, the program hangs.
The menus work fine (File, etc.) but whenever one of the graphical buttons is pressed I get the hang. I haven't had time to really play with it but I'm getting suspicious of sound. I'm thinking maybe the "click" sound when one of the buttons is pressed is causing some kind of issue. It still doesn't work if sound effects are off, but maybe there's a call to the sound system anyway.

I wonder if there are any command line options for opart 3 that might be useful, especially the ability to load a scenario or save directly and skip the first screen, i.e. "opart 3.exe scenario".

Post or send me a message when you try it - I'd be very interested to see if you get the same results.

(in reply to Captain Cruft)

Post #: 4

RE: So close yet so far - 8/1/2006 6:14:37 PM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

Yes TOAW 3 is a giant amongst wargames in that it allows you to give it a filename as an argument! Something so totally obvious yet virtually nobody else does it. Go figure ...

I would try something like:

opart3.exe nointro nosound scenario.SCE

Or if that doesn't work, make a .SAL file under Windows and use that instead. I know that works.

(in reply to superdave56)

Post #: 5

RE: So close yet so far - 8/2/2006 12:24:28 AM

superdave56

Posts: 22
Joined: 4/17/2005
Status: offline

quote:

ORIGINAL: Captain Cruft

Yes TOAW 3 is a giant amongst wargames in that it allows you to give it a filename as an argument! Something so totally obvious yet virtually nobody else does it. Go figure ...

I would try something like:

opart3.exe nointro nosound scenario.SCE

Or if that doesn't work, make a .SAL file under Windows and use that instead. I know that works.

I tried a command line in Windows to directly load a .SAL and it didn't work - I just got the regular startup screen.

I tried

"opart 3.exe nointro nosound test.SAL"

Am I doing something wrong here? I tried it with the nosound option and that worked fine (i.e. sound was disabled) - it just looks like it doesn't take the filename argument.

(in reply to Captain Cruft)

Post #: 6

RE: So close yet so far - 8/2/2006 12:29:37 AM

superdave56

Posts: 22
Joined: 4/17/2005
Status: offline

Never mind. It worked in Windows if I specified the full path to the .SAL file, i.e.
"C:\Matrix Games\ . . . . \test.SAL".

(in reply to superdave56)

Post #: 7

RE: So close yet so far - 8/2/2006 2:51:45 AM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

Yes Windows does maintain a notion of a "current directory" ;) Though it is system-wide, unlike the per-process UNIX model.

(in reply to superdave56)

Post #: 8

RE: So close yet so far - 8/3/2006 9:30:32 PM

superdave56

Posts: 22
Joined: 4/17/2005
Status: offline

Alright, here's the deal with TOAW III & wine support.

The problem is the buttons for loading a save, starting a new game, etc. Any button of that style will hang the program if pressed.
I have located and confirmed what the problem is. Its an issue with the GetAsyncKeyState function in Wine (see tech details below). In other words its a bug in wine. I have yet to locate any other problems in my testing other than sound, which is a little shaky on my box. This might just be a problem with my particular setup though.

There is a workaround - you can't load a game from the default beginning screen because the buttons don't work. You can however load the game from the command line,

i.e. wine opart3.exe nointro nosound "c:\Matrix Games\ . . . \game.sav"
(nosound because sound on my Linux box isn't so good).

This will load the save or scenario and you go directly to the game. As long as you use the keyboard shortcuts or windows menus at the top you are fine. I have tested this and successfully played a few turns of smaller scenarios without a hitch. All functions vital for gameplay can be accessed from the menu or via keyboard shortcuts. Remember you can hit [Enter] or [Esc] or number keys to choose options instead of having to click (which will hang the program) on the "TOAW style" buttons in the main program. You might not see the "begin" box when you load the scenario from the command line. Just hit [Enter] and you should be able to play. This is not an ideal solution by far, since one click on the 'TOAW style' buttons by mistake and your up the creek (save often!).

As far as fixing the 'TOAW style' button behavior, I am going to work on a patch to fix the GetAsyncKeyState function in Wine. I will then submit it to the Wine project. There's no guarantee that my patch will be accepted but even if it isn't, I will post my fix to the forums here. I have an ugly, dangerous hack working on my wine install now but I can't recommend since it will almost certainly break other programs. Its just to prove where the problem is. Getting a real fix together will probably take me a couple of weeks because I don't have a whole lot of manhours to work on it.

I believe if the GetAsyncKeyState problem is solved, TOAW III will play very well under Wine.

< Message edited by superdave56 -- 8/3/2006 9:59:40 PM >

(in reply to Captain Cruft)

Post #: 9

technical details - 8/3/2006 9:58:52 PM

superdave56

Posts: 22
Joined: 4/17/2005
Status: offline

Here is what I believe is happening with the buttons in TOAW hanging the program when you click on them.

I think the code is something like:
//click mouse on button
//draw the button depressed
GetAsyncKeyState(LEFT MOUSE BUTTON); //we loop until this tells us the left mouse button is up
//do some work, pop up dialog box, etc.

The problem is that we hang forever on GetAsyncKeyState(); -
it always says that the left mouse button is down even after it is released.

I can prove this is the problem. If you have the Wine source code, you can go into the
dlls/winex11drv/keyboard.c (where the code for GetAsyncKeyState() is located)
and add something like the following code to the beginning of the function:

Do This At Your Own Risk! I Am Not Responsible If You Break Your Wine Install!

SHORT GetAsyncKeyState (int key)
{
if (key==1) //1 corresponds to the left mouse button
{
return 0;
//button is up or window does not have focus
}
//rest of function
}

This will fix the problem and the TOAW buttons will work. Only do this if you know exactly what you are doing because it will almost certainly break something. As I said in my post above, I'm hoping to put together a real patch or perhaps the wine project will produce a fix.

My hack proves that GetAsyncKeyState is the problem. The real question is why the mouse button never registers as being up. The mouse up event is apparently never being processed so the key_state table is never updated. I'm not sure why but my guess is that Wine is processing events synchronously (in order) and some event is in the queue (perhaps a focus change?) in front of the mouse up event that is never processed properly. So the mouse up event is blocked. I'll poke around in the wine source and do some more debugging and see if I can't figure out why the mouse up event never gets processed.

(in reply to superdave56)

Post #: 10

RE: technical details - 8/3/2006 10:02:55 PM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

Excellent work matey, thanks

Just a thought. If Wine was processing events synchronously as you describe then surely just about nothing would work?

(in reply to superdave56)

Post #: 11

RE: technical details - 8/4/2006 10:26:56 PM

superdave56

Posts: 22
Joined: 4/17/2005
Status: offline

Sorry, I wasn't thinking that explanation through very well.
I was kind of in a hurry.

I was originally thinking about some window message was not being processed correctly and kind of jamming things up, but the explanation is probably much simpler than that.

Windows receive most events in order otherwise you could receive the mouseup event before the mousedown event for instance.

I haven't been in the Win32 world for a long time, but if memory serves the program is responsible for getting its events off the queue. Usually a Win32 program sits in a message loop calling GetMessage(), DispatchMessage(), and calling appropriate event handlers, etc.

So what might be happenning is that opart3.exe is looping calling the GetAsyncKeyState over and over again in an infinite loop. So it never calls GetMessage(), so the mouseup event which is sitting on the queue is never processed. Since the mouseup event isn't processed, wine doesn't update the key_state table to reflect the mouse button being up.

Really, though, it doesn't matter because the implementation of GetAsyncKeyState is just plain wrong in wine. I did some research on MSDN and it seems pretty clear to me that GetAsyncKeyState should be querying the actual physical state of the keyboard/mouse at this very moment, regardless of windows messages and all that. It shouldn't consult some key_state table, it should actually ask the mouse 'is your left mouse button up or down right this second?'.

There's another function GetKeyState which is supposed to check what keys are up/down within a particular window taking into account what messages have been processed. It's so you can see if the user was holding down the shift key while pressing the mouse button for instance - so you want to know if the shift key was down at the time the mouse event was processed, not necessarily a few milliseconds later when you make the function call.

The way wine works now GetKeyState/GetAsyncKeyState do the exact same thing and I believe that's wrong. GetAsyncKeyState, IMHO should be written so that it queries the actual, physical state of the keyboard/mouse. So I'm going to try and rewrite the function to do that and submit it as a patch and see how it goes. That should fix TOAW and some other games that depend on GetAsyncKeyState working as it does in Windows.

(in reply to Captain Cruft)

Post #: 12

RE: technical details - 8/5/2006 3:13:15 AM

Captain Cruft

Posts: 3652
Joined: 3/17/2004
From: England
Status: offline

That makes sense I guess. GUI programming is not my strong point TBH.

Good luck with submitting a patch. I remember a not dissimilar thing a couple of years ago with the XFree86 (as was) mouse input processing and the various Quake engines. The X developers were quite insistent there was nothing wrong, but to a player of the game(s) it was totally obvious that there was. It eventually took a player with coding knowledge to drill way down into the source and pinpoint the actual problem. Which of course did not manifest under normal conditions, only under the particular ones in the game, which involved a lot of simultaneous key presses and mouse movement ("sliding" and "strafe-jumping", if you're interested) ...

Anyway, thanks again

(in reply to superdave56)

Post #: 13

update - 8/8/2006 5:32:31 PM

superdave56

Posts: 22
Joined: 4/17/2005
Status: offline

I remember the Quake thing, something about buffering mouse events?

Anyway, I thought I'd post a little update.

I've rewritten GetAsyncKeyState the way I think it should work and have done some testing. TOAWIII works great so far (I've played several turns of Two Weeks in Normandy on Ubuntu). I've got to clean things up and do a lot more testing though.

I'll be pretty busy this week and am out of town this weekend, but hopefully I can get finished up late next week sometime.

(in reply to Captain Cruft)

Post #: 14

RE: update - 8/11/2006 5:10:34 AM

jascou

Posts: 57
Joined: 2/19/2005
Status: offline

Hi, guys...

sorry to intrude, but as mentioned on an earlier thread (dealing with running the game on a mac), I've been running TOAWIII on Linux with CrossOver Office 5.0, which uses an older version of Wine, 20050830.

I'm not sure if any of you want to install an older version of Wine just to play 1 game, but I thought I'd mention it.

On the other hand, Crossover Office is a great investment for anyone wanting fuss-free Wine management, PLUS you get to financially support Wine development at the same time