I don't recall the high pitched sound you're talking about. So I don't know what NESticle's issue was.
Fx3 wrote:
I'm not saying a "60Hz video refresh", but a way to display exactly 60 frames per second during the emulation. Yaya, even the NES isn't exactly 60 FPS, but come on... ;)
You
need to sync to sound (which would produce a ~60.1 Hz framerate) unless you do one of the following work arounds:
- modify the APU (CPU) clock to run slightly slower, so less audio samples are produced each frame (this will lower the pitch of generated audio, and, if you modify the CPU time, will possibly break timing in some games)
- produce more or less audio samples on demand by clocking tone generators more or less as needed (this will cause crackling in games which do timed writes to $4011)
If you do not do one of those two things, and you hold a steady 60 Hz framerate... your sound
will break, probably in the form of buffer overflow (since you'll be producing audio faster than you're outputting it) which will result in a "crack" or break in the audio every few seconds -- the severity of which can differ depending on how you're streaming audio.
Quote:
- I tested this thing in my emu to understand the reason of Allegro's sound output being gasping during the game play... and it worked. The sound was in sync with the frame rate.
This "gasping" is probably your buffer overflowing for the reason mentioned above. I don't know what you're doing now to solve it, but it must be some form of one of the above 3 options.
Quote:
- Technically, there are two explanations, but I know only one of them. If you do 1000/60 = 16.6667 milliseconds per frame and, technically, the lowest unit of time is 1 millisecond, acceptable in the Allegro library (and perhaps Windows too?).
Only way to get exactly 16.666667 milliseconds between each frame
without eating 100% CPU time would be to VSync (and that would only work if the monitor is set to 60 Hz). An exact framerate isn't all
that important, just so long as gameplay isn't jerky.
One of the two timing mechanisms I would recommend is:
- sync to sound: do 1 frame when you are able to output 1 frame's worth of audio. Since your audio buffers empty as the audio is played, this can be used for a steady framerate. Plus it gives you the ideal 60.1 Hz framerate.
- time using the clock (1 frame every 16.6667 milliseconds). You can fall back to this when you're not outputting audio or if you have some other way to prevent audio from breaking.
But I'm really convinced syncing to sound is the best option.
Quote:
- Here's my "unknown" part: plenty of emulators CAN perform 60Hz, I've read a few tidbits there and there, but never a crystal solution. Perhaps by switching into DirectX programming, but what if NOT ? -_-;;
You can land exactly 60 Hz
IF you VSync and
IF the user's monitor is set to 60 Hz refresh rate. But note
vsyncing is not a good way to regulate your framerate unless you specifically change the monitor refresh rate to 60 Hz (which would probably piss more people off than it'd help). I run my monitor at 75 Hz, and I know a lot of people that run theirs at 100+, so if you use VSync to set your framerate, your emu will run
way too fast on our computers.
You don't need to use DirectX to VSync... but I do think it's platform dependent. Some crossplatform libraries have a way to do it (SDL+OpenGL can do it) -- I don't know if allegro does.
Vsync is a great way to smooth out the framerate to make it less jerky. Though if you use it combined with syncing to sound, you'll end up having to skip a frame every once in a while.
Anyway I don't know if I helped or if I just confused you more XD