VOGONS

Search

Common searches

Search results

Display options

Display options

Re: old opengl-ports of classic shooters

Posted on 2017-09-27, 01:36

MesaFx version 051h-5a has opengl 1.2 compatibility with support for 3dfx Voodoo in Win95. Tested in emulation and Zdoom-CL ran Hexen's MAP01, but there are a few opengl rendering problems. Attached the opengl32 library for testing which is dependent on an installation of the latest 3dfx reference …

Re: old opengl-ports of classic shooters

Posted on 2017-09-26, 00:57

Nice work on zdoom-CL! It has better performance and many more features than dxhexen. It also supports Win95 with the video acceleration set to none while dxhexen produces an error in that case. I like the culling addition, too. I did try your client with Voodoo1 in emulation, but I had an error …

Re: old opengl-ports of classic shooters

Posted on 2017-09-25, 00:11

glhexen v0.9 works with hexen wad version 1.1 in Win95 (and 3dfx Voodoo without paltex option) as discussed earlier in this thread. It ran slow as compared to the directx ports dxhexen and chocolate hexen 2.0 beta 1. Edit: chocolate hexen ran fast and depends on SDL libraries, but replaced its SDL. …

Re: PCEm. Another PC emulator.

Posted on 2017-06-19, 01:23

Testing UT99 non-mmx software renderer in PCem and noted the lighting issue which was previously documented. However, even though the cause is likely the gouraud-shaded triangle routines, it doesn't seem that the colors are mistakenly mismatched. This can be verified by the working mmx software …

Re: DOSBox-X branch

Posted on 2017-06-16, 08:42

Confirmed that UT99 v400 and v428 work with the path 2 game clock. However, later versions are dependent on RDTSC and are not expected to run on a 486 cpu. In this case of path 2, the UT99 log will show that the timestamp is not supported. Presumably, a timestamp parameter value is first estimated …

Re: DOSBox-X branch

Posted on 2017-06-13, 01:51

UT99 likely relies on the CPUID opcode to detect a Pentium like CPU with RDTSC for the game clock (path 1) or instead a 486 like CPU with a presumed timeGetTime() game clock (path 2). Since path 1 (RDTSC) is dependent on a fixed number of cycles in emulation, therefore the non-fixed rate of cycles= …

Re: DOSBox-X branch

Posted on 2017-06-12, 04:16

By logging the RDTSC instruction in dosbox-x (cputype=pentium), verified that the RDTSC instruction is continuously called by UT99 (3dfx mode). However, where cputype is 486, then this instruction is not accessed. A simple text editor shows that timeGetTime() is included in UT99 binary, so a likely …

Re: Zdoom fork?

Posted on 2017-06-11, 20:27

Attached Eternity DOS build (v3.39.20-7). Includes patches and a readme file. Fixed additional issues with menu options, added a video mode console option, and reduced the size of the Allegro library dependency by excluding support for non-8-bit color depths. User takes responsibility for use of …

Re: Zdoom fork?

Posted on 2017-06-08, 07:07

Attached Eternity DOS build (v3.39.20-5). Includes patches and a readme file. Fixed additional issues with menu options and backported code bits from Allegro v442. User takes responsibility for use of binaries.

Re: PCEm. Another PC emulator.

Posted on 2017-06-04, 09:07

Thank you for the information. The MIPS rating of the emulated 486 CPUs seems to also agree with real benchmarking. However, the Pentium CPUs have a much higher MIPS rating than the 486. Doesn't this indicate that the Pentium is processing instructions at a higher rate and that the cycle count does …

Re: PCEm. Another PC emulator.

Posted on 2017-06-04, 00:33

In x86_ops_misc.h, there are several cases of CPU division (x86) which have a higher cycle cost in 486/Pentium. Did the time to complete a division operation increase between the 386 and the 486 design? case 0x30: /*DIV AL,b*/ src16 = AX; if (dst) tempw = src16 / dst; if (dst && !(tempw & 0xff00)) { …

Re: PCEm. Another PC emulator.

Posted on 2017-05-30, 07:49

If all the statistics in the status window are not necessary in a release build, then it may be worthwhile to define the win32 high resolution timer code with preprocessor lines (#if defined HIGH_RES_TIMER). Some of this code is in the inner loop, although I didn't note any obvious effects from the …

Re: DOSBox-X branch

Posted on 2017-05-18, 22:01

The dosbox-x normal core handles the virtual memory system of cwsdpmi (djgpp dpmi provider). However, with unusually high memory use by a dos program, the x86 based core handles the paging slowly which can lead to a page fault. It seems best to avoid paging in these instances by specifying high …

Re: Zdoom fork?

Posted on 2017-05-17, 05:28

Attached Eternity DOS build (v3.39.20-2). Includes patches and a readme file. Fixed issues with menu options. These binaries are unsupported, user takes responsibility for their use. Edit: tested several zdoom 1.23 beta and 2.0 wad files. They load in this version of Eternity, but they depend on …

Re: Zdoom fork?

Posted on 2017-05-16, 06:22

Attached Eternity DOS build (v3.39.20). Includes patches with detailed information. The above issues were resolved. These binaries are unsupported, user takes responsibility for their use. Resolution is changed by v_mode command and ZDBSP maps may require >256Mb of RAM.

Re: Zdoom fork?

Posted on 2017-05-15, 08:19

Attached experimental version of Eternity DOS build (v3.39.20). Includes patches. These binaries are unsupported, user takes responsibility for their use. Note that this version is currently set at VGA only and the ZDBSP maps require >192Mb of RAM. The console input is very slow after starting a …

Re: Zdoom fork?

Posted on 2017-05-07, 23:53

Segmentation violation confirmed by building v3.39.20 a DOS binary. Shows very similar error to v3.33.02 with the uncompressed ZDBSP code. However, it can start vanilla doom until a level is loaded. Attached the patch for v3.39.20 so others could repeat the test. Also, attached patch to build the …

Page 19 of 22

Go to top of page Go to top of page
Close window
Close window