VOGONS


First post, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

This may have been asked in some other time or place, but I haven't seen it, so here goes: Many other emulators I've used - the vast majority in fact - have a feature called automatic frame skipping. The way this feature works is that if the emulator is unable to do enough processing to emulate the emulated system at full speed, it automatically starts skipping the rendering of some frames. In terms of DOSbox, it would change the frameskip variable dynamically while the emulator is running to be at the lowest value that allows the emulator to run at full speed.

I'm curious as to the reasons why this has not yet been implemented. Hopefully it just hasn't been considered yet, but I can imagine that emulating something as complex as a PC could raise many issues.

Reply 2 of 5, by The Khan Artist

User metadata
Rank Newbie
Rank
Newbie

The problem is: how do you determine what is full speed? Systems like the Genesis and SNES had CPUs that ran at a fixed speed. PCs have hundreds of different possible processor variations. It's really a subjective thing.

Reply 3 of 5, by icemann

User metadata
Rank Member
Rank
Member

Well then is it possible to emulate a specific PC, and get the emulator to think its working on that PC, so that would runs fast on one users computer will run fast on the other and vice versa?

Reply 5 of 5, by mrsbrisby

User metadata
Rank Newbie
Rank
Newbie

It might be possible to use a timer and if we're not updating the frame in-time for the vertical retrace, we can "increase" our frameskip. Perhaps a fractional frameskip could be used... Unfortunately, the overhead in doing so is probably significant as you'd have to do it every cycle (or at least for a while) as not all operations can execute in the same-time, and worse-still, they might not even do it twice in a row.

Another option could be a predictive frameskip- but that would involve assigning a metric to each operation (perhaps how long the "real" x86 takes - in cycles) and seeing how far over we went. This would have the added bonus of allowing a user to specify a "mhz"-looking number for their desired speed, but the downside (At least the most immediate one) is that it'd have even more overhead than the previous idea if the compiler (or a clever mortal) can't find a way to turn that into a simple lookup...