Hmm, other big+ for PCem..
If something is wondering which game they are there is list with this info:
DOS Glide Games List
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.
Ok, i tested all Dos 3dfx games, which i could to easy others i dont have or their setup is annoying (Lands Of Lore 2), or i dont want to play them.
It would make sense test other not 3dfx games, because so far no good? Is there any idea why games like Doom or Golden Axe are too slow?
Regardless of compatibility, which is should be main goal, i expected better performance, dont really know if these games are so badly designed that even with overpowered CPU+GPU still have lots performance drops (30-60 FPS), or its problem of Qemu 3dfx.. it would need somehow measure performance of PCem or real machines frame analysis to compare, good is that everything what is working is playable.
- RedGuard demo - I read that , at least for someone in the past it worked.
- Shadow Warrior has only broken palete which a guess would be hard to fix.
- Blood3Dfx also worked in the past for someone.
- Tomb Raider - im not sure if there is demo without static link?
- Q1DOS and Q2DOS and H2DOS all using own Dos glide impelemtation which is not compatibile with this build, that is the shame, because if performance is there, they can give as high res with V4/F5 emulation..
With these performance results not 60 FPS lock.. PCem is cleary better solution, if you have powerfull CPU - 2D games / programs are working fine, 3dfx in 640x480 are working fast enough and all 3dfx games are working (static links) also setup is easier. Its still good to have alternative and ARM port.
Main advance of Qemu 3Dfx would be i hope in Windows 98 and high res.. but it could work (make sense) only if its overall setup would be less PITA than make these games working on new OSes with dgVoodoo and nGLide and other fan patches, so of them are great. Of course on Linux you have not other choice than this or Wine.
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.
ruthan wrote on 2021-02-04, 01:09:Ok, i tested all Dos 3dfx games, which i could to easy others i dont have or their setup is annoying (Lands Of Lore 2), or i don […]
Ok, i tested all Dos 3dfx games, which i could to easy others i dont have or their setup is annoying (Lands Of Lore 2), or i dont want to play them.
It would make sense test other not 3dfx games, because so far no good? Is there any idea why games like Doom or Golden Axe are too slow?Regardless of compatibility, which is should be main goal, i expected better performance, dont really know if these games are so badly designed that even with overpowered CPU+GPU still have lots performance drops (30-60 FPS), or its problem of Qemu 3dfx.. it would need somehow measure performance of PCem or real machines frame analysis to compare, good is that everything what is working is playable.
- RedGuard demo - I read that , at least for someone in the past it worked.
- Shadow Warrior has only broken palete which a guess would be hard to fix.
- Blood3Dfx also worked in the past for someone.
- Tomb Raider - im not sure if there is demo without static link?
- Q1DOS and Q2DOS and H2DOS all using own Dos glide impelemtation which is not compatibile with this build, that is the shame, because if performance is there, they can give as high res with V4/V5 emulation..With these performance results not 60 FPS lock.. PCem is cleary better solution, if you have powerfull CPU - 2D games / programs are working fine, 3dfx in 640x480 are working fast enough and all 3dfx games are working (static links) also setup is easier. Its still good to have alternative and ARM port.
Main advance of Qemu 3Dfx would be i hope in Windows 98 and high res.. but it could work (make sense) only if its overall setup would be less PITA than make these games working on new OSes with dgVoodoo and nGLide and other fan patches, so of them are great. Of course on Linux you have not other choice than this or Wine.
Give yourself a break and just use PCem. No one cares about the comparison, commentary or judgement from those who can't properly build QEMU themselves. PCem is the greatest piece of software in existence when QEMU is way out of one's league. Another Big+ for PCem. Have fun and play some games 😀, don't bother with QEMU.
Voodoo4/Voodoo5 is nothing compared to the 6 years old Intel HD Graphics 515 in Core m3 6Y30 at 8W TDP, a privilege for those who take the advantage of QEMU virtualization or willing to spend the time and patience to learn how to build and use it. Otherwise, have fun with PCem and be grateful to the performance of Pentium II 300MHz and Voodoo3. 🤣 Just go to my YouTube channel, open your eyes and watch for yourself Q1DOS and Q2DOS. All performance stats are clear & vivid, instead of PCem fanboy simply claiming 60 FPS without displaying stats on YouTube video. I am not eager to show DOS Glide games on QEMU because I strongly believe DOSBox is still the best for DOS games (even without virtualization) for its Sound/MIDI and DOS IPX tunneling support. PYL is probably the only exception that greatly favors QEMU due to virtualization.
When you didn't have the knowledge to make things work and yet made poor judgement out of them, you are just making a fool out of yourself.
If you want to measure performance stats with Carmageddon 1 3Dfx, then press key "i" during race. The line containing FPS will show up in the middle of the screen.There are 2 3Dfx modes for Carmageddon with the correct 3Dfx Voodoo2 patch (voodo2c.exe), '-vgraphics' and '-vrush' modes. The default is '-vgraphics' mode which dgVoodoo2 has trouble with the HUD but works fine with '-vrush' mode. In '-vgraphics' mode, QEMU and OpenGlide deliver 60 FPS locked on Core m3 6Y30 on both Windows 10 and Linux. Try out both modes on PCem with Core i9 and don't be shy to tell me how well it performed on Core i9. Post a few screenshots please, if you don't mind. 30 FPS is all you need and I am pretty sure Core i9 5GHz will be able to make it. 🤣
ruthan wrote on 2021-02-03, 22:20:The opengl32.dll stub you mentioned is for MesaGL, so it's needed if the game uses OpenGL or Direct3D. Where it should reside in the guest, depends on the guest Windows version.
So if you have a Win98 guest, it goes to Windows\System. Win2k and WinXP can make use of it directly in the game directory, I think.Hi, well robertmo just posted some package of files, without any info.. i had to guess. This file is new one for with Qemu 3Dfx build..
Main thing is it could be used with Windows, because MesaGL is Linux thing.. Otherwise OpenGL32 is in Win98+ always in system32 from its install time.. but some games have their own, drivers too and sometimes is needed to overwrite them, but i asked its always better, maybe its just thing why i can ignore.
The purpose of opengl32.dll stub is to direct any opengl calls to the host opengl, whatever it may be called (yes, on Linux it is Mesa). If you don't have the stub in place, the calls will end up for the guest (software rendering).
Btw I always had this dll in the system directory (in a win98 guest) and not system32. The messages on the qemu console make it easy to spot if there are problems with the stub placement.
ruthan wrote on 2021-02-03, 18:34:New version of Qemu again messed with commands, other thing which i really hate on these low level stuff with bad architecture ( […]
New version of Qemu again messed with commands, other thing which i really hate on these low level stuff with bad architecture (from used perspective, they change this in some internal logic, not on user level, without backward compatibility mod switch..), how i suppose to enable pc speaker on windows? In doc is this:
-audiodev <backend>,id=<name> -machine pcspk-audiodev=<name>
On Windows we dont live in world of ids and same soundback.. it just working.
I tried and failed:
-machine pcspk-audiodev=dsound,id=onboard ^
My understanding is that the end users aren't supposed to mess with the qemu command line directly, but use the virt-* tools instead.
I've always found it more straightforward to use command line, however. So I can't really say how stable those tools are. It's an extra layer of complexity, added on top of already complex software.
(=Kind of invitation to bugs is my thinking).
ruthan wrote on 2021-02-04, 01:09:Of course on Linux you have not other choice than this or Wine.
Wine is great when it works, but it isn't always an option. For example some nasty drm-in-kernel schemes can stop it in its tracks.
Give yourself a break and just use PCem. No one cares about the comparison, commentary or judgement from those who can't properly build QEMU themselves. PCem is the greatest piece of software in existence when QEMU is way out of one's league. Another Big+ for PCem. Have fun and play some games 😀, don't bother with QEMU.
You are continuing behaving like typical superstark jerk - offend own product users and call them fanboys of competitive products checkboxes checked.. I asked you before about important things you just ignored it... just you ignoring alot of technical questions in whole thread history. Try find one 1 post on PCem form, which could be called as from fanboy, im using same nick, you will find same "annoying" questions, ideas and problems reports like here.
Voodoo4/Voodoo5 is nothing compared to the 6 years old Intel HD Graphics 515 in Core m3 6Y30 at 8W TDP, a privilege for those who take the advantage of QEMU virtualization or willing to spend the time and patience to learn how to build and use it
You are wrong, you didnt get message.. Its was about Voodoo 4/5 emulation speed, that it would be nice just speed with Qemu 3dfx.. you find only in your head, in your own reality that talked about some real machine speed, to call me stupid.
Just go to my YouTube channel, open your eyes and watch for yourself Q1DOS and Q2DOS. All performance stats are clear & vivid, instead of PCem fanboy simply claiming 60 FPS without displaying stats on YouTube video.
You problem is that you trying to make reviews of you products => because communication with you is so complicated, nobody else independent can make these videos, because is not working for nobody else.. You are offending people, instead communication on technical level, for me Q1Dos and Q2Dos are crashing.. for you are things working, my setup has to be different (at least you are running everything on Linux, i dont).. but there nowhere any guide how to do it.. only bla, bla how users is stupid and i dont have enough knowledge etc.
Which OpenGl Dos driver, you used? FXmesa, Mesa, Sage? Do you know anybody who tested it on Windows 10? If yes with which build, did you retest that from RobertMO, before calling users anybody fool?
I gave you most transparent review as possible - online sheet with editing access for anybody who wants, here is what is working and what not and if is not working, there is problem description.. anybody can retest it, or write what is wrong with my setup, to make results better.
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.
My understanding is that the end users aren't supposed to mess with the qemu command line directly, but use the virt-* tools instead.
Virtmanager is only for Linux and it has lots of missing options.. its not integral part of Qemu product like, in case of Vbox or Vmware.
I've always found it more straightforward to use command line, however. So I can't really say how stable those tools are. It's an extra layer of complexity, added on top of already complex software.
(=Kind of invitation to bugs is my thinking).
Whole personal computers and smart phones, devices revolution is based on gui.. commands are slower to process, need to be remembered in advance and required much more concertation.
Problem is you can have quite robust great code inside of application but if at the end is some stupid parser to process user commands or some fragile text file configs most of robustness of it is thrown away when user has to input something. On GUI you have much better control of it - you use comboboxes, checkboxes, ratio buttons, input filter patters.. events to disable, enable some elements, depends on other options, checks after every keypress is input value is compatible. Its simply better, more intuitive and error proof and more time and user energy efficient.
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.
ruthan wrote on 2021-02-04, 14:43:Virtmanager is only for Linux and it has lots of missing options.. its not integral part of Qemu product like, in case of Vbox o […]
My understanding is that the end users aren't supposed to mess with the qemu command line directly, but use the virt-* tools instead.
Virtmanager is only for Linux and it has lots of missing options.. its not integral part of Qemu product like, in case of Vbox or Vmware.
I've always found it more straightforward to use command line, however. So I can't really say how stable those tools are. It's an extra layer of complexity, added on top of already complex software.
(=Kind of invitation to bugs is my thinking).Whole personal computers and smart phones, devices revolution is based on gui.. commands are slower to process, need to be remembered in advance and required much more concertation.
Problem is you can have quite robust great code inside of application but if at the end is some stupid parser to process user commands or some fragile text file configs most of robustness of it is thrown away when user has to input something. On GUI you have much better control of it - you use comboboxes, checkboxes, ratio buttons, input filter patters.. events to disable, enable some elements, depends on other options, checks after every keypress is input value is compatible. Its simply better, more intuitive and error proof and more time and user energy efficient.
Yeah with much of the Linux software if there is a Windows port at all, it's only done as an afterthought.
If the project is volunteer based, you'd need some volunteer Windows devs to get anything better than that...or, if there is a commercial angle to the sw, you'd need a sufficient clientele there to justify the expenditure.
(How many Windows users even know of QEMU? Outside of VOGONs of course...VOGONers have probably been slapped to their face with QEMU when they least suspected it 😀
From a user pov GUIs are ofc nice to have, but for the devs it's a lot of extra effort that could be better spent elsewhere. It also depends on what has been defined as their "end user".
If you have a large clueless userbase, it makes sense to spend some time to make a "dumb-proof" GUI.
EDIT: By this I mean that a lot of silly mistakes (like typos) can be eliminated with a GUI (not that the users are literally stupid). So there is definitely merit to them, however I don't think cli and GUI are mutually exclusive.
They both have their place. I've been using various clis for a couple of decades, so I may also be somewhat biased 😁
Yeah with much of the Linux software if there is a Windows port at all, it's only done as an afterthought.
If the project is volunteer based, you'd need some volunteer Windows devs to get anything better than that...or, if there is a commercial angle to the sw, you'd need a sufficient clientele there to justify the expenditure.
Yeah, but as developer is good idea also thing about userbase.. and 96% of gamers are still on Windows.. and actually you need to make better product to make users even consider switching. What is even worse compatible product and there are producs like WIne - big have lots of some very old bugs.. and maybe new bug reported and than fixed. Its its not just some free community project lots of companies include Valve is pumping quite a lot money into it, but its bad side of Linux worlds, so developers are probably selecting what to fix and are not fixed to dig into bad stuff as in "normal" companies.
Commercial angle - its absolutely clear, Vmware is one of most successful IT companies, its making lots of money from virtualization, there is lots of money in LPAR, VPAR - HP (HPUX)/ IBM (AIX) own virtualization stack. If would Qemu had same level of quality or reasonable quality / performance ratio + support (look at Red Hat business model is working but its only Linux with actual Windows like support), they could make lots of money on that. And license could be something like that free for anybody, except big companies.
They can make some small money on small users too, i would paid for it, im already paying for Vmware workstation.. i can use VBox, or Qemu instead, but its waste of time, small investment is back in few days of intensive work - because its more stable, running faster, its easier to setup and even games 3D support for new OSes is getting better.
From an user pov GUIs are ofc nice to have, but for the devs it's a lot of extra effort that could be better spent elsewhere. It also depends on what has been defined as their "end user". If you have a large clueless userbase, it makes sense to spend some time to make a "dumb-proof" GUI.
I cant argue that is needs some effort, but 99% of creators and successful products it seems that found out that is worthy to invest time here. There are now lots of developers, designer who are actually specialized in that. Better gui will probably bring you more users, and it means probably more protentional community developers even for non gui things, its clear logic.
Yeah, im maybe biased, but even when i do some parsers and simpler data proccessing stuff, im using some small gui frontend to control it, load data, progress reporting etc.. and where in games forum, text based games, also have small market share.
I will add one more argument, well you know - all these old mainframes - top,ps,vmstat,sar etc commands.. but even there someone is using some text based better GUI like design thinking is just working better - look at htop - use of few simple colors, text menus, asci graphs and views is giving you much better tool.
I really thing that is mainframe like type of thing has to go away, its make more damage than benefit. You can see in Linux market share, text configs and commands, will never work in comparison with some GUI control panels for basic users OS settings.
About dumb users - i would say that is false idea, lack of gui, will you bring actually something. With GUI most of users, can quickly learn to use basic operations and more advanced users still can/ will do more advanced stuff - its not blocker.. and you can able automatization layer on gui layer, same as on command line, its other interface.
About my "stupidity" personally, there are two attitudes how to solve things:
1) simply do lost of research, experimenting, searching
2) asking..
First option has problem, that you are assume lots of things, why i ask, i would look stupid, to clarify this obvious things.. so i assume this, assume that.. problem is that at the end, you are to do lots of testing of that assumptions on you own, reinventing a wheel.. or you are stuck in classic too many variables (assumption) problem.. Its getter better, if you solving something is some pseudo elite or semi-professional group, when you suppose to understand everything detailly and not wont to show weakness.
In my eyes this attitude is wrong, so im asking, maybe look stupid on the way, not trying to understand to everything, make my own barriers, what is too much, what i don't want to do.. and this often leads to good results with good time / performance ratio.. i see it actuality as clever way, which make good artifact for others to learn, specialization and work effort distributions are good things, but is bad idea to force them on people in areas, which are not like in name of their re-education..
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.
@ruthan: I wouldn't waste my time arguing with them. I've been there, done that. They simply believe they're right and act like a computing superstar.
While in reality they are missing out a great opportunity to bring QEMU to more people, make it more accessible, more gaming friendly and also a real popular replacement for $$$ virtualization software bought by end users, who know sh1t nothing about CLI and building/compiling themselves an app they need: Parallels, VMware...
Only the time will tell for them.
UTM is a GUI for vanilla QEMU 5.2.0, works well for macOS and iOS, and in fact is a very good alternative that makes QEMU usage easier on these platforms, Linux users do not need it because they already have virt-manager, Windows users can go the WSL2 route and install the same Linux version there too. I've spent the last two years searching for a good option, testing DOSBox, QEMU (even failing to compile a version with this 3Dfx patch), PCem. While DOSBox and PCem lacks more speed/performance, QEMU lacks more 3D graphics options, but has a better performance, and I don't really have many 3D games (just two or three) to die trying to compile it for a such feature, so I went for the UTM route.
I might try PCem again when I get a M1 Mac, I've heard good things about its performance there. Or DOSBox when the dynamic core gets fixed too.
My recommendation? Check the list of games you want to play and choose an emulation software based on it, so you can enjoy your retro games instead of wasting time trying to compile something that don't really work on your end. That was the conclusion I had, after all this testing.
"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
Ok, lets continue, i every second Unix/Linux related discussion, ends with some toxic arguments about stupidity of BFUs.. Problems with Linux are only technical / architectural as is described in this great article:
http://itvision.altervista.org/why.linux.is.n … nt.html#Preface but also in its community.
I finally found that magic parameter for Win98 VBE vga:
-vga std ^
and i also tested, that with even with new build version + even vanilla, is the same, when i enable:
-accel hax ^
I got crash on desktop, so no acceleration on machine for now.
Here are also still problem with AC97, in log is this:
audio: Failed to create voice `ac97.pi'
audio: Failed to create voice `ac97.mc'
audio: Failed to create voice `ac97.pi'
audio: Failed to create voice `ac97.mc'
With vanilla i have not such errors audio problems.
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.
ruthan wrote on 2021-02-04, 19:39:Ok, lets continue, i every second Unix/Linux related discussion, ends with some toxic arguments about stupidity of BFUs.. Prob […]
Ok, lets continue, i every second Unix/Linux related discussion, ends with some toxic arguments about stupidity of BFUs.. Problems with Linux are only technical / architectural as is described in this great article:
http://itvision.altervista.org/why.linux.is.n … nt.html#Preface but also in its community.I finally found that magic parameter for Win98 VBE vga:
-vga std ^
and i also tested, that with even with new build version + even vanilla, is the same, when i enable:
-accel hax ^
I got crash on desktop, so no acceleration on machine for now.Here are also still problem with AC97, in log is this:
audio: Failed to create voice `ac97.pi'
audio: Failed to create voice `ac97.mc'
audio: Failed to create voice `ac97.pi'
audio: Failed to create voice `ac97.mc'With vanilla i have not such errors audio problems.
Maybe you have the added problem on Windows that manual pages for qemu are MIA? There's some explanation for those switches in the manual.
The audio messages were addressed previously, they're harmless but I don't know if there is a fix to make them to go away.
@Bruninho: Thanks, I didn't know about UTM. So, it is actually possible to get a decent user experience from QEMU, you just need someone who cares enough 😁
I finally got some speed with Win98, even without any HW acceleration.
There is something strange with frame counting, MSI after burner overlay is showing much less that internal game counters, ~ 1/2 half. Its maybe is how Qemu internal / erxternal displaying is working.
I have to enable Quake 3, internal overlay, because i measured 50 FPS, but from my feeling it was quite choppy like 20-30 fps, but i could be wrong, it needs more testing.
Both test were in 1600x1200, full details, btw is working better than old Voodoo card, even 32bit colors option could be enabled.
C:\Programy\Qemu52-3dfx\qemu-system-i386-520glide.exe ^ -rtc clock=host,base=localtime ^ -m 512 ^ -vga std ^ -device AC97 ^ -boo […]
C:\Programy\Qemu52-3dfx\qemu-system-i386-520glide.exe ^
-rtc clock=host,base=localtime ^
-m 512 ^
-vga std ^
-device AC97 ^
-boot c ^
-hda D:\Games\!Emulators\Dos-QEMU\HDDs\Win98System2-8GB-440-AC97-VBE-3dfx.vmdk ^
-hdb D:\Games\!Emulators\Dos-QEMU\HDDs\Win-Data-28G.vmdk ^
-drive file=D:\Games\!Emulators\Dos-QEMU\Isos\Win98SE-ENG.iso,index=2,media=cdrom ^
-drive file=D:\Games\!Emulators\Dos-QEMU\Isos\Win98-Data-and-Drivers-CD2.iso,index=3,media=cdrom ^
-netdev tap,id=mynet0,ifname=TAP -device rtl8139,netdev=mynet0 ^
-usb ^
-k en-us
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.
I tried to play Quake 3 and game somehow runs internal ~ half is speed, its not framerate issue, its similar too slow running games in Dos Qemu problem, or has to be some cpu timer bug or something like that.
Update: Im using that Qemu timer synchro command, but i already see that time is desynchronized by 13 min, after i would say 45 machine up, so something is work with it for sure.
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.
I have to to address this:
If you want to measure performance stats with Carmageddon 1 3Dfx, then press key "i" during race. The line containing FPS will show up in the middle of the screen.There are 2 3Dfx modes for Carmageddon with the correct 3Dfx Voodoo2 patch (voodo2c.exe), '-vgraphics' and '-vrush' modes. The default is '-vgraphics' mode which dgVoodoo2 has trouble with the HUD but works fine with '-vrush' mode. In '-vgraphics' mode, QEMU and OpenGlide deliver 60 FPS locked on Core m3 6Y30 on both Windows 10 and Linux.
If -vgraphics is default i already tested it and getting that 40-60 FPS, so it this case you machine is faster than mine.. i dont know how much machine are using for testing..
It would be nice if other people would post their numbers too, we have now everything running builds, starting scripts, in my online Excel in Notes is all important hints, even dos configs files, you have only install OS, copy / games and few Qemu 3dfx files and test.
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.
mr.cat wrote on 2021-02-04, 19:54:@Bruninho: Thanks, I didn't know about UTM. So, it is actually possible to get a decent user experience from QEMU, you just need someone who cares enough 😁
Yes, that was my main point. With UTM for example, on my iPad Pro (a picture was posted some posts ago here) I was running Windows 98SE VM, I can play FIFA 99 and Grand Prix 3 if I want to, FIFA 99 in particular is much better with 3Dfx but since UTM/vanilla QEMU does not offer such feature, I can play with software rendering. But I spend much more time playing DOS games and SimTower/SimCity using the DOS6.22/WFW3.11 VM. Also, UTM has made it easier to switch disk images while the VM is running, for example, if I want to play Championship Manager 99/00, I can load the cd image of that game, or if I want to install EA Sports NBA Live '97, I can eject the CM99/00 image and insert the NBA97 cd image. Pretty easy, like it is with VMware. You can visit my thread about the VMs I am running on several environments (iOS, macOS) using different methods (UTM/QEMU, VMware) and check by yourself how the experience is.
"Design isn't just what it looks like and feels like. Design is how it works."
JOBS, Steve.
I still have issue with aspect correction in fullscreen.. i dgvooodo i set, everything what could be related to force 4:3 and streching. Set hard resolution, make no sense, because every game run in other resolution.
;--------------------------------------------------------------------------
[General]
; OutputAPI: "d3d11warp", "d3d11_fl10_0", "d3d11_fl10_1", "d3d11_fl11_0", "bestavailable"
; Adapters: "all", or the ordinal of the adapter (1, ...)
;FullScreenOutput: "default", or the ordinal of the output on the adapter (1, ...)
; ScalingMode: "unspecified", "centered", "stretched", "centered_ar", "stretched_ar",
; "stretched_4_3", "stretched_4_3_crt", "stretched_4_3_c64"
OutputAPI = bestavailable
Adapters = 1
FullScreenOutput = default
FullScreenMode = false
ScalingMode = stretched_4_3
ProgressiveScanlineOrder = false
EnumerateRefreshRates = false
Brightness = 100
Color = 100
Contrast = 100
InheritColorProfileInFullScreenMode = false
KeepWindowAspectRatio = true
CaptureMouse = true
CenterAppWindow = true
;--------------------------------------------------------------------------
[GeneralExt]
; DesktopResolution: Desktop (native) resolution can be forced for dgVoodoo's internal calculations.
; Useful for rare applications that pre-set the desktop to other than the native
; resolution before dgVoodoo gets in action. Only the compact format can be used here,
; and applies to all outputs of the desktop.
; DesktopBitDepth: You can define what screen bit depth should be reported through dgVoodoo
; (8, 16, 32)
; DeframerSize: When resolution is forced to other than the app default then
; a black frame is drawn around the output image coming from a wrapped API
; to remove scaling artifacts -
; frame thickness can be defined in pixels (max 16, 0 = disable)
; ImageScaleFactor: Integer factor for scaling the output image coming from a wrapped API
; Always done by nearest point filtering, independent on scaling mode
; (0 = max available)
; Separate factors can be defined for horizontal and vertical scaling
; by subproperties, e.g.
; ImageScaleFactor = x:3, y:2
; DisplayROI: Display region of interest
; If scaling is done by the dgVoodoo then you can define a subrect of the
; output image, coming from a wrapped API, to be displayed. The defined subrect
; is mapped to the display output according to the current scaling mode
; It can be useful for applications rendering a widescreen subimage into a 4:3
; resolution; in this case you can scale up that subimage to (nearly) fill the
; whole screen on a widescreen monitor.
; DisplayROI empty value means the whole image.
; DisplayROI value can be a proportion in form of %d_%d or a pixel size (%d|%d)
; Pos subproperty is not mandatory and can be 'centered' or a pixel position (%d|%d)
; Examples: DisplayROI = 16_9, pos:centered
; DisplayROI = (320|200), pos:(10|10)
; Resampling: When scaling is done by the dgVoodoo for the given scaling mode,
; you can choose which filter is to be used for resampling the output image
; Available filters are: "pointsampled", "bilinear", "bicubic", "lanczos-2", "lanczos-3"
; FreeMouse: If true then physical mouse is free to move inside the game window
; when using emulated scaling and/or application and forced resolution
; differs; can be useful when a game relies on the physical window size
; WindowedAttributes: You can define attributes for forced windowed appearance (separated by commas):
; "borderless" - forces the app window not have any border
; "alwaysontop" - forces the app window into the top-most band
; "fullscreensize" - forces the app window to be full screen size with image scaling inside
; Environment: Software environment in which dgVoodoo is running: can be left unspecified (native)
; or can be set to 'DosBox' or 'QEmu'.
; EnableGDIHooking: If enabled then dgVoodoo hooks GDI to be able to render graphical contents
; (like movie playback through the ancient Windows Multimedia AVI player library)
; rendered through GDI - experimental feature, for the time being it's implemented
; only for DX emulation
DesktopResolution =
DesktopBitDepth =
DeframerSize = 1
ImageScaleFactor = 1
DisplayROI =
Resampling = bilinear
FreeMouse = false
WindowedAttributes =
Environment = QEmu
EnableGDIHooking = false
;--------------------------------------------------------------------------
[Glide]
; VideoCard: "voodoo_graphics", "voodoo_rush", "voodoo_2", "voodoo_banshee", "other_greater"
; OnboardRAM: in MBs
; MemorySizeOfTMU: in kBs
; TMUFiltering: "appdriven", "pointsampled", "bilinear"
;
; Resolution: either "unforced", "max", "max_isf", "max_fhd", "max_fhd_isf", "max_qhd", "max_qhd_isf", "%d x"
; or subproperties: h: horizontal, v: vertical
; + optional subproperty refrate: refresh rate in Hz
; e.g. Resolution = max, refrate:60
; Resolution = 2x, refrate:59
; Resolution = h:1280, v:1024, refrate:75
; or just use the compact form like "1024x768@60" or "512x384"
;
;Antialiasing: "off", "appdriven", "2x", "4x", "8x", "16x" (your GPU must support the chosen one)
VideoCard = other_greater
OnboardRAM = 128
MemorySizeOfTMU = 65536
NumberOfTMUs = 3
TMUFiltering = appdriven
DisableMipmapping = false
Resolution = unforced
Antialiasing = appdriven
EnableGlideGammaRamp = true
ForceVerticalSync = false
ForceEmulatingTruePCIAccess = false
16BitDepthBuffer = false
3DfxWatermark = true
3DfxSplashScreen = true
PointcastPalette = false
EnableInactiveAppState = false
;--------------------------------------------------------------------------
[GlideExt]
; DitheringEffect: "pure32bit", "dither2x2", "dither4x4"
; Dithering: "disabled", "appdriven", "forcealways"
; DitherOrderedMatrixSizeScale: integer scale value for dither matrix size
; 1 = normal, 2 = double size, etc.
; 0 = automatic (the aim is to have some retro feel&look)
DitheringEffect = pure32bit
Dithering = forcealways
DitherOrderedMatrixSizeScale = 0
;--------------------------------------------------------------------------
[DirectX]
; VideoCard: "svga", "internal3D", "geforce_ti_4800", "ati_radeon_8500",
; "matrox_parhelia-512", "geforce_fx_5700_ultra"
; VRAM: in MBs (default) or in GBs (e.g. VRAM = 2GB)
; Filtering: "appdriven", "pointsampled", "bilinear", "linearmip", "trilinear"
; or the integer value of an anisotropic filtering level (1-16)
DisableAndPassThru = false
VideoCard = internal3D
VRAM = 256
Filtering = appdriven
DisableMipmapping = false
Resolution = unforced
Antialiasing = appdriven
AppControlledScreenMode = true
DisableAltEnterToToggleScreenMode = true
BilinearBlitStretch = false
PhongShadingWhenPossible = false
ForceVerticalSync = false
dgVoodooWatermark = true
FastVideoMemoryAccess = false
;--------------------------------------------------------------------------
[DirectXExt]
; AdapterIDType: "nvidia", "amd", "intel" or leave it undefined
; You can define what type of driver version and vendor id's the wrapper should report to
; the application; Some games rely on that information so it can be useful for them
; Can be defined only for SVGA and Internal3D card types; the others have their own wired
; information
; VendorID, DeviceID, SubsystemID, RevisionID:
; Can be defined only for SVGA and Internal3D card types
; You can overwrite these properties even if a non-default AdapterIDType is defined;
; say, you defined an nvidia id type but would like to refine the vendor id
; DefaultEnumeratedResolutions: you can define what resolutions should be enumerated to the application by default
; "all", "classics", "none"
; ExtraEnumeratedResolutions: you can add extra resolutions (separated by commas, max 16) that will get
; enumerated to the application as display adapter supported ones -
; can be useful if an app supports rendering at arbitrary resolutions
; and you have a particular favorite resolution that are not
; enumerated to the application by default
; you can either use the compact resolution format here, or
; "max", "max@refrate" meaning your desktop resolution with a potential refresh rate, or
; "max_4_3", "max_4_3@refrate", "max_16_9", "max_16_9@refrate"
; meaning the maximum resolution with the given aspect ratio calculated from
; the desktop resolution with the given refresh rate, e.g. "max_4_3@60", "max_16_9"
; EnumeratedResolutionBitdepths: you can filter what bitdepths are included in the resolution enumeration
; any subset of {"8", "16", "32"}, or "all"
; DitheringEffect: "pure32bit", "ordered2x2", "ordered4x4"
; Dithering: "disabled", "appdriven", "forceon16bit", "forcealways"
; DitherOrderedMatrixSizeScale: integer scale value for dither matrix size
; 1 = normal, 2 = double size, etc.
; 0 = automatic
; DepthBuffersBitDepth: internal bit depth of depth/stencil buffers for 3D rendering (32 bit is not recommended)
; "appdriven", "forcemin24bit", "force32bit"
; MaxVSConstRegisters: Max number of vertex shader constant registers (DX8/9 only)
; Can be defined only for SVGA and Internal3D card types
; Valid values are 256 (default), 512 or 1024
; MSD3DDeviceNames: if true then original Microsoft D3D device names are exposed
; (some applications check for them and they fail)
; RTTexturesForceScaleAndMSAA: if true then forced resolution scaling and MSAA is
; applied also to rendertarget textures
; Set it to false for games requiring pixel-precise rendering
; but be careful it can EASILY break certain things, not recommended
; SmoothedDepthSampling: if true then extra smoothing is added to depth textures
; when they are sampled
; DeferredScreenModeSwitch: If true the switching to full screen is deferred after the application initialized
; the DirectX device; can be useful for games that don't expect rendering window changes
; during initialization and crash
; PrimarySurfaceBatchedUpdate: If true then direct changes of the primary surface are batched together for presenting them
; If false then each change is instantly presented (debug-like mode)
AdapterIDType =
VendorID =
DeviceID =
SubsystemID =
RevisionID =
DefaultEnumeratedResolutions = all
ExtraEnumeratedResolutions =
EnumeratedResolutionBitdepths = all
DitheringEffect = pure32bit
Dithering = forcealways
DitherOrderedMatrixSizeScale = 0
DepthBuffersBitDepth = appdriven
MaxVSConstRegisters = 256
MSD3DDeviceNames = false
RTTexturesForceScaleAndMSAA = true
SmoothedDepthSampling = true
DeferredScreenModeSwitch = false
PrimarySurfaceBatchedUpdate = false
;--------------------------------------------------------------------------
[Debug]
; This section affects only debug/spec release builds
;
; Info, Warning, Error
; "Disable" - disables all messages and debugger break
; "Enable" - enables messages and disables debugger break
; "EnableBreak" - enables both messages and breaking into debugger
;
; MaxTraceLevel: Maximum level of tracing API calls
; 0 - Disable
; 1 - API Functions and methods
; 2 - Additional trace info for internals
;
; LogToFile: if false or debugger is detected then output goes to the debug output
; if true and no debugger detected then output goes to 'dgVoodoo.log'
; (not implemented yet, always the default debug output is used)
Info = enable
Warning = enable
Error = enable
MaxTraceLevel = 0
LogToFile = false
In Dos is always wrong in Fullscreen:
In Win9x Desktop is right + and 2d games are righ (4:3 forced) fullscreen on whole monitor:
Win9x Qemu 3d in Window mode is right:
Win9x Qemu 3d mode in Fullscreen - is wrong, picture is place in left- bottom as resolution is not change is drawning 1600x1200 etc picture on whole 2540x1440 canvas (monitor resolution).
BTW in theory some speed, framerate problems could be related to my refresh rate 144, even some modern, games, apps have problem with tha, are hardcoded to 60. That for old games it should be right as back in day fast refresh rate CRT monitors.
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.
I added couple of Win98 test results to online sheet:
https://docs.google.com/spreadsheets/d/17tB99 … dit?usp=sharing
I future i will also add Qemu console output for not working games (as cell coments), for now its only for Return to Castle Wolfenstein demo crash and Q1dos(Dos sheet.) So far speed problem is related only to Quake3, but performance of other games is not near to fast as on KJLiew Linux setup..
Also some no working games probably needs some hacks to force 3dfx mode - UT 2003 demo, NHL 2000 (there some fix on nGLide site but for full game not demo)
Update: i made Q1Dos running (OpenGL-Mesa and glide3.dxe from RobertMo package, No Hax(with it crash right after execution)), but it took couple of minutes to load and slideshow, missing textures and maybe is Dos settings sound related (but probably not -nosound is the same) , i dunno.. and some texture are missing:
glidept: DLL loaded - glide3x.dll
trace: _grGlideInit@0 called
glidept: f6c9c59-09:12:50 Feb 3 2021 build WRAPFX32
glidept:
Extension: CHROMARANGE TEXCHROMA TEXMIRROR TEXUMA PALETTE6666 FOGCOORD TEXTUREBUFFER GETGAMMA RESOLUTION
Hardware: Voodoo4
Version: 3.10
wr2x_trace: _grGet@12
wr2x_trace: _grSstSelect@4
glidept: grSstWinOpen called, fmt 1 org 1 buf 2 aux 1 gLfb 0xfac00000
glidept: LFB mode is Shared Memory (fast), One-copy
window 640x480
30 frames in 5.1 seconds, 5.9 FPS
Update 2: Ok performance and slow loading problem was really caused by inactive EMM386, never saw this on real machine.. Texture problems are still here. With hax it is still crashing right after start.
Its not solutions of all problems, Doom2 are still slideshow, it need that hax removal but, after that is for change too fast..
As i wrote its minefield run like experience (mines=bugs), you can find "right" way how to play games, but its complicated.
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.
ruthan wrote on 2021-02-05, 01:16:... So far speed problem is related only to Quake3, but performance of other games is not near to fast as on KJLiew Linux setup..
As i wrote its minefield run like experience (mines=bugs), you can find "right" way how to play games, but its complicated.
Yeah, QEMU is full of minefield to blow away your precious time. Blame no one, you were on your own dismay at your own will. 😁 You could have stayed in the wonderland of PCem and VMware.
Wouldn't it be so silly to expect the same results **WITHOUT** acceleration? You do realize the difference between QEMU TCG and KVM/WHPX, don't you? 🤣 As for the Q1DOS texture problem, it was yourself to blame by configuring dgVoodoo2 as "Voodoo4" for such an ancient DMESA API for 3Dfx. Exercise some common sense, Voodoo2 is the most compatible and dgVoodoo2 default to that. The old MESA 3Dfx and Sage had never supported well for anything more recent than Voodoo Banshee before the company busted. I guess you did not bother to read the codes. Bigger does not always equal better, just like those who think they need Ryzen 5950X or Core i9 to play Direct3D/OpenGL games on PCem with Voodoo3 emulation.
And don't rant about HAX not working. I am in no business to steer the direction of the project for use cases that it had decided not to support.
I made some progress in Dos, without EMM386 inactive.. all already tested 3dfx games which had some framerate issue, are now running at full speed 50/60 FPS locked, depends on game. BTW what is making 60 FPS limit, dgVoodoo, Qemu itself or Qemu 3dfx? More and more people have now better than 60 FPS monitors so it would make sense to enable high framerates.
Other games like Redguard started working after HAX removal.
Here is Shadow Warriror broken palete picture:
Blood - there is again game speed problem, is too slow, but its about framerate its running 60 fps.
Also needs some gamma adjustments - its too bright, i vaguely remember that there were some system variables for it.
wrote:-no-quit
Thanks and for EMM386 tip. I also discovered by DX12 was not available, i replated glide*.dlls, but not dgVooodoo control panel with new dgVoodoo update.
wrote:Yeah, QEMU is full of minefield to blow away your precious time. Blame no one, you were on your own dismay at your own will. 😁 You could have stayed in the wonderland of PCem and VMware.
I dont know in which world you are living, but change virtualization settings on game / app basic, its really not normal and good experience.. and even then there are issues. With all problems and you disappointment with my personality, online sheet is making clear progress, if will be greater you will aim on technical aspects..
wrote:Wouldn't it be so silly to expect the same results **WITHOUT** acceleration? You do realize the difference between QEMU TCG and KVM/WHPX, don't you?
Its called acceleration, so i only excepted that it would be faster, but so far i did not see any numbers, comparison. I tried to enable Qemu acceleration on Linux KVM machine / Vanilla, so far big difference. Now i see that in DOS is lots problems with HAX and my machine is fast enough even without it, with WIn98 im getting crash with HAX. robertMo wrote than without HAX he expect in DOS much slower performance, but i got only 1/4 off, so no big deal. For you its clearly working, so make some benchmarks to show difference.
Im not happy with situation, but because of problems with Win10 upgrade ( Vmware + Hyper-V at same time needs Windows 10 20H1 build 19041.264, im stuck at 1909, quite a lot of Windows 10 user know already had upgrade issues , its taking almost hour even for fail attemp), so now im not enabled WHPX because of lost of Vmware, rebooting, i will do it later and quicker if will game me some great performance expectations. From overall perspective, i thing that is good that we would be both numbers..
As for the Q1DOS texture problem, it was yourself to blame by configuring dgVoodoo2 as "Voodoo4" for such an ancient DMESA API for 3Dfx.
Well i fixed it by using even older FXMESA. Voodoo 4 until i saw Qemu ouput, i dont even know that Voodoo 4 is emulated, because i just expected is virtual compatible 3dfx something is making things possible and that is clone to some real Voodoo cards, its only compatible with them. Why my dgVoodoo settings look like this, i dunno its long time, probably because someone here hinted it and its emulating fastest possible settings which make sense.
Info and other "important" switches consequences should be at least point on project description page, readme etc. - thanks our try and fail - report strategy we now have online which settings is needed for some game and major patterns are known.
And don't rant about HAX not working. I am in no business to steer the direction of the project for use cases that it had decided not to support.
I was only curios, how it actually works together, if problem with HAX itself, Qemu or you Qemu 3dfx part? Its getting better with new updates? Other question enabling HAX means crashing in lots of use cases, its WHPX better - more stable?
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.
