Beat Hazard Forum

Beat Hazard basically runs fine. However, I'm unable to browse my music files in-game. The cause is probably the same as in normal wine: "unimplemented function KERNEL32.dll.GetVolumePathNamesForVolumeNameA"

Also, this may not be Beat Hazard specific but I seem to hit a bug when trying to launch the game in full screen mode with two displays connected. I can work around that by enabling a virtual desktop in wineconfig or by disconnecting the secondary display. I'll try and get some kind of useful log about that.

Hi,

In a windows world, something like "GetVolumePathNamesForVolumeNameA" would, I surely  

suspect, refer to floppydrive 0 <==> A: .... I could be wrong, but that's how I've always
viewed that (and I don't have a 3.5" drive, do you? 8)....however, you can work around this
I believe. Start cxsetup (manage bottles) -> highlight bottle -> control panel -> wine configuration
-> launch selected item. In the winecfg gui that appears, click on the 'desktop integration'
tab -- there you will see how the 'common' windows locations are mapped to filesystem locations
on your host machine. You may be able to have a play there and make one of the links point to
where Beat Hazard is defaultly looking for your music files (or add a link to satisfy it's needs)..

..regarding the behavior wrt dual-head or 'twineview' setups, that is a known issue with
crossover/wine, and has as much to do with the X implementation as it does with wine itself.
At present, the only way I know to work around it is to (as you've discovered) enable the
emulated virtual desktop function or disable the dual-screen/twinview setup.

Hope this helps...

Cheers!

If you're just talking about stretching between both monitors, you can expose the correct resolutions manually in xorg.conf so that it sticks to one monitor only rather than manually turning it on and off. My line in [Screen], for example, reads

Option "metamodes" "CRT: 1440x900 +1680+0, DFP: 1680x1050 +0+0; CRT: NULL, DFP: 1680x1050 +0+0; CRT: NULL, DFP: 1400x1050 +0+0; CRT: NULL, DFP: 1280x1024 +0+0; CRT: NULL, DFP: 1280x960 +0+0; CRT: NULL, DFP: 1152x864 +0+0; CRT: NULL, DFP: 1024x768 +0+0; CRT: NULL, DFP: 960x720 +0+0; CRT: NULL, DFP: 928x696 +0+0; CRT: NULL, DFP: 896x672 +0+0; CRT: NULL, DFP: 832x624 +0+0; CRT: NULL, DFP: 800x600 +0+0; CRT: NULL, DFP: 720x400 +0+0; CRT: NULL, DFP: 700x525 +0+0; CRT: NULL, DFP: 640x512 +0+0; CRT: NULL, DFP: 640x480 +0+0; CRT: NULL, DFP: 640x400 +0+0; CRT: NULL, DFP: 640x350 +0+0; CRT: NULL, DFP: 576x432 +0+0; CRT: NULL, DFP: 512x384 +0+0; CRT: NULL, DFP: 416x312 +0+0; CRT: NULL, DFP: 400x300 +0+0; CRT: NULL, DFP: 360x200 +0+0; CRT: NULL, DFP: 320x240 +0+0; CRT: NULL, DFP: 320x200 +0+0; CRT: NULL, DFP: 320x175 +0+0"

Which in effect exposes resolutions to the game I'm running that are one of the standards for the first monitor, and "off" for the other. They simply show as normal resolutions in the game, and the system automatically blanks the second screen when needed and turns it back on when you're done. It does mean that you can't really use the second screen while you're gaming, but it's a much more elegant solution that manually turning TwinView on and off in my opinion.

That works some of the time, but other times it doesn't because the X server presents (first up)
the -combined- resolution of both desktops...then it becomes ugly :) The most 'elegant' work
around I've found in those cases (instead of toggling twinview) is to enable virtual desktop,
desktop_size at 1 pixel less that actual, then turn off window manager decorations and it -appears-
as a pseudo fullscreen. But then, on this rig display0 has a completely different default res/aspect
compared to display1 and that just adds to the confusion 8)

I can live with it booting across the desktop the first time, it's functional enough to set it to single monitor fullscreen res in the game in every game I've tried so far, and after that one time I archive the bottles and never need to deal with it again. 😀

The missing function gets all drive letters associated with a given volume GUID path. I managed to put together a quick and dirty implementation that seems to do the trick :) Yay!
I can upload the new dll.so (for OS X 10.6.3) and a patch someplace, once I figure out where and how to properly make the patch :P
Unless of course, someone already did that elsewhere in these or winehq forums..

Here's the patch:
patch

apply to crossover games source thus:
patch -p1 < kernel32.patch
from the directory you unpacked crossover-games-sources-9.0.0.tar.gz into (that contains directories wine, cxgui etc).

A .dll.so and .dll.so.fake compiled using the git source on OSX:
kernel32.dll.so
kernel32.dll.fake

Alas, I'm not a registered rapidshare user, so only 10 downloads are allowed 😋

A question about using self-compiled .dll.so files: I'm currently overwriting the appropriate files in /Applications/CrossOver Games.app/Contents/SharedSupport/CrossOverGames/lib/wine to actually use the above patches. Is there a cleaner, more application or bottle specific way of overriding the builtin dll files with other builtin dll files?

I still can't get my music to load in Beat Hazard, even after tweaking wineconfig. I can't use anything other than the built in songs, so I gave this a bronze medal. :| Has anyone figured out how to get this to work on Snow Leopard (or Leopard)?