First post, by robertmo
- Rank
- l33t++
Pył, Pyl, Dust is finally playable in English with 3dfx (glide) in Qemu with dgvoodoo2 in Win7/8/8.1/10
English translation:
Pył, Pyl, Dust English language version
Pył, Pyl, Dust is finally playable in English with 3dfx (glide) in Qemu with dgvoodoo2 in Win7/8/8.1/10
English translation:
Pył, Pyl, Dust English language version
Thanks !
This game looks very interesting. 3DFX DOS Glide support is always a treat.
Too bad I can't find it on ebay onr some other website. Any hope for a poor Western European ?
Nice!
I cannot try it now, and in the other thread I read it has a quite good performance through QEmu.
But, how it feels compared to DosBox?
A few years ago I played this game through DosBox+dgVoodoo (with fast vidmem access because of very frequent LFB readbacks) and mostly it played fine. (To the end of the first level and then it always exited complaining about some missing file. 😀 )
Someone made a playthrough video (mixed dgVoodoo / nGlide):
i5-3450, 660 Ti
resolution 1600x1200
Using max graphical settings with max sound settings at the beginning without moving mouse.
(I set longer view distance and higher textures quality by hex editing menu.set)
dosbox daum (2015 january 03)
lfb=full
17fps
lfb=full_noaux or write or write_noaux
30fps
qemu haxm
LfbNoAux,0
55fps
LfbNoAux,1
172fps
If you turn on scope with minimum zoom and stand in a corner of a large room and look into the opposite top corner of the room (it is the location from the screenshot, beginning of third level)
dosbox daum (2015 january 03)
lfb=full
1fps
lfb=full_noaux or write or write_noaux
2fps
qemu haxm
LfbNoAux,0
15fps
LfbNoAux,1
15fps
Was wondering if it would be possible to add some hack to dgvoodoo so that pyl doesn't display black bars on top and bottom on panoramic monitors.
Doesn't resolution forcing work with Qemu or DOSBox? Resolution forcing should allow you to eliminate black bars.
I think that's more of the problem for QEMU 3Dfx. Existing version "ScaleWidth" option can only scale on Glide resolution and max out at 1600x1200. I have since removed such limitation and my local version can scale at any resolution at the same aspect ratio, for example, 1440x1080 for 4:3. I don't know about panoramic display (I don't have one), scaling 4:3 into 16:9 display should only give you black bars on the sides, assuming that you can fully utilize the vertical height. Perhaps this would be able to remove the top and bottom black bars if your panoramic display vertical height can be fully utilized in scaling.
BTW, what's the native resolution of your panoramic display?
wrote:Was wondering if it would be possible to add some hack to dgvoodoo so that pyl doesn't display black bars on top and bottom on panoramic monitors.
If I guess it right, the problem is that Pyl runs in a 4:3 resolution but renders only into a 16:10 (or 16:9 ?) subrect inside it (except the main menu).
So, on a widescreen monitor you have black bars on all sides (left, top, right, bottom), but it'd be cool to stretch the effective region to fully fit into the display instead (with aspect ratio kept).
Not Pyl is the only app affected and this can be very annoying.
However I had no idea how to handle it. An 'internal aspect ratio' could be defined in the config but what if the needed AR doesn't match exactly any of the usual 16:9, 16:10, etc. AR's but it's a custom one instead, and, what if the game renders at multiple AR's like Pyl (4:3 for the menu, 16:10 for ingame)?
Is there a guide to setting up QEMU w/ this Glide Pass-through support?
The case of Pyl is rather easy as it uses typical 640:400 AR. And the menu shouldn't be a problem as it doesn't contain any information in top and bottom parts so they don't have to be visible. If the menu is stretched to a different aspect nothing wrong should happen too I guess.
As for other games with similar problem:
If they are even more panoramic they would be enhanced by this feature anyway.
If they are less panoramic, you won't have to use this feature with them.
Of course if we find a game, appropriate AR may be added in dgvoodoo's menu. And that extra option may enhance even more games too. And I guess we can live with those thin black lines still left at top and bottom of some games 😉
...till someone asks for making text from here http://www.zeus-software.com/img/galleries/ng … e/specops_b.jpg
as a OSD (HUD) 😉
wrote:Is there a guide to setting up QEMU w/ this Glide Pass-through support?
Plz try dgVoodoo WIP65. I added an option for defining a subrectangle for the output.
Pyl seems to render into 640x380, so I tried it with 640:380 aspect ratio and it worked nice.
It works but I think something is wrong.
Pył has active picture of 640x400
So when I set dgvoodoo to generate a picture of:
Resolution = h:1728, v:1296
And ask it to cut it down to:
DisplayROI = (1728|1080), pos:(0|108)
It should give me perfect sharp pixels.
But it doesn't 😀
Picture is blurred (both: menu/hud and edges of 3d elements)
BTW I had to add 1728x1296 and 1728x1080 resolutions in nvidia control panel
I guess the reason for blurred image is that dgvoodoo is displaying 1728x1080 image in 1728x1296 upscaled (blurred)
While is should simply display it in 1728x1080 unchanged.
The best would be if dgvoodoo could work this way:
I set my desktop resolution here:
Resolution = h:1920, v:1080
I set that I am interested in region:
(640|400)
and dgvoodoo automatically calculates that it needs to generate a picture of 1728x1296
then generates a pirture of 1728x1296
then cuts it down to 1728x1080
and finally displays it in 1920x1080 adding black bars on the sides (left and right).
What scaling mode do you use it width? Display ROI is intended to be available only with scaling modes with 'Stretched, * aspect ratio' and 'Centered, keep aspect ratio'.
Plain 'unspecified', 'stretched' or 'centered' aren't supposed to work. If they do, then it's a bug. 😀 (I disabled display ROI for them because of the emulated cursor in DX.)
Also, ROI rect must be specified in forced resolution space (not application resolution) in the current version. The subimage is simply stretched (or centered) to fill the display, according to the scaling mode.
Maybe changing the behavior, like specifying the rect in app resolution space then taking it into account for auto-calculated resolutions would be better, I'll consider it.
OK, works fine now 😀
What about Qemu? 😉
Umm, I didn't test it with QEmu, but I think it should work there too.
QEmu works for me like it is ignoring ROI setting
Did you try it in fullscreen mode?
Display ROI is available only
- in fullscreen
- windowed mode with 'Fullscreen size' attribute enabled
because in plain windowed mode there are no extra black bars rendered which means that the aspect ratio of the window is (can be) different from fullscreen.
Starting in fullscreen mode somehow doesn't want to start but i figured out how to do it starting in window mode:
DisplayROI = (1728|1080), pos:centered
Environment =
Resolution = h:1728, v:1296
Start qemu, start pyl
switch dgvoodoo to fullscreen (alt-enter)
Works perfectly 😀