Doesn't sound too wrong for me, it used to be common sense to run the desktop in 16-bit color for avoiding initialization issues with 3dfx Voodoo cards. I know my S3 card supported 32-bit color, and I never used it in the day.
wrote:Yes, But I can't change color depth to more as 16-bit (under jDOSBOX it is possible).
I updated the installation guide which may help. Leileilol's replies are informative, too.
Here is one of the additions to the guide:
Find the S3 video device via the following dialog boxes:
Control Panel -> System -> Device Manager
There may appear two devices matching the S3 video card. If so, disable the device labelled S3 and retain the other device labelled S3 Trio 32/64 PCI (732/764). Press Ok.
Edit: I believe I reproduced the display error by booting the image in jDosBox after using Daum's build. It is not advised to boot via jDosBox after the initial 98SE installation. If it does happen, then follow the suggestion below.
Enter the Control Panel, then Add New Hardware. Select the option to search for new devices, then allow the system to add them. This should fix the display problem. Also, once it is working, then navigate to the Device Manager and remove redundant devices.
Finally everything works (although very slow on my Pentium 1,5 GHz with 2 cores). I would like to thank you guys for your help and patience. I hope, this guide will be moved to "DOSBOX Guides" It's very detailed and very helpful.
wrote:Finally everything works (although very slow on my Pentium 1,5 GHz with 2 cores). I would like to thank you guys for your help and patience. I hope, this guide will be moved to "DOSBOX Guides" It's very detailed and very helpful.
Thanks OSH.
I have similar DosBox performance between a Pentium Dual-Core and a Pentium 4. The former's second Core does not seem to provide a significant benefit.
I also have the impression that typical 3d Windows games are CPU bound in DosBox and therefore the GPU is underutilized. Anecdotes consist of glide games running at similar speeds, regardless of whether the video card is from 2011 or 2004 technology.
I've also wondered if Windows 98 can be reduced to the necessary gaming components, analogous to what nLite has done for other versions of Windows. I did try replacing the shell with GameOS GE, but its functionality is fair. There isn't good reason to run Explorer or Systray in the background and perhaps some of the protected mode devices could be disabled without issue.
I also have some evidence that my Direct3d6/7 graphical anomalies can be attributed to an ATI graphics driver, and not the virtual Voodoo1 graphics card in hardware mode. The anomalies disappear when I run in the same hardware mode, yet pipe the video output through GLdirect's "OpenGL to Direct3D" driver. I don't have a modern Nvidia card to confirm yet that this is an ATI-specific driver issue (verified via newer and older card).
The above anomaly is easily seen in the "dxdiag" test in Windows. The Display2 tab of the dialog box has a button to test the 3d capabilities of the card, both in software and hardware rendering modes. In software rendering mode, there are vertical black lines on the right half of the screen and also the rotating cube appears double in size.
However, I've observed no issues with games dependent on DirectDraw acceleration (up to DirectX7). Excellent scalers provide further benefit in this setup (ie, openglhq) versus other methods of PC emulation. Also, this solution is the most portable and accessible across operating systems; and is not tied to the host.
There's 98Lite, and you could also use Program Manager for the shell if you really wanted to.
wrote:Also, this solution is the most portable and accessible across operating systems; and is not tied to the host.
In terms of "portability and accessibility", Bochs may well be even better.
wrote:There's 98Lite, and you could also use Program Manager for the shell if you really wanted to.
http://www.embeddingwindows.com/ is their professional version which starts hacking out huge chunks of the OS, for embedded applications.
yeah, but Bochs is slow as hell and far less user-friendly. Like many projects, it is focused on just being on as many platforms as possible over having something working nicely.
wrote:There's 98Lite, and you could also use Program Manager for the shell if you really wanted to.
Those are great suggestions. I download 98lite 4.5 from here:
http://www.litepc.com/download.html
It is listed as a preview edition, but here is a quote from its site: "a free, feature rich, no-nags edition of 98lite to trial, or use for life." It is a DOS based program to modify the installation files and shrink the space required by 98SE.
I tried the preview version of lite98 and it is possible to disentangle IE from the OS to some extent and save 10mb; it would be also interesting to have the professional version and reduce the size of the OS to <40mb.
Using dd.exe and writing zeroes to free space on an image, it is possible to then compress the disk image to a very small space (probably <20mb for a 2gb image). This would only be advised after the 98 setup was stable since new drivers would be installed from the installation's CAB files.
Also, the Program Manager shell (progman.exe) worked perfectly. I did the following to install the shell from Windows 3.1:
1. Back up system first
2. Edit c:\windows\system.ini so that the Explorer shell is not active while Progman becomes the new shell:
[boot]
shell=;Explorer.exe
shell=progman.exe
This change can be reversed by removing the line with progman and then activating Explorer by removing the semi-colon.
Windows98SE now boots up even faster in Daum's build and I don't have the occasional error during start-up. It is simple to configure and I could even access the 3.1 file manager, Winfile, via its "Run" menu item. Winfile utilizes the shorter Dos based file names, but one could access Explorer instead. I found Winfile to be very light in memory use, fast, and stable.
Also, to accompany the Progman shell, run the msconfig tool, navigate to the "Startup" tab, and then find the check box for SystemTray, uncheck this box.
If TweakUI was installed via the unofficial service pack for 98, then navigate to the tab labelled "Boot", uncheck "Display splash screen while booting".
On Pentium Dual-Core, Daum/Win98 now boots in <5 seconds.
Edit: added systray, system boot hints; compression of disk image. Optionally, test using IEradicator2001 to remove elements of Internet Explorer; this is an alternative, though less effective, method to using lite98.
I don't see much hope for windows games when even dos games don't have enough cpu power in dosbox (even with glide wrapper).
wrote:I don't see much hope for windows games when even dos games don't have enough cpu power in dosbox (even with glide wrapper).
Maybe for 1999/2000-era titles or 3D games, but for 2D Pentium 1 era stuff, I think DosBox would suffice.
Well...I've tested DOSBOX test build 2 with Windows 98 SE (German version) and X - Beyond the Frontier 2.2 (German version also) under Windows 7 64 bit and Pentium Dual Core G840 2,8 GHz. After setting voodoo to "auto" and resolution to 640x480 game works ALMOST smooth (although graphic artifacts are still visible). I hope, we can count on full Voodoo 2 emulation. Big companies, like Oracle (VirtualBox) and VMWare (VMWare Workstation) have ZERO interest for creating and development 3d-acceleration solution for Win 9x...we can only count on us self...
wrote:I don't see much hope for windows games when even dos games don't have enough cpu power in dosbox (even with glide wrapper).
Half-Life works pretty well even in 640x480 software rendering.
wrote:wrote:I don't see much hope for windows games when even dos games don't have enough cpu power in dosbox (even with glide wrapper).
Half-Life works pretty well even in 640x480 software rendering.
On the other side Pył works pretty bad in DOS even in glide rendering 😉
There's a big price to pay for constant reads from video memory. 😀
wrote:Well...I've tested DOSBOX test build 2 with Windows 98 SE (German version) and X - Beyond the Frontier 2.2 (German version also) under Windows 7 64 bit and Pentium Dual Core G840 2,8 GHz. After setting voodoo to "auto" and resolution to 640x480 game works ALMOST smooth (although graphic artifacts are still visible). I hope, we can count on full Voodoo 2 emulation. Big companies, like Oracle (VirtualBox) and VMWare (VMWare Workstation) have ZERO interest for creating and development 3d-acceleration solution for Win 9x...we can only count on us self...
It may be worth trying vooodoo=true and then add an opengl32.dll to the DosBox directory. This will bypass the video card driver for opengl and pipe the output to direct3d and then send that to the video card. If this removes the artifacts, then it isolates the video card driver as the probable cause.
The opengl32.dll is found inside a zip file from this site:
http://sourceforge.net/projects/gldirect/
Edits and additions: confirmed that the Direct3D6 anomaly is due to a ATI HD6xxx video configuration; tested with a range of compatible ATI drivers. However, an ATI x800 functioned perfectly in all "dxdiag" tests. I have yet to run openGL tests of the ATI HD6000 series video card. The integrated video chipsets are showing signs of limited function, too.
It may be worthwhile to track which video cards don't work fully with kekko's Voodoo1 in opengl mode, at least for the "dxdiag" test and Direct3D6 games. If this occurs often, then it would be possible that there are OpenGL bugs in the drivers of modern video cards. Is the OpenGL API undergoing exponential decay, too?
A way to test an OpenGL bug is via Linux using the same card or by trying a different card (ATI or Nvidia) in the system. Even when the problem has occurred, it has only been observed on the advanced Direct3D6/7 games.
Another DosBox hint for running in openglnb mode:
In the dosbox.conf, set fullresolution=original. This allowed for stretching of Windows98 to full screen; however, some other settings I tried did not allow for stretching in this mode.
Please note that almost any set of drivers with OpenGL support will include a file named opengl32.dll. You are linking specifically to an OpenGL wrapper.
tried latest ykhwong build (emu/opengl)
sdk test25 is slow/jerky at the beginning, you can speed it up with some keys but it will be slow again if you enter menu with h and leave it. But if you start shameless plug with u and leave it ON, it will be always fast when you enter/leave menu with h.
I think simmilar problem may be happening in Tie Break Tennis when you leave a game with pressing esc twice. The camera is spinning very slow (one frame for a few seconds).
wrote:well, in my test builds I boosted v1 memory up to 12mb (4mb front buffer, 4mb x 2 texture units).
Voodoo1 never mounted so much memory, but architecture and drivers (shared with v2+ cards) supported these figures.
wrote:After setting voodoo to "auto" and resolution to 640x480 game works ALMOST smooth (although graphic artifacts are still visible). I hope, we can count on full Voodoo 2 emulation.
TestBuild-3 is attached (+source code). It is a modified DAUM build+Voodoo1_max. Kekko's Voodoo1 is now fully enabled as described above, reaching the maximum of 12mb of video memory (previously 8mb was available). This should show many of the advantages of the Voodoo2, and in fact the texture quality is now much improved. Graphical glitches should be rarer, too. Also, the framerates may be improved, but the Direct3D7 and Windows Glide games will most likely be limited by CPU rather than GPU. This additional video memory may also benefit DOS games.
I applaud the DosBox developers in choosing CPU emulation as it provides maximum portability and also in choosing SDL. This great advantage will also require a wait for additional host CPU power before the full potential of this setup is realized.
I believe a compatibility list would show that the major bulk of Windows games up to DirectX7 will run.
Hi Truth,
Can you share some benchmark numbers with the build on Voodoo1 emulation?
- PCP Direct3D benchmark
- 3Dfx Wizmark
- Quake 2 timedemo
- Final Reality 1.01
- 3DMark99MAX. I can't get this to run fully, but the results from the 2 game demos should be good.
The above posts have old dosbox builds for testing. I haven't revisited those since near to the upload dates; given there have been many patches introduced since that time (many in the patches and development sub-forums). The simplest, and I believe the more accurate benchmark, is the GLQuake timedemo. However, the results will vary depending on the Voodoo1 emulation and all the patches. I believe Ykhwong's recent build has the Voodoo1 enabled with the higher memory configuration along with many of the patches which do not break other functionality. I use additional patches which work with 3dfx games but may cause older games to fail (although I haven't experienced this problem yet).
Using a slow Core2Duo system, I have playable frame rates in UT99 and certainly in GLQuake (both running with V1 emulation). With the 3dfx stretching patch, I can run them at 512H resolution and then scale to full screen, which provides additional frames per unit time.
