Did any dos ports have a fps counter?

[invictius]

Could have sworn that boom or mbf had one in one of the menus but can't find it. Maybe I'm thinking of the windows versions of these ports?

[VGA]

http://www.vogons.org/viewtopic.php?f=24&t=40857

This nice curiosity has an fps counter according to the features. It is an unofficially updated MBF.

[Edward850]

While it isn't quite an FPS counter, vanilla and any ports that keep it have -devparm, which shows the number of tics-per-frame processed. 1 dot would be 35 FPS, 2 dots (constantly) would be 17 FPS, and so on.

[invictius]

VGA said:

http://www.vogons.org/viewtopic.php?f=24&t=40857

This nice curiosity has an fps counter according to the features. It is an unofficially updated MBF.

Is MBF meant to be really unoptimized? Plutonia map 1 went like a slideshow on a 486-100 and map 32 even slowed down quite a lot on a pentium 90. Boom handled all this just fine.

[Linguica]

Are you sure you're not trying to play at 640x400? Because MBF was never any slower than Boom, and that particular MBF variant is supposedly faster than normal old MBF.

[invictius]

Linguica said:

Are you sure you're not trying to play at 640x400? Because MBF was never any slower than Boom, and that particular MBF variant is supposedly faster than normal old MBF.

I'm certain. Down to 19fps in the room full of pinkies and archviles, regardless of all combinations of wait for vertical retrace/page flipping on and off.

[VGA]

invictius said:

I'm certain. Down to 19fps in the room full of pinkies and archviles, regardless of all combinations of wait for vertical retrace/page flipping on and off.

If that 2.04 version is slower than the last official MBF, you should report it on that thread.

Also, how does Doom Legacy 1.41 do?

[invictius]

VGA said:

If that 2.04 version is slower than the last official MBF, you should report it on that thread.

Also, how does Doom Legacy 1.41 do?

Sadly the ticrate command isn't in any of the dos versions of Legacy.

[wesleyjohnson]

DoomLegacy 1.46.1 has a FPS counter, and a FPS graph, for all ports.
It is in the common code. It is activated from the video menu now.
The DOS port code is still there.
However, I have not compiled it under DOS, and have no idea of what problems would
arise right now. I expect some debugging would be needed. I have been updating the DOS port code with any changes to the interfaces so that should not be a problem.

First person in a long time that shown interest in the DOS port.
Compiling for FreeDos or DosBox would also be interesting.
There may be tricks in the DOS specific code might not work for them.

[Danfun64]

If the DOS code doesn't work, it may or may not be a good idea to remove the unused and broken code. Nothing wrong with fixing the DOS code up...but who would use that port on that OS, and would keeping that code hold Legacy back?

On a similar note, is Win9x still supported? (xD)

[wesleyjohnson]

I also have OS2 port code, but do not have OS2 to test it.
The Mac code is the same, I do not have a Mac.
I am not going to delete something from the SVN repository just because I personally do not have the means to test it or have not tested it. Right now, I do not have the means to compile it on DOS due to not having a working compiler on DOS.
But as far as I know the DOS port is still functional, but may have typo errors due to absorbing interface changes without having been compiled lately.

At one time there were team members that had these platforms. It would be wrong to trash the code just because those members are no longer active. The code can sit there until some team member can support it again. It is not hurting anyone.
The SVN is the repository for keeping such code bases, even the inactive and historical code sources.

The 1.46.1 code was tested on Win9x for some of the fixes, but not the Release version.
However there are no patches that I know of since then that would affect the OS compatibility. It should compile fine on Win9x.

It is simply that I do not have the means or time to test every platform port for every patch or even every release.
To make the release binary packages those binaries are tested.
The primary supported ports are the SDL ones.

[HavoX]

You're right, it's definitely not a good idea to delete something just because you're not going to use it anymore. Someone else might find a good use for it.

"One man's trash is another man's treasure."

[chungy]

It's a version control system, removing the code from HEAD will clean it up, not permanently erase it from history.

If somebody is really set on resurrecting DOS support, they can go back to history if needed.

[wesleyjohnson]

Interesting factoid but it misses the point, the inactive platform ports are still
being updated with interface changes and other improvements that the other platform ports get. Deleting them from the current would leave them as obsolete code that no longer works with the newer main code interfaces, leaving a huge mess to be cleaned up by any potential user. Worse yet, the cleanup to bring such a hunk of old code back up to compliance with the main code would have to be done long after the other ports had been done, and by people unfamiliar with those changes. Much easier to just maintain them all together, even the inactive platform ports. It is not that hard to make the same changes to all the platform ports all at once. At least I can leave notes in the code as to what needs to fixed or is incomplete. To do that I need that code to stay active in the SVN repository.

Example: One of the latest changes was to put the FPS display in the main common code. It is now accessed by menu, and uses the common pixel drawing function to display numbers and a graph. Each platform port had previously had its own version of the FPS display, where some were similar and some entirely different. All the code for the FPS display was removed from each platform port, even the inactive ones.

Similar changes for the new sound playing interfaces were made to all the platform ports.

[fraggle]

wesleyjohnson said:

Interesting factoid but it misses the point, the inactive platform ports are still
being updated with interface changes and other improvements that the other platform ports get.

Not if they're never being compiled or tested for those platforms, they aren't. Do you even know if the platform-specific code still compiles?

Honestly, this is just basic good programming practice. Rollbacks and version history exist for a reason. The code's still there if you need to dig it up. In the mean time it's probably reasonable to assume that if you've been already working on the project for years and haven't bothered to get that stuff working, chances are you're never going to do it and you ain't gonna need it.

Basically I'd question your fundamental assumption that it's a good thing that "inactive platform ports are still being updated". If you're never going to actually resurrect those ports then it's wasted effort for a future that's never going to happen. If you ever do decide to resurrect those ports, my experience is that it usually requires investing a bunch of time to get everything compiling and working again anyway, so you might as well put off any updating work until then. Besides, given that these are long obsolete platforms (who uses OS/2 nowadays? really?) you could argue it's just straight-up wasted effort for something nobody needs or wants.

[jerk-o]

If you want to try compiling for dos, you could try using http://www.freedos.org/