VOGONS

Search

Common searches

Search results

Display options

Display options

Re: Zdoom fork?

Posted on 2017-05-06, 22:05

The above memory limitation occurs with >110,000 nodes. Artificially limiting the # of nodes allows further reading of the uncompressed ZDBSP format. However, continued reading of this extended format leads to an error in P_RemoveSlimeTrails(). Removing that function remedies the errors and loads …

Re: Zdoom fork?

Posted on 2017-05-06, 07:31

Most of the maps in the Valiant megawad are dependent on the ZDBSP map format. It is listed as a MBF megawad, but requires a doom source port that supports this "zdoom extended node" format. There is a list of these ports from the doomwiki: ZDoom 2.5.0+, GZDoom 1.5.0+, PrBoom+ 2.5.0.7+, Eternity …

Re: Zdoom fork?

Posted on 2017-05-05, 06:51

For testing valiant.wad (2015) maps, the attached eternity.exe may replace the same filename from eternity-dos-v33302.zip. The following maps load with this update: 01, 05, 11, 19, 29. The update is a workaround to startup errors: --- ETERNITY-ORIG//r_data.c 2017-04-22 22:17:17 -0400 +++ ETERNITY …

Re: Quake 2 DOS Port WIP

Posted on 2017-04-30, 19:38

I mainly followed the instructions in your porting guide. And I set cl_async and cl_predict to 0 for testing under low framerates (<7 fps). I recall that cl_predict=1 had less smooth gameplay in that case. Once the fps was at a playable rate, then it was not possible to see this effect. However, I …

Re: Quake 2 DOS Port WIP

Posted on 2017-04-29, 19:14

Thank you. I look forward to using the updated binaries. I also recently tested crbot against your project and attached it. Patched against the "modified" original code here: http://arton.cunst.net/quake/crbot/. And original binaries here: http://arton.cunst.net/quake/crbot/CRBot114.zip (requires …

Re: Zdoom fork?

Posted on 2017-04-27, 04:43

I've been testing hx dos with the different zdoom versions. zdoom v117c (win32) shows video, but doesn't work yet. However, there are a couple of reports that hx dos works with v217. There are hints here: https://forum.zdoom.org/viewtopic.php?f=18&t=9198 The dosbox debugger helped find many of the …

Re: DOSBox-X branch

Posted on 2017-04-27, 04:34

On reading other posts, it seems that UT99 bases its clock on the RDTSC instruction. This makes sense since the instruction depends on cpu speed. In the normal core, tsc is set to CPU_CycleMax. This presumably will vary with cycles=max? If the variation is high, is it feasible to use a fixed real …

Re: DOSBox-X branch

Posted on 2017-04-26, 02:23

Thank you for the help with interpreting the titlebar meters! It seems that performance and estimation of values has a large (or entire) role in the real-time meter values. I also wonder if a meter could be developed to test whether UT99 is running as expected. I recall that it uses the cpu speed …

Re: DOSBox-X branch

Posted on 2017-04-25, 05:19

Further tested the real time meter. I have two questions. First, is the internal timings meter necessary now that the real time meter is now included in dosbox-x? I may have this wrong, but it seems that the real time meter is measuring the rate of ticks assigned to the emulator versus real time; …

Re: DOSBox-X branch

Posted on 2017-04-24, 03:17

Benchmarked in Quake with and without the recent FPS/RT meter code in dosbox-x. There appears to be no discernible cost in running the meters. I also tested by removing that code entirely and the effect is <1%. Thanks!

Re: DOSBox-X branch

Posted on 2017-04-24, 02:07

I should have the performance test soon. With %8s, program name should always display 8 characters in the title bar, but with %.8s the maximum number of characters is 8 while the minimum number of characters is the length of program name. I didn't verify, but %8.8s should correspond to %8s.

Re: DOSBox-X branch

Posted on 2017-04-24, 01:35

It is possible to further conserve space by changing the way "RunningProgram" is printed in the title bar. The lines are in GFX_SetTitle() (sdlmain.cpp). It appears 5x, but an example: sprintf(title,"%s%sDOSBox-X %s, %d cyc/ms, %s", dosbox_title.c_str(),dosbox_title.empty()?"":": ", VERSION,(int) …

Re: DOSBox-X branch

Posted on 2017-04-24, 00:29

It only looks like it's repeated 2X. The MSR and CMPXCHG8B checks are copy-pasta'd once for Pentium and Pentium MMX cases. I see now, sorry about that. I've been surveying all your recent commits! The real time meter looks very interesting, and I would think it would help the speed demo community ( …

Re: Zdoom fork?

Posted on 2017-04-23, 06:09

Eternity v33302 (DOS) will load Back to Saturn X megawad after making this change to the wad's EDFROOT file. The file may be edited in SLumpEd. --- EDFROOT-Orig 2017-04-23 01:44:46 -0400 +++ EDFROOT-Eternity 2017-04-23 01:43:51 -0400 @@ -1,5 +1 @@ stdinclude("root.edf") - -gameproperties { - credit. …

Re: Zdoom fork?

Posted on 2017-04-23, 03:06

Attached Eternity DOS build (v3.33.02). Includes a patch. The binary is built by djgpp and the non-executable files are from the win32 release. These binaries are untested and unsupported. User takes responsibility for their use. Goal is to test further before trying this dos sound subsystem in …

Re: Zdoom fork?

Posted on 2017-04-22, 05:29

The above Eternity DOS build (v3.31.10) seems to work fine. The issue was the non-executable files. This version is newer than v3.31-beta7, so the files should be copied from the v3.31.10 archive here: http://www.gamers.org/pub/idgames/source/ee33110w.zip The attached archive includes the Eternity …

Re: Zdoom fork?

Posted on 2017-04-22, 04:41

Attached a patch for building Eternity v3.31.10 for DOS. The source is available here: https://www.doomworld.com/idgames/source/ee33110s Depends on Allegro 3.x. Tested with Allegro 3.0, but the DOS build is not yet functional even though there is video and audio output. The Eternity DOS binaries for …

Page 20 of 22

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