ruthan wrote on 2021-02-05, 16:38:

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.
... For you its clearly working, so make some benchmarks to show difference.

Your machine is also fast enough without QEMU. Just use PCem, it fits your world view of "one size fits all" better than QEMU.
The difference is all over the place from my YouTube channel. Just go and watch every single video, they will redefine your perceived "fast enough" for more demanding 2000/2001 games.

I had already done thorough analysis on the Shadow Warrior (DOS) problem, only if you could just STFW. Yeah, QEMU f*cked up, another big+ for PCem. 🤣

Where is your claimed 15+ years of virtualization experience on VMware/Hyper-V deployment and yet only now you realized DOS does not work quite well with virtualization? I have zero experience in virtualization but followed QEMU since its inception and learning every bits by bits since then. I went through the early stage of KVM that only worked for guests with Linux/NT kernel and nothing else. QEMU even had its code to make sure the guest enabled 32-bit protected-mode with paging before it switched on KVM. Today, with Unrestricted Guest (UG) mode, 16-bit real-mode can be somewhat accelerated by virtualization, but context switching (in the case of 32-bit DOS extenders) or VGA planar I/O accesses continue to incur considerable performance loss for virtualization. Yeah, another big+ for PCem with its emulation done right. 🤣

Or just use DOSBox for DOS games, KISS! You could continue to litter this thread with garbage on DOS games, EMM386, MOUSE/CD-ROM real-mode drivers, bloated CONFIG.SYS, SMARTDRV bla... bla... Yeah, QEMU is just a piece of FOSS crap, just look elsewhere for your Utopian ideals. For those who understand and cherish virtualization, we simply have a good laugh. 😜

-hda DOS.VHD -cdrom d:
DAEMON Tools Lite for switching cds

I just retested everything with WHPX on - new column in Win 98 sheet, its 4-6x faster, i expected smaller difference. From games which are working only Quake 3 still has that half speed problem regardless of 350 FPS+.
Update: UT2003 has same problem, regardless of 144 FPS lock.

I wonder for games which are not working and using some sort of *gl.*dll, but use other name than opengl32.dll, is good idea, just try replace original file with opengl32 renamed to new name to make game working? If my memory serves, at least sometimes which workaround is working..

robermo wrote:

-hda DOS.VHD -cdrom d:
DAEMON Tools Lite for switching cds

Great, workaround.

kjliew wrote:

Your machine is also fast enough without QEMU. Just use PCem, it fits your world view of "one size fits all" better than QEMU.
The difference is all over the place from my YouTube channel. Just go and watch every single video, they will redefine your perceived "fast enough" for more demanding 2000/2001 games.

Pleas stop behaving like that, its childish, i criticized you for some things.. people can judge is it was justified or not, but you are now trying to twist every by sentence to disagree with it. Im trying to make things actually working.
I wrote is fast enough for me, no thing is anything wrong to make it faster.. In second wave i can test it on other machine.

kjliew wrote:

I had already done thorough analysis on the Shadow Warrior (DOS) problem, only if you could just STFW.

Im just reporting about present state of whole solution, i could maybe google this problem later, i just quickly insert picture here, that maybe someone will know and will not offended by it.

kjliew wrote:

Where is your claimed 15+ years of virtualization experience on VMware/Hyper-V deployment and yet only now you realized DOS does not work quite well with virtualization?

DOS virtualization made no much sense, until last year or two, because on working Sound - Sound Blaster emulation and there was Dosbox as better alternative.

kjliew wrote:

EMM386, MOUSE/CD-ROM real-mode drivers, bloated CONFIG.SYS, SMARTDRV bla... Per partes. EMM386 - Yes was using EMM386 f […]
Show full quote

EMM386, MOUSE/CD-ROM real-mode drivers, bloated CONFIG.SYS, SMARTDRV bla...
Per partes.
EMM386 - Yes was using EMM386 from 1995 or something like that because i needed more few conventional memory and it worked quite well.. except games like Ultima and Wing Commander, which have only inbuild memory management, incompatible with it. DOS4GW is compatible. If would be issue, i would be stop using it as default.
MOUSE/CD-ROM - i tried mouse.com only because ctmouse was not working, mscdex - is there i thing from some robertMo original config sample, i had not yet reason to remove it. Yes i know better alternatives.
bloated CONFIG.SYS - yeah im big friend branched configs with lots of options, i have whole thread about it here, but for this project im really using some stub config from roberMo
SMARTDRV - you did not even look in my samples, smartdrv is not here.. that is thing which i not using for various reason. For example PCem recommend it and without it its disk performance just more that in should from my knowledge.

For those who understand and cherish virtualization, we simply have a good laugh.

We will see, maybe for more people your behavior here is source of disgustment, regardless of your great coding skill and knowledge.

ruthan, I already advised you not to waste your time trying to convince him. I can’t understand why you insisted on this. If you simply want to play the games, go the easy route: DOSBox, VMware, PCem. Unless you want to move to another architecture (like I am about to do, from Intel Mac to M1 Mac) there’s absolutely zero benefit for you to keep trying QEMU with his 3Dfx patch, unless you understand fully how his patch works.

Get VMware Player, install Windows XP and go from there. Direct3D works and I can play FIFA 99 in all its glory.

ruthan, I already advised you not to waste your time trying to convince him. I can’t understand why you insisted on this.

Its good project from that it is its goal, make sense to support it, only its developer has its flaws..
When you look and our online sheet. we made from the start quite progress, for something which cant be even compiled, to quite working solutions with lots of unpleasant workarounds and settings per game basis.

As i wrote is good to have alternatives to PCem and its some ways, if need to play some to play some old game on some slow device, like is some netbook or 15W company laptop, or my GPD Win2 its really only solution, never tested PCem on such slow device, but i dont except that it would be able emulate anything faster than P100 or something like that.

I still have my dreams, that this will be merged into main Qemu one day and even you iPad build would be able to benefit from it.. and it would be once all games solution at least for Windows 98 - with fully working 2D, Glide, OpenGl + Direct3D.. GLide / OpenGL is already there, KJLiew shown some Direct3D videos, im not sure if possible with current build and how, his video ask usually lack any info how to replicate its like monument build to its own authors skills. I hope that someone will continue to improve sound quality and Dos sound compatibility and we will have someone in future really great all round solution for all Win 98 gaming.

Bottleneck of weakest point i dont see maybe surprisingly for someone in KJLiew work, but in use VBE9x.. its really quite buggy and dead project and i dont see any alternatives and if anybody willing to write whole 2d stack or make working cirrus with 3Dfx together to get rid off VBE9x and its disadvantages.

ruthan wrote on 2021-01-19, 21:56:

.. there is 637 vs 848 its so difference is very small and with PCem im getting fully emulated machine without QEMU / VBEMP problem, it would be no brainer sacrifice 25% of performance for that. Same Quake 2, there is difference but its not huge (lets say 50%), as i expected..
.. and if im not wrong anything with OpenGL is not public..
.. Qemu 3dfx is so far designed only for average kjliew 😀 Because he is only one who is able to use it for OpenGL..

Oh, what a drama ... Welcome to the club of average kjliew! 🤣 🤣 It's now your turn to rub qemu to everyone's face ... 🤣 🤣
I am glad that you didn't add another column for PCem v17, otherwise the moderator may edit your post to remove the link ... 🤣 🤣 Your account on PCem forum (if you signed up one) may be locked out/deleted in no time to prevent you from further posting. There are lots of queries on how to maximize PCem performance ... Well, you now have the answer for them, just join the club of average kjliew.

At 1600x1200 (or anything higher than 1024x768), PCem "freaking fast" 3Dfx recompiler would be even harder to keep up and the fanboy defended that with *BS* of missing AGP emulation bla... bla... If I cranked up the resolution, the comparison between PCem and QEMU even on TCG would be so ugly. QEMU does not suffer that problem with API pass-through. The GPU potential is largely untapped since TCG isn't fast enough to pump the data into GPU. It delivers roughly the same performance from 640x480 to 1600x1200. I don't even need to show anything from KVM/WHPX ...

ruthan wrote on 2021-01-19, 21:56:

Because with these numbers your project starting to be interesting for me, otherwise no big deal with PCem quick progress.

Yeah, no big deal, they will just never get there. 🤣 🤣 Or perhaps they have access to time machine or a friendly alien civilization that empowers them with technology lightyears ahead of our time 🤣 🤣 Well, we never know, perhaps a friendly humiliation might change their perception to embrace virtualization, too. It would then be win-win for all of us. 😀

ruthan wrote on 2021-02-05, 23:58:

I still have my dreams, that this will be merged into main Qemu one day ...

I hate to be a negative nelly here, but this merging business seems very unlikely to happen (at least, in the current form). Mainstream qemu already has their own method of providing 3D acceleration for the guest, which unfortunately leaves these oldtimer OSes out in the cold - no drivers exist, and no-one is going to write them.
Their main concern is also the Cloud and not retrogaming, and that necessitates a rather different approach to security.

Even with that dream shot down, there are other possibilities.
One of the niceties you get with open source is that you can just take the source and use it to your liking. If you were to, for instance, disagree with the author 😁
you can always just fork it if you like. Needless to say that requires quite a strong motivation to do so, but it has happened before with some projects.
But to make an "easy" version for that 96% of Windows gamers (as ruthan mentioned), no forking is even necessary, "just" some fancy packaging.
Maybe in that 96% gamers there is a dev or two who'd like to do that? (Or maybe not, maybe they're too busy gaming 😀

EDIT: Forking is just an example here (and an extreme one at that) of what can be done if there are multiple goals present within a project.

God knows I’ve tried to warn him (ruthan).

Given the games I want to play, I believe DOSBox-X would be the best choice FOR ME if they get to fix the dynamic core to work with Windows 9x. As of now, UTM/QEMU vanilla is my only option. PCem is too slow for that job, but might be a much better option if it works as expected with a M1 Mac.

ruthan, again my advice... check your games and get a free VMware Player install. Or DOSBox. Stop wasting your precious time trying to convince OP to make a “dumbed down” version for you. That time you would be better of playing the games OOB instead of countless testing hours only to get shot down by OP every time you do them.

EDIT: I have to fully agree with mr.cat here. QEMU devs are not interested in retrogaming. For them, its enough the route for modern games to use a passthrough method so your guest OS would use your discrete GPU while your host OS is powered by the integrated GPU. Many linux users do this for gaming on windows titles.

kjliew wrote:

ruthan wrote:

.. there is 637 vs 848 its so difference is very small and with PCem im getting fully emulated machine without QEMU / VBEMP problem, it would be no brainer sacrifice 25% of performance for that. Same Quake 2, there is difference but its not huge (lets say 50%), as i expected..
.. and if im not wrong anything with OpenGL is not public..
.. Qemu 3dfx is so far designed only for average kjliew 😀 Because he is only one who is able to use it for OpenGL..

We still not have numbers for right comparation, but 25% is really nothing, but it case of Win9x/2k/XP are now have at least some numbers.. and lets estimate that Qemu performance without accelerator would be same as PCem performance, with WHPX we have not ~ 500 % boost.. that is really something.

kjliew wrote:

] Oh, what a drama ... Welcome to the club of average kjliew! 🤣 🤣 It's now your turn to rub qemu to everyone's face ... 🤣 🤣
I am glad that you didn't add another column for PCem v17, otherwise the moderator may edit your post to remove the link ... 🤣 🤣 Your account on PCem forum (if you signed up one) may be locked out/deleted in no time to prevent you from further posting.

I not have some great feeling about these projects, to be super excited about it (yes i want to play great old games on new machines, on the way on portable slow handheld), as you because its your child, you invested into it much more effort, but with question about PCem was something already wasted to ask in next post, before i started to respond to this. Because other people are not much believe in shiny future of Qemu for retro gaming, it would only other possible "short term" solution.
If would banned for it in PCem forum, well, i would be on same ship with you, if they banning people for that they are toxic too. I dont read anything about that, but i would say that you have "gift" to jump right into middle of some thread and post something about your project and how much is superior (it is in some ways), but how it is communicated matters too.
I already asked in PCem forum, on which is whole solution based and its not fork of something its just something mainly wrote of one developer - Sarah is her name if not wrong.. and there justified worries how many people can really understand its code and continue with project, if she would get other priorities.. But its a bit same with Qemu 3Dfx, yes Qemu with live without you, but that why i thing that merging into main branch make sense.

kjliew wrote:

]At 1600x1200 (or anything higher than 1024x768), PCem "freaking fast" 3Dfx recompiler would be even harder to keep up and the fanboy defended that with *BS* of missing AGP emulation bla... bla... If I cranked up the resolution, the comparison between PCem and QEMU even on TCG would be so ugly.

PCem started as some 8086 emulator and with every release they adding support for new hardware (now they had PII 450 and couple of new videocards like Voodoo 3) so i hope that they will add AGP and PCI-E in future, if they are stubborn to not add more, they are just plainly wrong.
BTW when i dig deeper in Qemu and KVM, its emulation by default old i440 chipset, which there is somehow glues PCI-E support into it, which with chipset not even dream about.

mr.cat wrote:

I hate to be a negative nelly here, but this merging business seems very unlikely to happen (at least, in the current form). Mainstream qemu already has their own method of providing 3D acceleration for the guest, which unfortunately leaves these oldtimer OSes out in the cold - no drivers exist, and no-one is going to write them.
Their main concern is also the Cloud and not retrogaming, and that necessitates a rather different approach to security.

This is actually very interesting topic, there are all this world about free software freedoms and how great it, but from words in reality it some that at the top of Qemu projects sits some board controller but some Bill Gates like person which care only about money. If this is true hope that openness would be big bubble. If not long time when i checked other iteration of Why Linux sucks from Bryan Lunduke, and he said at some Linux conferences sits most of bosses with MacBooks and using MacOS as OS, on even border to install Linux on it.
I tend to believe that is not picture of whole us pawn in community and its not so dark.

I understand some forking for small project, or when lots of developers what to go by other way, but when you have big project and one developer want go other way, i thing that forking is way to hell.. because as main code base will change there is still more and more work needed to check you additional code compatible.. to situation when in simply became too much.. Its my simple view of project.

In other way, best thing in the life is possibility of change and it simply not understand why is not possible simply to Qemu add some optimal "-retro 3d" switch why will active kjliew part of code of code and 99.9% of users will not use it, can ignore it, same way as some old PowerPC mac, 68k Mac, or Alpha code which is already merged into.

I would actually like to some link, then kjliew send its code for merge and some evil corporate administrator rejected it..

I thing that problem is elsewhere as proven my bug reports, old OS problems are simply hard to solve, they lots of knowledge is less and less common and use base is small - so it make complete sense, they have small priority. Exactly here i always believed that open source would work and volunteer can add and it would be merged.
BTW whole Vmware Dos Sound blaster support for Vmware workstation is also project by on its employer done in this spare time and its merged and even added to release notes ad highligh.. It would be shame of whole FOSS machinery would be actually worse than so big IT moloch, which is in 99% money oriented, but even Vmware cant ignore gaming making better, but yes not for retro OSes..

Yeah you can even argue, that some leaders are blind to how retro gaming market can be profitable, because age of average player is now 35 or something like that, but its other topic. Its very similar in whole game industry, i heard zillion time that market is saturated, that nobody will buy game like XY, there is not room for new genre etc and its always proven as wrong.

One more offtopic note, there is even more scary thing than Qemu, Bochs, even here probably all people here said me not try to bend it for gaming use, yet it has some Voodoo 3 support, i dunno for what.. if im not wrong i saw so androind emulators based on it..

So we really don't like the types of discussion that is occurring here on this forum (personal remarks, posting off topic in other posts, intentionally trying to rile people up, etc) and it has polluted this thread. I'm not going to bother to clean up the inanity in this thread.

So:
Please start another thread if you wish related to development of QEMU with 3dfx.
If you all want to discuss anything not related to the development of QEMU then open up other threads: ex: Emulator benchmarks, opinions of emulator development, etc.

If the idiocy continues then bans will occur.

Once those threads have been created I will close this thread. If no threads created then I will close this thread one week from today.

Moderator god come from its mountain.. we have to respect it.
I dont believe that divide this into more threads here its would be much better - it would end with same deus ex machina locking, lets create successor thread elsewhere, where rules are no some strict and link it here for continuity.
If it would be about personal attacks ok, but if broader discussion is problem her its bad , lets change ground.

Update:
I made Qemu 3dfx thread on Win-Raid, it has retro gaming section, is now quite retro gaming, i already have some philosophical disscussion like this about Win 98 KVM gaming here, with conflicts of views, without any censorship
https://www.win-raid.com/t8242f53-QEMU-Dfx-Gl … .html#msg136792

Thanks...
I guess the writing was on the wall (pun intended) on that one!
Hmmm I did call for restructuring a while back, well this wasn't exactly what I had in mind.

Well, that's about it, this could be the last post before it is locked out ...

There is only one thing that I wish to clarify because it relates to area of research where I had spent efforts in addressing the *side-effect* of virtualization. And it was already brought up in the other forum with another poor judgement for those who had no clue of what they were talking about.

QEMU has no such way to limit (CPU) performance.

This seems to source of one of present Qemu gaming problems ...

Yes, it is true QEMU would never limit CPU performance. It is the right decision (similar to VirtualBox/VMware) for enterprise virtualization solution. Unlike DOS games, almost all Windows games are not sensitive to the speed of CPU computation, but only the speed of how fast rendered frames are presented where the game logics/AI may be taking that into account. Glide/Direct3D/OpenGL all have more reliable ways of limiting frame rate without jeopardizing the CPU performance. It is year 2021, not the mindset of 8088 in the 80's with MoSlo or CPUGrabber. That's why I am not in the *BS* of the so-called *cycle-accurate* emulation for use cases (as in playing games) where cycle-accuracy does not present any values. I value cycle-accuracy when the emulation is used for debugging HW/SW issues or in areas of research focusing on determinism.

"Just enable that f*ucking VSYNC"
This is the easiest way to limit frame rate at VSYNC. If the GPU driver support more precise swap control of just simple ON and OFF, then it can also be used to impose limit at 30FPS for typical 60Hz panels. For most OpenGL games, it is all that is required to cure audio crackling and/or synchronization when frame rate exceeds 60FPS.

For early Glide/DirectDraw/Direct3D games (1995~1997), it was a little more troublesome due to immaturity of early game engines or game engines ported based on DOS VESA LFB. They were usually targeted for 25~30 FPS and they had never imagined to be run on a CPU/GPU prowess that could blow the FPS off the roof, even 60FPS could be too many for them and not all GPU drivers support precise swap control. Glide was easy, it was almost certain that all Glide games will use grBufferSwap() to present rendered frames and QEMU Glide pass-through WIN32 guest stubs support frame timing at the function call to effectively limit the frame rate. The concept was proven and demo'ed on Titanium Mechwarriors videos on my YouTube channel. Nuclear Strike is another Glide game that are known to exhibit unplayable erroneous behavior with extremely high frame rate and QEMU Glide pass-through restore the game perfectly. For DirectDraw/Direct3D games, Wine DDRAW.DLL can be modified to support frame timing at ddraw_surface_flip() and has been proven to work reliably, too.

So before someone comes back and argues for the sake of argument (not again 🤣) on kjliew's frame limiting methodology sucked because there are games (mostly DirectDraw, but Glide/Direct3D/OpenGL all allow that) render directly into framebuffer (front buffer) without requiring to perform flip or buffer swap for frame presentation. Yeah, you're right 🤣, screw the games then 🤣. OR just use PCem, as extremely high FPS would hardly be a problem for its "emulation done right".

All right, it will be the last one .... 🤣

ruthan wrote on 2021-02-06, 17:19:

kjliew wrote:

]At 1600x1200 (or anything higher than 1024x768), PCem "freaking fast" 3Dfx recompiler would be even harder to keep up and the fanboy defended that with *BS* of missing AGP emulation bla... bla... If I cranked up the resolution, the comparison between PCem and QEMU even on TCG would be so ugly.

PCem started as some 8086 emulator and with every release they adding support for new hardware (now they had PII 450 and couple of new videocards like Voodoo 3) so i hope that they will add AGP and PCI-E in future, if they are stubborn to not add more, they are just plainly wrong.

You still don't get the point, do you? 😀
It was yet another friendly humiliation to those who mentioned "AGP emulation" or "... it's the PCI versions that are emulated as the bus bandwidth ..." in defend of unplayable high-resolution, over here at VOGONS and their own forum. Do a search, will you? 🤣

uhh... wow.
I came back to this forum after a few weeks, and jeez this is a mess.
Anyways, Kjliew. Can you please share the modified wine dlls you used to get direct draw to work? I've gotten most of the rest of this project working on my machine, but Ddraw is the biggest roadblock so far.
Binaries would be preferred, but source code would be cool too.

Also, Ruthan I'll be sure to add some stuff to your google doc once I get a reliable and repeatable setup process going.

In terms of why QEMU instead of PCem? Input latency, PCem is slow as hell in that regards, even with a modern i9. Qemu is the only thing that's even close to realtime. This is why I'm interested in the project, not accuracy or fps or anything like that, just input lag. I'll probably just stick with real hardware, but eventually that won't be an option anymore so I'm trying to compile and archive a working copy of this project before it inevitably disappears off the face of the net.

So my last note before this thread is locked, is thanks for all the hard work everyone has done.

2 more days left till thread closure

t9999clint wrote on 2021-02-10, 13:27:

... PCem is slow as hell in that regards, even with a modern i9...

OMG! Hadn't I warned about no forbidden words on the "freaking fast" PCem? 🤣 🤣

I as wrote i available on Winraid thread, i tested quite a lot games with 3dfx Qemu, im quite sure that some marked as not working could work with more knowledge how to enable acceleration (for example EA games with its 3Dsetup), other need some advance in code especially some internet Qemu timer fix for proper game speed.

Okay, everyone. Concretely: which separate threads have already been created and how more distinct ones do we need?

I know things have gotten a little hectic here, with quite a few topics being mixed, but most of them are quite interesting and worth discussing further separately.

Can we have an overview here, before this thread closes?

Closed