P.S. Dont forget read my previous post =).

I think Pyl designed for Voodoo 1 card , so anyone can test it? The next idea i want to try DOS32A extender for this game.

from cfg: (perf = performance change +- , inc = increase)

fog_distance (no perf, by logic less fog more fps?)
resolution (no perf, lowering more fps?)
textures quality (0=max 4=min) (no perf, should be 4 more fps, but no again)
textures facture on(def) (no perf, should increase fps by turning off, its detailed textures)
shadows on (default) (no perf, should inc fps if turned off)
*aim (no perf, turned off should inc fps, what a good option on is onscreen crosshair)
*lens effect (PERF!!!, turned off is increase fps in case if you use sniper scope, if you change to night vision it again drops fps, it turns off glass distortion, fps drops in animations when you turn it on and off)

Also the game seems don't have any 3dfx msdos variables like we use in bat files before start game.
SET SST_... VALUE
SET FX_... VALUE
SET BUILD_... VALUE

Placing glide2x.ovl from Voodoo1 drivers doenot give anything, game don't want start.

P.S. Well dos32a failed here, or i use it incorectly , last version fail, first ever failed , i not tried between versions http://download.narechk.net/

fog_distance=viewable distance from game's menu - you can just set it more in the file

mouse options are better explained in a .txt file of my translation

fog_distance - decreasing far of distance should gain fps?

readed .txt's
well need to examine that game deeper =)

From demo version of pyl, readme

2. Hardware requirements […]
Show full quote

2. Hardware requirements

Windows 95 or Windows 98
Pentium 133 Mhz processor
32 MB RAM memory
150 MB free hard disk space
SVGA graphics card compatible with the VESA 2.0 standard
Sound Blaster sound card or 100% compatible with it
Quadruple speed CD-ROM
mouse
a 3D graphics accelerator based on the 3Dfx processor (Voodoo, Voodoo Rush, Voodoo2) is recommended

Seems we already can meet these, need look what system needed for full version i think the same.

I use http://www.split-code.com/strings2.html to extract strings , to look more infos.

in PYLSETUP.EXE one word in polish Siekiera which is "Axe" 🤣

in attachment:
pyldemo.exe some strings, suspicious to me.

game compiled by WATCOM 16or32?
it compiled on/and designed for Intel CPU

pyl something like anabioz , what great PC you get is not enough, mystery must be solved by black magic hex editor expert

There is list of Glide2x externals, maybe some drawing calls cause slowdowns? modify or remove , for experiements.

there is command line parameters, more that /HELP switch give us. But they seems not work =(

game uses DPMI memory ? (HIMEM?) sorry not expert here, probably CWSDPMI or HDPMI32 -r can help? or simply Win98 raising DPMI memory.

LINEXE_ ? linear executable.

.ovl
PATH
C:\WINDOWS\SYSTEM\

it means you can copy ovl into game dir or in path dir and play without win and drivers in emulators?

Banked or Linear mode which faster and we need it for 3dfx Pyl? (LFB vs BANKED?)
VBE2 VESA, need to experiement with there resident drivers
VORTEX hmm , i think its not relative to Aureal cards =)

LIGHTMODE
LOW ??? (other value HI)

game uses real mode? no way its dos4gw should be protected

so pyl developed using c++

sorry looks like spam, but i realy interested in that game and want dig deep. =)

start:
200 fps

back touching closed door:
140 fps with spiders and soldier
240 fps without spiders and no soldier

The game has 3D sound so it might be using aureal vortex 3D.
You can hear it best at the beginning in the second room in the corner there is water pouring through the opening in the ceiling.

how you archieve that hi fps?

kjliew just updated his QEMU 3Dfx Glide Pass-Through with lights shining through walls feature with fps increase as a side effect 😉

I can do more optimization by merging the LFB writes to help gaining playable frame rate for OpenGlide, especially for Linux KVM. DgVoodoo2 is probably doing this in a very intelligent way that would offload the pixels pushing to GPU.

Anyway, I need someone to play through this game and conclude that having lights shining through walls is the only visual artifact by dismissing AUX/DEPTH locks. The overall game play is not impacted. Otherwise, it is pointless to optimize to the point that it would affect game play, for eg. if some traps/items/switches/levels would become invisible.

the game was intended to be realistic.
lights shining through walls are not.
they are also a spoiler as they kind of reveal parts of map not explored yet.
also lights shining into your eyes make it harder to look around.
when you enter the second room there is a message that you can destroy lights to be able to sneak.
Destroying lights make the room dark for you too.
there are also lights in the same room but just hidden by some elements of the room.
having lights shining behind walls may be misleading.
Some lights are already kind of partially visible hence it is hard to destroy them.
I already know more less how these lights work, but if you don't know game's mechanics...
Try destroying lights and you will know a bit more of what i mean.

On the other hand you can always turn the feature off.

I finished the game a few years ago and don't think they will make the game unfinishable.

Or need to dig, and figure-out, how to remove flare texture, or even flares mechanics (coded) so it goes draw faster? even without qemu fake lfb feature?

Any way Fake LFB great , must have , just option on or off =)

I decided to go ahead with the LFB writes optimization since this also improves OpenGlide compatibility with other games, especially Archimedean Dynasty. With LFB write merge, it is now possible to have playable frame rate (35~50fps) on Core-i7-6600U with OpenGlide in KVM and WHPX. Core-i3-4010U can barely make it in KVM at 22~27fps and frame rate would tank in single digit in action.

However, there is an additional visual artifact with LFB write merge, the greenish lens effect with aim pointer on scope is gone. Night vision and zoom are OK. So one will have to just imagine the center of the scope to pin-point the target. Fog can be disabled in OpenGlide to light up the textures and reduce the contrast of lights shining through walls. Anyway, this is all we got for playing the game in Linux KVM.

Playing with dgVoodoo2 on Windows with a BIG, FAT GPU is still the best for this game.

you may call 660 ti big and fat but i guess 1030 or the coming 2030 are not 😉

Firtasik wrote:

Pył is being converted to Unity Engine: https://www.youtube.com/watch?feature=player_ … d&v=V0ehfC5Yx4c […]
Show full quote

Pył is being converted to Unity Engine:
https://www.youtube.com/watch?feature=player_ … d&v=V0ehfC5Yx4c

More info:
http://pyl1998.wordpress.com/dust-1998-201x/

Update: project is closed.

😵

RaVeN-05 wrote:

i tried Pyl on real hardware Pentium 2 350Mhz + Voodoo2 8mb seems not enough for better fps, does game designed that bad way?

Yes, it was a crap/paździerz. Dos only Glide only Quake 1 clone build on 3d engine written by first timer while working on his midterm exams, and released in 1999 by incidental "hey, we manufacture millions of computers per month lets branch out to development" publisher of low budget edutainment pre-install shovelware (software whose sole purpose was padding value of Optimus computers sold to edu segment in Poland).
I only remember this game from gaming magazines (something about being shit quake clone), never knew personally anyone who either played or owned it, didnt even see it listed by pirates. Sad state of affairs really.

not bad, i like this game , the good idea with crap tech/realization, with qemu 3dfx pass trough kjliew fixed this game to run 60+ fps with one artifact - flares draws through walls, anyway need to remove that flare texture or even find way to disable it in exe, cut off that functionality. And it becomes good game with good fps =)

p.s. Chasm the rift also considered as quake clone but also very good game, and it have more love now trough PanzerChasm project.

A challenge to everyone:

Get to the roof of the hovercraft from the centre of the picture from the third post of this thread 😀

I did it 😀

RaVeN-05 wrote:

need to remove that flare texture

you can shoot them 😉

@robertmo
Hi, finally I was able to nail down the artifact that fire can be seen through moving door. Basically the artifact was caused by reusing the same depth buffer without refilling on every lock before swap (sort of optimization for 1 fill per frame). So I corrected the AUX/DEPTH handling to refill the shared memory on every lock and now the rendering was correct, but it cost a few frames.
Here's the patch, please check it out and confirm the fix for other places. I only checked the door on the initial level.

Update: remove the patch. I have pushed the changes into GitHub with a new configuration option for more accurate LFB shared memory semantics (at some performance loss).

it works 😀

here you have a package for uber busy guys with no time to read 😉
just insert the cd 😀