I'd like to know if there's a way to get DosBox or the actual game to display at 60 frames per second.

well i could be wrong but try to set the speed at normal in the option (while playing)

If you want a similar result (but slower) you can just set the ingame speed to "Turbo" by pressing Esc while playing a level .
You can always play with the settings by editing "dosboxT2K.conf" in the install folder (C:\Program Files\GOG.com\Tyrian 2000 - default location on win Xp).

CTRL+F7 = Decreases frameskip
CTRL+F8 = Increases Frameskip
CTRL+F11 = Slows down the game
CTRL+F12 = Speeds up the game

I don't think it ever runs at 60. To my eye it seems capped at 30, or thereabouts.

Frame Rate depends on game speed, they are linked.

Slugmode: 14 fps
Slower: 23 fps
Slow: 29 fps
Normal: 35 fps
Turbo: 47 fps

Playing with the ctrl+f11/12 keys can get you values in between those, and thus game speeds.

Maybe possible to have normal game speed with higher fps with some external program or hacks, i dunno, not gone that far with messing with it.

frame rate depends on the game you are playing, but to my knowledge there isn't a single dos era game that runs at 60 frames. Hardware at the time was incapable of it.

lol.

The NES ran games at 60fps... It has a freakin 1.79Mhz processor.

With simple 4-16 bit graphics it was pretty trivial for hardware of that era to run games at 60+ fps. And I can think of dozens that did run at that frame rate (or higher)

I mean the dos era is also a pretty huge timeframe. Ever heard of quake? certainly runs at 60+ fps, and yea its a dos game. (ported to a million systems now, but the original release was a dos game)

Yea EARLY dos era games (pre 1995) mostly didn't run at 60 fps, but that certainly wasn't because the hardware wasn't capable of it, we were quickly running machines 2-100x+ faster than consoles that did it as a standard.

They simply didn't because they simply weren't programmed like that. The tools available didn't make it at all clear to developers that was a good target frame rate, so they really didn't know what to aim for, so there was never really any standard. Plenty ran at 60+ fps, plenty ran at weird variable rates from 20-50. Pretty much if the guy who developed the game (and most dos games were programmed primarily by just one guy, especially in regards to their graphics engines) though the game looked smooth at whatever frame rate he managed on his machine with his code, thats what he stuck to.

Console games tended to look nicer and smoother in the 83-90s era mainly because they were far more straightforward to program for. They had 1 target hardware only, they had specialized tools that worked well and they had standards to follow.

It took a long time, but PC gaming is really now finally getting really good standards and developer tools that can target a huge variety of hardware and thus perform and look far better than console games to show that the hardware is/was capable of it, it's just a matter of putting in the time to make it work.

We're talking Interlaced video which is something completely different. NTSC standard is 30 frames.

Nope. The original nes could output at a full 60 fps. Actually 60.0988 progressive if you wanna get technical.

The newer crappy NTSC-US toploader that only had a RF-output maybe could only do interlaced video, not sure, gotta read up on my old school rf tech lol. But yea the original had composite output and rf.

ref: https://kb.speeddemosarchive.com/NES_capture

Also technically since we are discussing processing power of the era, even if it could only do interlaced, my point would still stand.. Since to do 30fps/60hz interlaced, the hardware still has to internally render 60 frames a second, then split them - it's actually technically more demanding on the hardware to run interlaced (though that's handled by a separate chip then the cpu)

Also:
http://pcgamingwiki.com/wiki/Home

Has been getting lots of updates, even for oldshool dos games to list what supports 60 fps (and 120). Plenty do from my past I had no idea at the time (and maybe my hardware wasn't managing even close), but these days gotta have my 60fps cuz im spoiled like that :) Thought i still love tyrian despite its low fps (at playable modes since im not a shmup god)

Ha, thanks for the info. Since I posted that ,I found myself doing a little bit more research in that area and was regretting my post. :) But then life hit me and I forgot. It really is amazing what they managed to do back then when you get right down to it, except for certain games like starfox which had its own limitations... and now we can't get a console game above 30. Just a wild guess but I bet the video splitting was done in the box in the middle of the RF output cable, since I'm pretty sure the signal coming out of the NES itself wasn't interlaced. But I could be wrong again.

To be honest at the time framerate wasn't something we thought about as consumers except when it was completely unplayable like under 15 frames a second... But we use to put up with a lot at the time and not think twice about it.. Personally, I don't need Wing Commander to be 60 frames, but modern games, absolutely. We have much better coding practices these days and developers should absolutely take advantage of them.

But I give old things a pass because, that's was the way things were. They are representative of a different time, and I have no problem enjoying them for what they are.

To be fair, I wrote a lot of Tyrian in x86 assembly language so it would run okay on my 386 laptop. I was a kid and that's what Epic paid me forward against the royalties. When computers hit around the era of the Pentium it broke the Turbo Pascal library as it used a 16-bit number to calculate the polling rate for some internal thing. I had to patch it. Obviously, nobody conceived that computers would get so fast.

Tyrian's sprite system was fast due to the routines, but also a unique compression scheme to avoid testing for transparent pixels. Due to the compression I could fit a lot more into the few MB of ram that I had available. I made up my own coding theories as I went along, such as an encryption algorithm I don't know how to break anymore. (Which is what made it so hard for people to reverse engineer it.)

Notably, Jazz Jackrabbit went in the opposite direction, with Arjan achieving maximum speed (I think 60 fps) by compiling the sprites into routines on the fly. Very wasteful, which is why the tile sets didn't have a huge amount of variety, but insanely fast.

I did a lot of Gameboy Advance development in later years (after failing to get a contract for Jazz Jackrabbit 3) and can tell you that Nintendo hardware tended to use a lot of sprites and a hardware system that was more like a tile/sprite engine. You really did very little processing and are just moving sprites or the background coordinates around. And, yet, you'll notice some developers couldn't manage that and had terrible slowdown.

If you want to talk speed, find a weird old game I did called Crushed Baseball. The stadium is a software 3D engine rendering at runtime to a special pixel mode for one of the backgrounds. I could only calculate about, oh, probably was something like 100 polys because the hardware didn't have a multiply instruction. Lots of tricks, but I seem to recall each pixel was ~12 clock cycles to draw thanks to efficiencies in packing ARM instructions.

Also, the speed calculations are not floating point. That would have been silly for processors back then, although nowadays I know about fixed point. Oh well. But that's why there's a fixed frame rate. You'd have to change the whole motion calculations and hope you approximate it correctly to not have to retune all the levels and enemy motion scripting. Doable, I suppose. Haven't looked at that code in SO many years. Hah.

Look for the games I did when I was *really* young on the HP-48 calculator to be amused. 'Course I was too young to know assembler or anything. I eventually found a book on that in my local library, which opened my eyes and led to things like Tyrian.

Nowadays it's mostly Unity and stuff, although for a while I was doing legacy support for Plants vs Zombies 2. Game coding is at a much higher level and a lot of menus and social and whatnot. Lately I'm learning Strange IOC, too, although I have very mixed feelings about that.

Really, it's quite a different ball game now. You never really touch the low level (or even close to it) and optimizing for speed is about figuring out how to tweak your engine or use it "correctly". Assuming you even know what it is doing under the hood.