Nazo […]
Show full quote

Nazo

On the frameskipping thing, I don't think it's fair to compare DOSBox to "other mature emulators" if by that you mean console emulators. Consoles and PCs work pretty differently on the rendering. Namely, consoles almost HAD to synchronize with the television thanks to interlacing, but, what's more, since all TVs had the same basics up until more recently with HDTV, it was quite safe for the console designers to assume the user will have something within a pretty fixed range. With a PC, a monitor operates 100% independantly of the video card (until much more recently with vsync, hich is apparently no easy task for a PC either considering that it requires more power to synchronize) but, what's more, monitors differ in more ways than one can count, supporting different resolutions at different frequencies and such. On a console, if you start rendering massively out of sync with the TV, there will be all sorts of ugly effects thanks to the interpolation. On a PC, thanks to the clarity of the monitor and lack of interpolation (not a
coincidence that interpolated monitors had a short lived lifetime -- though I sure wouldn't mind having one for DVD watching) the absolute worst case scenario is that the video card renders so quickly the monitor is unable to keep up and tearing occurs. Woops, that didn't happen until MUCH more recently.... For starters, before 3D acceleration, it was all up to the CPU to do the actual work, so there was no chance of it going out of control and rendering a scene faster than you expected. It just rendered what it was supposed to when it was supposed to via high resolution timers and such. The video card just had to do what the CPU told it as quickly as
possible (which is where a bad 2D drawing speed became a problem for some windows games I suppose.)

If I'm wrong, well, just in case, I'll be wearing kevlar around you in the near future. d-: If I AM wrong, then, I do agree that it really makes no sense to have to skip in such a manner. In fact, how about taking it more literally, eg whatever number of frames it says to skip, literally skip that, instead of it being more like a ratio with the second number hidden. Eg, if a game is rendering at say 30Hz, and frameskip is set to 1, don't render 15Hz, but, render 29Hz. Sure, it will mean frameskip gets set really high, but, at the same time, it also means some very precice control so you can get it just exactly right for a particular game.

*dons kevlar, just in case*

HunterZ Nazo, some good points. To continue the frameskipping & DOSBox discussion though : It's true that even now games don't […]
Show full quote

HunterZ
Nazo, some good points. To continue the frameskipping & DOSBox discussion though
:
It's true that even now games don't have to synchronize to the monitor, but the monitor is still limited to being able to display at whatever refresh rate it's set to. DOSBox could simulate the same behavior and it could then do automatic frameskipping just like any console emulator. All but a few DOS games use video resolutions with standardized refresh rates that DOSBox could (and may already) take into account.

Also, the idea that it takes more work to do vsync is a common misconception (although I've never had much luck convincing anyone of this). All vsync means is that your computer avoids doing extra work that would otherwise only result in sending more data to your monitor than it can reasonably display in a given period of time anyways. The end result of not doing vsync is that

your system is doing extra work just to produce tearing artifacts (as you mentioned). Disabling vsync is only useful for benchmarking, as it shows how many frames-per-second your system could render if it wasn't limited by the monitor's refresh rate.

I should also mention that it's possible to do vsync in DOS games. I've used DOS graphics SDK/APIs like Allegro that use an interrupt handler or somesuch to do it. I'm also pretty sure that the hardware doesn't normally do anything like this for you, nor was it the case that every DOS game rendered fewer frames-fer-second than the common video refresh rates at the time - I think that people just didn't know about these things back then, so we were able to take them for granted

Nazo […]
Show full quote

Nazo

Hmm.. Well, games DIDN'T take framerates and such into account, they just were designed to run a

certain speed on the certain type of processor at the time, but, I'm 99.999% certain that I never

saw any tearing occur in things such as Duke Nukem 3D and such which were 100% cpu. Meaning their

framerate was definitely below the refresh rate of whatever monitor I had way back whenever (as I

recall, it was an 800x600 screen that could do 1024x768 in some kind of seriously weird mode that

was interlaced or something.) That means it probably didn't have a super-high refresh rate there.

Still, we are in agreement on the important thing here. Games weren't required to output on a

certain frequency. It struck me this is probably how the consoles do it, output video to another

part on a certain frequency and just drop or maybe hold frames -- perhaps with blending or

somesuch, probably relying on the TV to handle it instead -- while the video part of the system

would draw in synchronization with the television. There's no way they would be 100% desyched

because the fact is, people would have seen that beyond any shadow of a doubt, and I had a real

NES, Genesis, and SNES and ever saw that. From what little I did understand in all I've read

about the hardware, it sounds to me like they still hadn't come up with a seperate video

acceleration type of thing until the playstation (which, btw, as a little interesting sidenote,

started in large part based an experimental model created when nintendo wanted to get in on the

booming business of adding a cd-rom to consoles like everyone else was doing but them -- phillips

did the same thing with their own model from the same negotiations, just their system never

REALLY made it off the ground.) With a console, you can just dump frames every now and then, but,

with a PC, well, all I can think is that DOSBox must be emulating the video hardware in every

detail because I don't see how else it skips frames without actually skipping instructions.

I'm not saying maybe a better frameskip method couldn't be possible, I'm just saying it's not

fair to glob dosbox up there with, say, a snes emulator. They just have no relation whatsoever is

what it comes down to. They quite simply work differently. I do, in fact, think that improvements

could be made to the frameskipping still, just, it's not as easy, and definitely not fair to

imply that the DOSBox team aren't working as hard as, say, the ZSNES team (frankly, they're

probably working harder, I haven't seen many updates, and they still have yet to get some things

like Clocktower completely 100% working, though so far I've only found a couple of graphical

glitches.)

HunterZ PSX: Yeah, I heard that Sony was going to do the CD-ROM part of the Super NES but Nintendo blew […]
Show full quote

HunterZ
PSX: Yeah, I heard that Sony was going to do the CD-ROM part of the Super NES but Nintendo blew

them off, so they used their tech to make the PSX - or something like that.

TVs: I think that while the refresh rate is fixed (60Hz for NTSC, 50Hz for PAL), the timing is

still driven by the input signal. As a result, the console still can know when the TV is starting

to draw a new frame. With that said, I see tearing all the time in XBox games and it drives me

nuts.

DOSBox versus console emus: I guess I'll leave it to those more knowledgable to discuss how much

harder it would be for DOSBox to do this. Also, the active development of DOSBox is one of the

reasons I hang out here

Nazo Newbie Starting with Playstation, consoles started using 3D acceleration. This means it's not longer the […]
Show full quote

Nazo
Newbie
Starting with Playstation, consoles started using 3D acceleration. This means it's not longer the

main processing cycles doing the video 100% 2D (even the 3D games were being done via software,

albiet usually with the help of an extra chip, I think doing floating point operations wasn't it?

I think the Super-FX was essentially the SSE of the console world,) it's just as seperate for a

game as it is on PC (at least, in 3D games.) In other words, tearing is possible just due to the

fact that the TV is essentially treated like a monitor, ESPECIALLY by things like XBox that are

even more PC-like than PSX ever was. (In fact, when X-Box first came out, I always insisted that

the reason I refused to buy one was because "I already HAVE a PC, why do I want to buy another?"

Please disregard my signature at this time. Oh well, truth is, I just don't like the direction

consoles have gone. Gone are the days of a specialized system that is radically different from a

real PC capable of doing amazing things far ahead of PCs at the time, now, they're just made to

be more accessable to the average joe.)

I never saw tearing on any of the systems I listed having had. Well, not on my PSX or DreamCast

either, but, I suspect more this is due to the fact that they were being pushed closer to the

limits than that they acted that much like a classic console in that respect. Honestly though, I

suspect my PS2 may be using synchronization as well as interlacing the signal just right or

something because I'll be darned if I've ever seen better quality on this old composite input

only television than I did with it when I play DVDs on that PS2. I can say I've seen better 3D

though......

Either way, the fact is, XBox can tear because XBox = PC with an uberized Geforce 3 Ti (I call it

platinum) hooked to a TV, which is BEGGING for tearing thanks to TV being 29.97 or 25...

Unfortunately, the interlacing double framerate trick won't work if you're treating it like a

monitor and not properly syncing and all.

I have a sneaking suspicion that the reason vsync didn't show up for so long is because it needed

that extra bit of data the monitors could send back that allowed for things like EDID and such. I

know EDID itself is more rare, but, still, I believe even this absolutely ancient cheapo monitor

has been telling my OS certain things, such as what resolutions it can handle and such, because

even when using the "default monitor" driver, it never allows an unacceptable resolution or

anything (I can understand refresh rate since it probably defaults to 60Hz always.)

HunterZ The PSX was definitely only doing integer-based 3D rendering. You can tell by the horrible affine […]
Show full quote

HunterZ
The PSX was definitely only doing integer-based 3D rendering. You can tell by the horrible affine

texture mapping.

Also, vsync has been around for a very very long time on PCs - it's just that most people didn't

know about it. Companies like Apogee/iD were using it in their EGA side-scrollers 15 years ago to

make the scrolling smooth... Vsync (or vertical retrace synchronization or vertical blanking

interrupt timing or whatever) didn't become a known concept to users until 3D accelerators came

along with the option to disable it in order to get higher benchmarking scores.

Also, if you have "default monitor" as your monitor in Windows, then I think it will ignore EDID

and/or DDC information. Try forcing it to the Plug-n-play monitor driver instead. Monitor drivers

are pretty broken in Windows though, so I usually just use Powerstrip or ATI Tray Tools to force

the refresh rate to something higher than 60Hz that my monitors support (I usually aim for

75-85Hz but anything from 70 on up will do).

Nazo Newbie […]
Show full quote

Nazo
Newbie

Well, irregardless, my point being here that the systems from the PSX on upward can't be compared

to earlier systems in their rendering methods. I have several points I'd like to make, but, the

fact is, we're starting to hijack this thread at this rate. In the end, what it boils down to is

that I have never heard of a real SNES, Genesis, or whatever having the tear effect. I don't know

if they had something so complicated as a video synchronization even, perhaps it just matched the

frequency of the AC power, but, I do know that one of the tricks to the way such systems worked

is that at some point in their processes, they are rendering at a fixed rate. In fact, I recall a

NES emulator which allowed you to actually change that fixed rate to speed up or slow down

emulation in some very interesting ways (I liked to switch it from the default of 60 to 70 so

games ran just a tad faster, but, not too much so. Whether or not internally that number was

divided by two or three, or whatever, I don't know. It probably was exactly 30 or 60 and just let

the TV drop the frame it drops I suppose though. One thing consoles such as those were not

innocent of was skipping, so what's one more skip?) So, all you have to do to speed up or slow

down a console emulator like that is have it render at a different rate. Simply drop occasional

video frame rather than emulating the process involved in drawing it out (since the actual

drawing part was software for such systems, that means they run notably faster if you cease

emulating the process from the video part onward for a frame.) I recall that some of the

complaints for later upgrades such as the PC-FX was that the hardware wasn't actually able to

keep up just because the video hardware was upgraded so that very little benefit actually

occured. In fact, I've never seen a PC-FX game, but, most of the screenshots I've seen looked

like they could have been on a NES just as easily -- with the exception that it did look like

maybe it was able to do FMV at last, or at least closer to it than the PCE ever hoped to do.

A PC, on the other hand, is NOT at a fixed framerate. An individual game could be rendering under

1 FPS as it only has to toss up a new single frame once in a blue moon and change nothing else,

and I'm pretty sure it doesn't just sit there rerendering the same scene either (especially

considering that we would have noticed the "flicker" on that particular hardware since it was

slow enough at updating a single screen I might add...) We all agree on this much. So, I guess

the question is, just exactly how COULD it be improved upon? I'm guessing that DOSBox isn't

sitting there trying to guess at a framerate or something. I suspect it's actually watching the

calls for the video card, that sort of thing and just not emulating any more than is needed to

satisfy the program that the draw occured so that it is able to just simply work on whatever

framerate actually exists in the particular condition. It could maybe keep some kind of counter

and dump every third frame or something maybe, but, wouldn't this make things run a little less

fluidly by essentially throwing off the flow?

I think our biggest problem here is that quite possibly all PC games before 3D acceleration were

designed to pretty well run on a particular system more or less and pushed the limits as much as

they could on that system, but, didn't really scale upward, only downward by removing things (or

even rendering less such as in the case of making the window smaller in Wolfenstein, Doom, etc.)

Most had speed limiters designed to keep them running smoothly so that even if you have a

P4-3.4GHz, and if you try to run Doom right now in a real dos session, it will not zip by faster

than you can blink, but will run just about the same as if you'd run it on a 386/25, or whatever

it was intended to run on, on which system it will be pretty well pushing the limits to the point

that you can't add much more without slowing things down (probably a little leeway so they can

take liberties such as a room full to the brim of monsters or something.) So, in essense, the

individual game runs on a fixed framerate I guess, but, we don't know what that is, and if we

toss them out unevenly, since we don't know what it is, won't it cause things to feel jerky?

Anyone have better ideas or know more specifically how it actually works?

HunterZ […]
Show full quote

HunterZ

Location: Down and to the left of Seattle Nazo: I think we're splitting hairs and going off

into the weeds and possibly engaging in several other figures of speech. I think you're confusing

the fact that while a game may not update the video card's screen buffer 60 times a second, the

video card will still send something to the monitor 60 times per second (even if it's what it

sent the last frame). In non-accelerated 2D games, the video card is really just a memory buffer

between the game and the monitor where it updates the picture of what's going on every once in a

while, and the video card sends that to the monitor every 1/60th of a second (or whatever the

monitor refresh rate happens to be).

To simplify things and get back to the point: I still maintain that, provided that DOSBox is

doing full-screen updates at a fixed interval (which may be complicated by the smart screen

patch, but I can otherwise surmise is being done since it supports double-buffering in full

screen among other things), it would not be difficult for it to skip at least some aspects of

rendering and displaying a given frame. This is a sufficient condition to allow some sort of

automatic frameskipping to be implemented.

Yes, it will definitely make it feel jerky if the host system isn't able to emulate things fast

enough to let DOSBox render every frame, and if DOSBox subsequently decides to skip drawing a few

frames. This is exactly what console emulators do now, and should be possible to implement

without affecting the emulated games. It would also help reduce stress on the host system and OS

if the user turns the cycles up too high for it to emulate things at full speed, and in my

opinion throwing out 1 or 2 frames every once in a while is a lot less jerky than throwing 1 out

every few frames.

gulikoza […]
Show full quote

gulikoza

I agree on the console part...the developers know the system so it's easier to create games and I

do think they were synced to TV refreshes (I remember some PAL games were running slower because

of NTSC-PAL framerate difference).

As for PC...things are not so simple. No, the games are not running at the fixed rate. Some of

them have frame limiters, some don't. Some will run too fast or too slow on some systems, some

will do frameskipping on their own (ever run Doom on a 386 ). Video cards just read a portion of

the memory (framebuffer) at a constant rate (60, 70Hz, depending on the refresh rate) drawing

whatever contents the memory describes. Games can either wait for a frame to finish drawing

before replacing the contents (wait for vsync) or simply draw into the buffer whenever they feel

like it. That's when you get tearing. Same thing for DOSBox. Get my build with a frame counter in

the top bar, you will exactly see at what rate DOSBox is drawing the picture. There is no way for

DOSBox to know when a game has drawn one complete frame and is ready to display it.

Also...adjusting frameskip will only adjust the rate DOSBox displays the game not how the game

renders. The game will still render those frames. So I see no simple solution how to implement an

automatic frame skipping...

Nazo how can you type that fast...I have trouble reading all your posts

Nazo Newbie […]
Show full quote

Nazo
Newbie

Joined: 2005-07-28
Posts: 34
Console emulators never felt jerky to me except when they dropped a bunch of frames in a

row. The autoframerate feature always felt smooth as long as the system wasn't so bad it had to

go below 24FPS or so. And that's more because at somewhere around that point the human eye starts

to definitely notice even a full screen update missing irregardless of any blending or whatever

that may be going on.) Bear in mind that I had direct experience with this sort of thing because

some of the best SNES games I ever played, such as Chrono Trigger, were after my SNES had already

died and I tried playing them on a P1-90 (yep, had to use 8-bit colors and such, and even then

still got bad results often enough.) Once you start dropping frames one after the other in a row,

even a monkey can see it because suddenly in one split second something has jumped a lot further

than it should have between frames, but, if you just drop one here and there, it's a lot harder

to notice even though the net effect can be the same. Perhaps this is a sort of "smoothing"

effect on the autodropping system or something, I don't know, I just know that those games ran

great until they had to start dropping frame after frame.

EDIT: I'm a fast typist I guess. I thought I wasn't, seems like I normally do around 40WPM, but,

I will admit that once I was on a roll in a typing tutor thing and repeated the same lesson and

it clocked me as going over 90. (No speeding ticket for that one, bwaha- *runs in fear*)

Freddo Member […]
Show full quote

Freddo
Member

Joined: 2003-10-29
Posts: 213
Location: Sweden This off-topic discussion about vsync should be split into it's own

thread. Stupid as I am, I'm gonna continue with it, though

One important aspect here is timing. Everything in a game have to be timed. How many pixels a

sprite move per second, and how long one have to hold down the button, and a whole lot of more

stuff.

One very cheap way to time things, is by using Vsync which have existed since the dawn of time.

Since it does not rely on any hardware timers or the CPU to do the timing, it's a very cheap way

of timing things on "poor" hardware, such as the machines from the 80s.

One big thing with Vsync is that the timing isn't "how many pixels a sprite move per second", but

"how many pixels a sprite move per frame". When the whole basis of timing is founded on the

amount of frames, which is the appearance of the "fixed speed" Nazo talks about.

The vast majority of console games were made in Japan (where they use NTSC like US) so games were

made for a fixed Vsync timing of 60Hz. When they later were released in Europe (which have PAL

which offer slightly bigger resolution, better colors and a 50Hz) they ran 1/6th too slow. This

is not something I realised back then. It wasn't until '96 or so when I played Mega Man 2 and

Zelda on a emulator I was thinking "arn't these games running too fast?" Of course, they didn't.

It was just that I was used for them running too slow!

And there are still console games of today that use Vsync timing. Like the latest Castlevania for

the PS2. Fortunally, the european version of the game offer the player the option if he wants to

play it in 50Hz or 60Hz, do it doesn't matter that much. And then there are many console games

that are nowdays ported correctly, and re-timed for PAL.

Computers from the 80s relied on Vsync timing aswell, like the Commodore64, Amiga and the PC.

However, with the arrival of some games in the early 90s, such as Wolfenstein3D and Doom, the

developers moved the timing from Vsync to the CPU, and instead did the timing "how many pixels a

sprite move per second" and pump out as many frames possible during that second. Something that

more consuming, and more portable.

masta_g_86 wrote:

From what I've heard, DOSBox handles frameskip rather oddly. With frameskip set to "1", DOSBox skips every other frame, taking DOOM from a maximum of 35fps to 17.5fps. Set to "2", DOSBox skips 2 frames and draws 1 (11.55fps)

This post is incorrect. Frameskip relates to refresh rate, not game speed. Frameskip set to "1" will draw 35 fps when refresh is 70Hz and 30 @ 60Hz. This is however a big step...

Qbix wrote:

And I like frameskip to think as something that skips more if you increase the number.

There's no reason this cannot be done like this: add fs 1/2 (draw 2, skip 1). This would add an intermediate step (~46 fps @ 70Hz). An automatic frameskip requires "smartupdate" patch (in one form or another)...the thread is just becoming interesting 😀