VOGONS


Reply 200 of 386, by ruthan

User metadata
Rank Oldbie
Rank
Oldbie

Otherwise Qemu is one of the most ambitious software projects.

In theory you could do great things with it emulate and run any major architecture sw on any architecture hw, but it reality its very problematic. One of my dreams is for example run emulated Windows and Crysis on very powerfull Power IBM server.. but i far i know nobody did it, its niche.

For example there is Limbo which is able to run Windows on android, i have some Android x86 machine, which is ideal for that, i can install Windows 98 or XP into run, its runns, but otherwise control it etc, its every akward.. Same on ARM phone, its running but its slow even for 2D stuff.
QEMU was used for some Raspberry PI machine emulation, for developement, but i dont thing its was enough for gaming.
There was some try to make Xbox 360 (PPC) based on QEMU, but it failed.
There is not good QEMU windows GUI - Frontend for machine settings for years.
Networking is realised though some strange TAP bridge, which was always awkward on WIndows when i tried it.
At the start there some Android virtual machines based on QEMU, but Bluestacks and similar are now much better than made them obsolete.

So far i know only about 1 sucessfull project using some QEMU stuff that its Unraid, which is using some its technology beside KVM, but i never undestood low level details.

QEMU really sucks a lot in comparision with classic user friendly stuff as Virtual Box,Vmware, Paralells and when you try to run x86 virtual machine on x86 machine, its even much slower that these.

Im old goal oriented goatman, i care about facts and freedom, not about egos+prejudices. Hoarding=sickness. If you want respect, gain it by your behavior. I hate stupid SW limits, SW=virtual world, everything should be possible if you have enough raw HW.

Reply 202 of 386, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
robertmo wrote:

kjliew what about a key press to show/hide 2D elements.

Isn't this already partially implemented for games that support this, such as Pandy1?
It is partially implemented because there is no window sizing when switching in and out of 3D. QEMU 2D rendering will shrink and fit into the window size of 3D resolution, most of the cases this is either 640x480 or 800x600. Not many games actually need this to play, probably just need to show the 2D GUI menu to configure inputs and quit the game gracefully.

Reply 203 of 386, by robertmo

User metadata
Rank l33t++
Rank
l33t++

Figured out how to solve distorted sound/music problem in Pyl in DOS when using highest sound quality set in game's setups (including 3D sound).

First you need to speed up boot process:
Use dos version without start menu.
Scrolling slows down boot, so use the autoexec.bat/config.sys settings I described before for removing scrolling.
Add SWITCHES=/F to config.sys to remove boot delay
Add pyl.exe to autoexec.bat so you don't have to type it manually.

All above makes the game start almost immediately with the start of qemu and also makes it easy to test.

Using qemu with:
-vga cirrus
It makes Pyl have clear sound almost always.
cirrus trick works best with HAXM.
Note that cirrus works only with glide mode and will freeze your pc if you use it in software mode and you will have to reboot.

Reply 204 of 386, by Glidos

User metadata
Rank l33t
Rank
l33t

Thanks robertmo for drawing my attention to this. Very interesting. kjliew, I particularly enjoyed reading how you just wanted to play a particular game with accelerated 3D and sort of got carried away. Exactly how Glidos came about.

Reply 206 of 386, by digger

User metadata
Rank Member
Rank
Member

Brilliant work, kjliew! 😀

As for the LFB performance issue, could that perhaps be solved by passing through an actual (S)VGA graphics card to the guest, along with the Voodoo card? That would solve the last remaining major bottleneck for running such games on modern systems, right?

Reply 208 of 386, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
robertmo wrote:

It looks Pyl has very washed out colours if you compare it to dosbox. I checked real agp voodoo 3 on athlon 2000+ and it looks like in dosbox.

Yes, I did notice that. I don't know how to fix it yet. I need to check LfbHandler=1 behaviors to compare with DOSBox. I think it has something to do with Fog. If the washed out colors was gone with LfbHandler=1, then there is something with how the depth buffer shared memory was initialized and read back.

Reply 209 of 386, by robertmo

User metadata
Rank l33t++
Rank
l33t++

Washed out colors is wrong expression here cause it may suggest white tint.
Pyl is simply way darker in qemu.
I also think it has nothing to do with distance fog as it only makes distant elements not being displayed to reduce cpu usage.

Reply 210 of 386, by robertmo

User metadata
Rank l33t++
Rank
l33t++

I noticed now that distance fog indeed works differently in dosbox and qemu:
while qemu immediately turns off distant textures,
dosbox is slightly dimming them.
so if dosbox can dim textures down it may also have them enlighted as default.
So I guess fog may be the reason indeed 😉

Reply 212 of 386, by Glidos

User metadata
Rank l33t
Rank
l33t

I've run into problems with fog in psVoodoo that showed up in Redguard. I never managed to make psVoodoo work as well as OpenGlide in that respect. Is the game applying fog to polygons with points that differ by large amounts in z?

Reply 213 of 386, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
Glidos wrote:

I've run into problems with fog in psVoodoo that showed up in Redguard. I never managed to make psVoodoo work as well as OpenGlide in that respect. Is the game applying fog to polygons with points that differ by large amounts in z?

I do have Fog working in psVoodoo for Redguard, but it renders slightly different from OpenGlide. Both dgVoodoo1 & dgVoodoo2 Fog also renders slightly different from OpenGlide. IIRC from dgVoodoo1 source code, the grguFog* are exact copy from 3Dfx DLL source code. I ported the same for psVoodoo. OpenGlide implements grguFog* quite differently from 3Dfx DLL source, and when I replaced the codes with 3Dfx DLL source, they didn't work out as nice as the originals.

However, OpenGlide Fog implementation is flawed with Titanium series Mechwarriors. On the other hand, psVoodoo and dgVoodoos' are fine.

Have you checked out the patch I submitted some time ago?
psVoodoo improvements

I have made several small improvements since then. I will re-submit the patch shortly.

Reply 214 of 386, by robertmo

User metadata
Rank l33t++
Rank
l33t++
robertmo wrote:

I noticed now that distance fog indeed works differently in dosbox and qemu:
while qemu immediately turns off distant textures,
dosbox is slightly dimming them.

Fixed with your new glide2x.ovl

Reply 216 of 386, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Project moved to GitHub.
The first committed source has the following improvements over 20190525 release.

  • Update ScaleWidth to scale at any resolution with the same aspect ratio.
  • Linux plumbing for libglide3x.so
  • Glide3x guest wrapper fix for games that forget to call grSstWinClose before grGlideShutdown.

Reply 218 of 386, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

This will be the last release update post in the thread. In future, please monitor the commits in GitHub.
For ideas, issues and assistance, you are welcome to continue using this thread, start a new thread or just use GitHub. I hope this would work for everyone. 😀
I sincerely thank everyone who shows interests and finds my work useful!

Reply 219 of 386, by RaVeN-05

User metadata
Rank Member
Rank
Member

Great Project! =))

https://hexenworld.org/forum/index.php (Heretic's & HeXen's forum)
https://www.youtube.com/user/whitemagicraven
https://go.twitch.tv/whitemagicraventv