Release WINE

[Pickle]

if there's no pnd nor a guide for noobs explaining how to even install it..how does the average user is supposed to use it?

just wait and be patient, this cutting edge and being developed.  Consider it beta testing at this point, when its ready as mentioned before it might be put into pnd form to make it simple.

The spiderweb rpgs are another set of games I wonder if will work with this. Although I dont know it they play well since some of them are at least 800x600.

 

[rohezal]

if there's no pnd nor a guide for noobs explaining how to even install it..how does the average user is supposed to use it?

This is alpha software, it needs some time. Here are the steps for a big software projekt.

1. First build it

2. Test it

3. Improve it

4. Test it again

5. Improve it again

...

50. Get more testers, do a big beta test

51. Improve it again

...

99. Make a pnd

100. release it .

 

[PokeParadox]

if there's no pnd nor a guide for noobs explaining how to even install it..how does the average user is supposed to use it?

You answered your own question - it's not for the average user yet - The quirks need figuring out before it's fit for general consumption.

 

[mcobit]

Tried to build it in sebt3's toolchain.

Here are some linkingerrors with qemu:

/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglInitialize'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `XMatchVisualInfo'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglDestroyContext'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglCreateContext'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `XOpenDisplay'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglMakeCurrent'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglSwapBuffers'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglDestroySurface'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglGetError'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglBindAPI'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglGetDisplay'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglCreateWindowSurface'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglChooseConfig'

 

[Pickle]

Tried to build it in sebt3's toolchain.

Here are some linkingerrors with qemu:


/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglInitialize'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `XMatchVisualInfo'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglDestroyContext'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglCreateContext'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `XOpenDisplay'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglMakeCurrent'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglSwapBuffers'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglDestroySurface'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglGetError'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglBindAPI'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglGetDisplay'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglCreateWindowSurface'
/mnt/utmp/wineemu/lib/libglhost.so: undefined reference to `eglChooseConfig'

Make sure you have -lGLES_CM -lIMGegl -lEGL -lsrv_um -lX11 -lXau -lXdmcp?

 

[elvissteinjr]

I got an application wanting at least 800x600 as resolution, even though I'm sure it would do fine with the 800x480.
Is there a way to fake the resolution? All I found about that was starting it in desktop mode, which doesn't seem to work.

 

[rohezal]

If this problem persists, maybe all output could be rendered to a texture. Then scale the texture and copy it to the screen buffer. This is some overhead and I am not sure if it is possible.

 

[mcobit]

qemu/qom/object.c:686: undefined reference to `__sync_fetch_and_add_4'

Hmmm, seems like I need a newer gcc anyway...

I got an application wanting at least 800x600 as resolution, even though I'm sure it would do fine with the 800x480.


Is there a way to fake the resolution? All I found about that was starting it in desktop mode, which doesn't seem to work.

Qemu actually has a scaler when rendering to a SDL surface, but it doesn't seem to work for GL?

 

[lunixbochs]

Qemu doesn't have anything like that in user mode. The client app is just connecting to your X server directly. We'd need to patch WINE.

No point speculating about difficulty of PND. I only dropped SZ support because it would be too annoying during development.

There's no technical reason why I can't bring it back with a bit of work and find a way to put this into a PND. It's completely feasible.

There will be a release for the latest OS when I'm ready, whether that be .next or SuperZaxxon. Just be patient.

 

[ingoreis]

/usr/local/lib needs to be in either /etc/ld.so.conf or

export LD_LIBRARY_PATH=/usr/local/lib

Full list of important variables:


export LIBGL_FB=1
export PATH="/usr/local/binPATH"
export LD_LIBRARY_PATH=/usr/local/lib
export QEMU_CPU=core2duo

That was exactly the Information what i needed

But i had little more Performance when i set the CPU to CoreDuo not Core2Duo

 

[Solstar]

can you guys please try out these games for me?

Hunter Hunted,made by sierra

Hyperblade,made by activision (its in 3d,in case you need to know)

Command and conquer tiberian sun or red alert 2

 

[lunixbochs]

General rule: if it's around 100MHz system requirements and in the winehq appdb as "supported", it will work now or eventually.

 

[ingoreis]

General rule: if it's around 100MHz system requirements and in the winehq appdb as "supported", it will work now or eventually.

And with 3D Acceleration can we maybe play Final Fantasy 7 PC Version.

The Characters there have Mouths

 

[Askarus]

General rule: if it's around 100MHz system requirements and in the winehq appdb as "supported", it will work now or eventually.

That doesn't sound much to me.

Does Quemu need so much power that we can't get more than 100MHz in the end?

 

[lunixbochs]

It's mostly the floating point emulation. I've heard it gets closer to 1/4 power with non-fpu-related code.

However, games tend to rely pretty heavily on floating point code.

Take a look at the Jazz Jackrabbit demo and remember it's slated for 90MHz system requirements.

We might get further into the 150MHz+ range for WINE when I bring more of the DirectX code to the host.

 

[Rockthesmurf]

I guess it would be somewhat interesting to see an 'intense' block of FPU code, both the X86 version and the generated ARM version, to try and get a better idea why the speed is 10X slower (is it X86 instructions that don't translate directly over to ARM instructions, is it register usage, is it MMX/SSE/etc. instructions, is it load/stores due to cache differences, is it something completely different). I guess there are very few people here that can actually help improve this, but at least knowing the issue would be interesting.

 

[Solstar]

General rule: if it's around 100MHz system requirements and in the winehq appdb as "supported", it will work now or eventually.

i don't know how to install this wine on superzaxxon,thus i cannot even try the games,let alone see the compatibility,that's why i asked

 

[lunixbochs]

I guess it would be somewhat interesting to see an 'intense' block of FPU code, both the X86 version and the generated ARM version, to try and get a better idea why the speed is 10X slower (is it X86 instructions that don't translate directly over to ARM instructions, is it register usage, is it MMX/SSE/etc. instructions, is it load/stores due to cache differences, is it something completely different). I guess there are very few people here that can actually help improve this, but at least knowing the issue would be interesting.

I already looked into this a bit. From initial investigation, the floating point emulation is somewhat *accurate* to the target cpu. There are a few layers of abstraction, but I can come up with a simple test to see exactly before/after. 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

 

[rohezal]

We could probably hack this to be fast for our case.

An other idea was to catch loaded libs like direct x math libs and replace their functions with the native arm code. Would this be possible inside wine or even outside? Something like:

app.exe load -> directx.dll (catched) -> load directx.arm.so

Would this even be possible or would it not work?

 

[lunixbochs]

I've already addressed this.

Like when you said:

But if you could do something like catching the call of fake direct3d lib with the call and handle it in ARM space and write the results in x86 space

and I responded

I don't yet have a good path for loading WINE DLLs into the qemu host, so I can't use native versions yet.

It's not high on my list.