CRT monitor 85Hz at 60fps?

I have a CRT monitor set to 1280x1024 / 85Hz, RetroArch tells me it goes 60fps, and in the output settings it says, Display-Reported Refresh Rate 60,000Hz.

Shouldn’t it run at 85fps?

Postscript: It is necessary a category of hardware for these things and other settings.

RetroArch will run at whatever modeline the OS is using at launch time unless you have values in the video_fullscreen_x/y and video_refresh_rate settings, in which case it will attempt to snap to the nearest valid modeline to those settings.

However, you probably don’t want to run at 85 Hz for emulators, as most of them run at ~60 fps, so you’ll get really choppy scrolling.

1 Like

I understand that in 2d games it can be a problem because there are many frame-by-frame animations, but 3d games are by interpolation, they will benefit from a high frame rate. A Metroid prime or FX-Zero at 144Hz can be crazy.

You mean crazy fast ? I don’t think those games will be very playable if you run them at 2.5x their original speed, which is what happens when you run 60Hz content at 144Hz (without inserting “black frames”).

Anyway, you can probably force those games at this wrong refresh rate if you want, most likely you just need to force your display at that refresh rate then enabling vsync without enabling the other sync options ? (assuming the core isn’t still limiting it by other means)

No, keep the original speed but at 120, 144, 240fps or whatever the monitor supports.

In PC games it can be played at 60pfs or 144fps depending on whether the monitor supports it and does not vary the speed.

Why is there this limitation in emulators?

You are comparing melons with apples… PC games are meant to be playable on hardware with different specs, consoles are meant to be played always with the same hardware with its limitations. A gamecube game is meant to render 50/60 frames per second, it’s hardcoded, vblank will be called by the game 50/60 times a second and will send the display at that time, period. Actually, even for PC games, i doubt all of them will be compatible with higher refresh rate, most PC games probably have hardcoded refresh rate too.

They are different hardware, I know, but emulation is the universe of the hack. PSX can be played in HD with all graphics flaws fixed or Daytona from Dreamcast can be played in 4k with a high definition texture pack.

I mean, how utopian can it be to hack the emulator to run at 120, 144 or the fps that the monitor allows?

3D games are going to benefit greatly, but 3d too. For example, Sonic’s walking is frame by frame, that doesn’t change. The movement of the background is animation by interpolation, it goes much more fluid.

Well, you don’t understand the issue isn’t about the emulator but about the content…

The thing is, when your gamecube game renders a frame, it then starts preparing the frame that will be rendered 1/60 second later. Now what happens if you decide to render something 1/144 second later instead ? The answer is simple : the frame won’t be ready and whatever will be sent to the display was never meant to be displayed. Could be something usable, could be a black screen, could be something partially rendered, it’s shroedinger cat.

You compare this with upscaling, but upscaling is “just” about increasing dimensions using formulas, it’s totally different from rendering something that basically doesn’t exist.

Yes, I understand that scaling improvements are based on a processed frame, I mean before. Who is in charge of saying, draw the frames at 30 or 60fps? Can’t he tell himself that I draw the frames at 144Hz?

All the Beetle PSX HW’s or things like Run-Ahead Latency, are they scaled?

Maybe they are very innocent questions, they should charge rookie membership :grimacing:

The game.

I already tried to explain you that those frames don’t exist. The game is programmed to produce 30/50/60 usable frames per second, anything in-between is shroedinger’s cat. Now, if you were a rom hacker with godly skills at hacking gamecube games, maybe you could overwrite that, maybe.

It is interpolation of movement, from point A to point B. The CPU defines how many FPS it is going to use and the GPu shows them.

Now, if you were a rom hacker with godly skills at hacking gamecube games, maybe you could overwrite that, maybe .

The question is not, if it is difficult. It will be reality at some point, without a doubt. :relieved:

I believe what barbudreadmon is getting at is that there is no intermediate state to interpolate. For a very abstract example: if you’re counting by 2s, you have 2, 4, 6, 8 … etc. At no point is there an intermediate step where your value is 5. You may intuit that 5 is in there somewhere, but you’re going to have to make it up whole-cloth.

In many modern PC games, the games’ logic is decoupled from the framerate so it can use a separate “tick” (maybe actual milliseconds) and it doesn’t matter how many ticks go by between spitting out a snapshot (that is, a frame of video and collection of audio samples). In fixed-framerate games–including emulators–the framerate is the tick, so if you push out more frame ticks, you’re pushing out more logic ticks, too.

Well, point B isn’t yet known at the moment you need it for interpolation, so all of this (determining possible points B from possible inputs - understand runahead - then do the motion interpolation between point A and possible(s) point(s) B, for 144Hz you already need multiple interpolations between A & B) would be very computationally expensive, keep in mind we can’t even use runahead for systems like gamecube at the moment…

With hardware several times more powerful than what is available right now, maybe ?

Also, i found that topic on dolphin forum :

I do not mean to generate frames by interpolating 2 existing ones, rather, to do a hack to generate them natively from the emulator’s cpu/gpu.

In fixed-framerate games–including emulators–the framerate is the tick

I understand it in 2D games, many frame by frame animations are based on a 60fps template, but does it also apply to 3d games?

All games have libraries of animations with beginning and end, they go from point A to point B, that is generated in 3D space. From the moment the button is pressed to throw a ball, the 30/60fps from A to B is drawn, unless, of course, the animation is interrupted with another event.

would be very computationally expensive

I know, generating 144fps instead of 60fps is going to be more expensive and more in emulation.

It is not about generating 144fps of the rendered 60fps, that would be insane of resources and also a false increase in frames, it does not look good.

What he thought is, if the game sets the frames to be used 30/60, that command should be changed to 144Hz (or those supported by the monitor). Let the CPU understand that it has to do the calculations for 144fps and send them to the GPU to render them. Yes, it is resource consuming, but with the Cards you have today you can.

I don’t know about 144fps, but there are plenty of cheat codes that enable true 60fps (at proper speed) for games that originally run at a lower frame rate. (PSP/PS/N64 games) Obviously you’ll need game-specific cheat codes for each game. Not sure if it’s possible to achieve an ultra high frame rate like 144fps using cheat codes.

Yes, apparently Dolphin already does it, with the genko codes they can be obtained. I have seen several of 120fps.

Why won’t you understand that every single command amongst the billions the game is sending to the console would potentially need to be changed to achieve this. Let’s think with a very simplified program of 10 instructions that goes like this :

  • execute 9 commands, each drawing a line
  • 10th command send this to the display

At the end of those 10 instructions, you got 9 lines drawn on screen.

Now, what you want here is having something ready to be displayed at 4th instruction, how would you do that without fundamentally changing what the program does, making it a totally new program ? If you don’t rewrite the program and only execute the display command at 4th instruction, you’ll end up with a screen with only 3 lines, is that the result you are expecting ? I’m not saying there won’t be rare cases where the result after those 4 instructions would be usable, but that would be a very small minority of games.

Cita Why won’t you understand that…

It’s just that I’m not that smart.

Anyway, this is just an idea, if it is achieved it is wonderful, if it is not achieved, nothing happens.

The problem is that I am a dreamer and the world of emulation is the world of “the impossible”

  • Sonic on a PC, it’s another engineering, that’s impossible,
  • Emulate Nintendo 64? It is a very powerful machine, it will never be achieved
  • Saturn, impossible, it is too difficult an architecture.
  • Emulators will always have lag.

And well, like I said, whatever happens is going to be fine. A hug!