Release WINE


Nothing much to say apart from I saw a window from Steam startup... might see if a "fresh install" may get it further as I've just copied my Steam installation from my desktop.

I also tried Osmos - still crashes.

Cogs - I see the Crazy8 splash screen then crashes - I think it doesn't like the sound proxy... (Do you have to do anything special to use the sound proxy?)

So Cogs has been the most promising so far! :) Was nice to see some x86 linux showing some graphics... even for a second.
 
Cogs uses shaders afaik. Can you turn them off in the configfile or something and try again?
 
I think it doesn't like the sound proxy...
If you think the sound proxy is causing problems...

You can disable the sound proxy like this:


cd wineroot/usr/lib
rm libasound.so.2
cd i386-linux-gnu
ln -s libasound.so.2.0.0 libasound.so.2

You can enable it again like this:


cd wineroot/usr/lib
ln -s libproxyclient.so.1 libasound.so.2
rm i386-linux-gnu/libasound.so.2
Direct3D is known to *not* work yet. If you see libGL messages in the console, don't expect much ;)

You should also look at the quoted system requirements for the games you're trying to run.
 
Last edited by a moderator:
Not the speed you are hoping for but... 

http://www.youtube.com/watch?v=cYsfCXzIbaA
 
Last edited by a moderator:
133Mhz Pentium with 24megs of ram was the minimum if you had a 3D accelerator.. I'm sure there is there can be some tweaking done to get this faster.

What's more important is that this shows that his opengl is working through wine (well outside wglgears).. although a tad slow..
 
Last edited by a moderator:
Nothing much to say apart from I saw a window from Steam startup... might see if a "fresh install" may get it further as I've just copied my Steam installation from my desktop.
What do you want with Steam?

I don't know any Steam game that neds 100 MHz.

For me we're much to slow for Steam.
 
Well for one Steam Linux would give us access to Linux Half Life - I'm guessing that x86 Linux games will have a little less overhead than stuff going through awine too.


Also the HumbleBundle games could possibly run ok as some of them were ports from Android (i.e targetted to lower spec machines)


Plus it would be cool to say "Hey look, Steam on ARM - Steam on Pandora!"
 
Lunixbochs, I realize the focus here is games, but how about general purpose Windows applications ? Have you tested anything that can run so far, even sometimes as simple as Notepad or something like that?
 
As HalfLife doesn't seem to run faster then software rendered with the GL proxy, I guess it is cpu restricted, too.

With a win95 install it seemed to run even faster than with the userspace qemu+wine.

see here:

http://boards.openpandora.org/index.php/topic/7004-qemu-for-pandora-for-rebirth-competition/page-14#entry132419
What I shared was my OMG I got it to work video, I did get a little more speed out of it with some tweaking pretty much on par with software rendered video above.. the other thing with my setup I had sound enabled so that may of been another detractor in speed. When I enabled software rendering with sound it's slower than the video in the other thread.
 
Last edited by a moderator:
I would recommend to use the half life version without steam. And try to lower details etc, which can give a speedboost too. Great that open gl works with wine. Is direct draw possible too?
 
ports from Android
Unfortunately, that's not even good enough. Remember the Android device has 600MHz+ while we have ~100MHz to work with.
Ah don't worry - I don't have unrealistic expectations. I'm well aware we are running on an emulated x86 CPU so I'm just trying things that are "more likely" to be playable. Obviously without seeing their source I have no idea on how much floating point is used - how much work is GPU bound/CPU bound. I just picked Osmos and Cogs as they are "simpler" puzzle games as opposed to something action intensive.

I also figured that with people seeming to be concentrating on the WINE side of things I could explore the x86Linux rabbit hole.
 
I would recommend to use the half life version without steam. And try to lower details etc, which can give a speedboost too. Great that open gl works with wine. Is direct draw possible too?
That was version 1.0 of half-life taken directly off the original CD circa 1998.
 
Dungeon Keeper / Creative Writer don't seem to work.

Monster Truck Madness starts to work (with the installer) but crashes with pcm_audio errors

SimCopter seems to be working with OpenGL and is VERY playable. (Just has a WineD3D_TEXF_LINEAR Not supported in software blit + DirectSound issue)
 
Maybe commandos will wirk. 2.99$ sale at gog. 120 Mhz Pentium, DirectX. Sounds nice :)
 
Last edited by a moderator:
Floating point operations aren't just converted to host instructions. They're passed through QEMU's SoftFloat engine. We could probably hack this to be fast for our case.

https://github.com/qemu/qemu/blob/master/fpu/softfloat.c
Holy guacamole, some accurate but scary stuff in there, take a look at float32_muladd over 250 lines of code to perform:

result = ( a * b ) + c

I wonder how often these sorts of functions are being called, and what would happen if a non accurate version is used instead, e.g.:

result = a * b

result += c

I guess a lot of stuff will be okay, but some stuff will break, potentially making it impossible for such harsh optimizations, although it sort of feels like the sort of thing that might be suitable on a per emulated application basis.

EDIT: From some of the stuff I am reading, from a couple of years ago, all floating point calculations are translated into series of integer instructions, in order to ensure exact precision. Is that still the case now? Is it possible to allow them to be translated into ARM floating point versions instead (obviously lots of stuff could go wrong, but it would be interesting to see if anything at all runs, and what the speed is like). Please forgive if this is a stupid question, I haven't looked at to the insides of QEMU until today, it just feels like turning 250 lines into one ARM instruction would be a massive win if it is true.

EDIT2: There seems to be some 'native' implementations of softfloat, https://github.com/hackndev/qemu/blob/master/fpu/softfloat-native.h
 
Last edited by a moderator:
Back
Top