V18 will be switching to Qt This may regress XP/Vista/7/8/8.1 support. Several emulators moving to QT (PCSX2, Dolphin) gave up 7 because they had no choice in the matter when that decision's from upstream and/or develop on Win10/linux unaware of the platform regression creep issues. OTOH it's great...

Is DirectX 7 installed? The last Voodoo2 drivers rely on them.

Windows 98SE does not ship Voodoo2 drivers. The Voodoo3 drivers do not provide functionality for the Voodoo2. You should disable the Voodoo Graphics checkbox when you've got a Voodoo3 anyway. Identity crisis aside, they work like two different beasts.

Have you seen the readme at the git repository?

The latest Raspberry Pi OS's on aarch64 and that's an architecture that wasn't tested much at the time of v17 (even though an arm64 dynarec is present, the 64-bit Raspban being a beta with less driver functionality). The current development tree on github may have better aarch64 support.

Delete flash.bin

DamTheGreat wrote: ↑Mon 02 May, 2022 8:45 am i7-9700 @ 3 GHz.

I'd dial the guest down to 166-200MHz. Voodoo2 threads can also matter, and i'd stick to 2 for this. (Maybe turn the screen filter off to help. :'( ) Either that, or get the host past 4ghz.

Games like Jedi Outcast and Jedi Academy run great on VMWare, but you would need a powerful CPU, if it exists, to run them with PCem. This is applied in real-life too. A Celeron 600 with a Voodoo3 isn't going to run JK2/JA very good, what with the weighted skinning, large textures and song crossfad...

Banshee/Voodoo3 have the VRAM necessary to handle contemporary widescreen resolutions (1280x720, 1600x900, 1920x1080), however Win9x monitor drivers don't expose them. You'll have to Powerstrip them in, probably.

Nevermind unemulateably slow Pentium IIIs when there's still other gaps (K5, MediaGX, UMC486, Rise mP6, Nexgen). We barely have CPUs that can scratch at the highest emulated celerons (disregarding emulation of cache penalties).

it's not a plugin. This was written long before the plugin system, and it'd probably need a major rebasing on the latest tree.

All 3DAnalyze does is inject overrides of caps and ids for Direct3D and OpenGL. It won't emulate anything. Way back then, it was mostly used to try to get DX8/9 games to work on DX7 hardware (often to trainwreck/slow results), and its hooking wasn't very stable.

SDL2 does have a screensaver-disabling function and disables screensavers by default.

On the PCX1/2 front, this repository just happened

https://github.com/powervr-graphics/PowerVR-Series1

No tech docs, but the simulat2 (PCX1) and simulat3 (PCX2) folders have a lot of juicy bits for emulation reference in there as that's simulator code (among hardware registers, etc).

As-is? Not many, as that's when CD protection started to peak.

Practically speaking, the SSE games that'd be requiring a minimum P3/AthlonXP would be late 2005 stuff also requiring GPUs far beyond feasible emulation (and also at this time, pixel shader 2 was starting to be seen as obsolete by some big developers already as nVidia pushes ps_30 hard)...

Bump for technical inspiration as there's recently been a DOSbox fork about it (intended for upstream)

https://github.com/jrdennisoss/dosboxrm

That's a different realm of usage though. Where PCem emulates, it'd have to emulate all the behavior that comes out of using the hardware, including the Voodoo2's incapabilities. It's not an ultimate turn-of-the-millennium game fixer, but can serve to fill compatibility gaps as time goes on, as even...

When I last tried it on a V2 it went into seemingly a rasterizer mode. Maybe it got support added in a later patch or something, but it definitely wasn't there for the demo.

also note the post dates. Blade of Darkness DOES work on PCem v17's V3 emulation fwiw.

The flag I usually use for self-compiled WIP builds is -flto. It's a little more obscure to set in a cmake makefile (imo) but I haven't noticed any sharp drop of performance from a vNext -flto build (built on GCC 11) compared to a pre-cmake -flto build (built on GCC 4.7). Also logging in a non-relea...

Sometimes blowing away all the devices in device manager and then letting it detect for all the stuff on a different board works. There's also some rare cases of a boot virus affecting detection. There's at least one Win95 CD bootdisk out there that has a virus that sabotages MBRs and/or forces Wind...

It's like that on real hardware yeah, there's recently been one streamer (PMMX233 + ATI Rage + Voodoo2) going through having to clear it up with the menu refresh.

Well.... 1. GCC 4.7.2 (which produces Win95 compatible binaries) can compile up to V17. The dependencies after V12 (Wx and SDL2) will hate Windows 98 though 2. KernelEx can run V12 somewhat pcemme.png 3. While this high-end W9X computer is demonstrating PCem, running certain games natively with this...

Maybe this feature could be a good candidate for the plugin system? Optional and own thread etc...

I don't know what the cause of it is now but in the V17 days i've avoided mounting hard drives to avoid the everlasting process when messing about video-related emulation ideas. Just had some config to mount nothing and head to the WinBIOS

the wx default icon in the low color pixel form happens to resemble 3 crewmates nowadays...

Try -G "MSYS Makefiles" instead

Alright it's built. I'm now seeing a pcem.exe and libpcem.dll. Thank!

Going through that MSYS2 guide (after 3.64gb of dev env prep) deadended me... $ cmake -G "MSYS Makefiles" -DCMAKE_BUILD_TYPE=Release .. CMake Error: Could not create named generator MSYS Makefiles Generators * Unix Makefiles = Generates standard UNIX makefiles. Ninja = Generates build.ninj...

There'd probably still be a CPU bottleneck. <bad idea> unless, somehow ......the CPU is also compute'd. GPUs probably could handle the FPU more precisely, but this all could be impractical memory read hell. Or maybe there's room for cache emulation... AS LONG AS IT'S NOT CUDA :( I have not had a sin...