#22 Wrong resolution

[Sunjoin]

I have a wrong resolution in fullscreen NTSC mode.

rm dgenrc.auto
dgen -N -H 60 -G 320x224 game_u
video: 320x224, 32 bpp (4 Bpp), 60Hz
video: OpenGL texture 512x256x4 (320x229)

It returns a small stretched rectangle in the center of the screen.
If I run the program again, It returns that

dgen -N -H 60 -G 320x224 game_u
video: 640x480, 32 bpp (4 Bpp), 60Hz
video: OpenGL texture 1024x512x4 (640x461)

and then I have a low bitrate. But everything is OK in fullscreen PAL mode. (except stretching)

rm dgenrc.auto
dgen -P -H 50 -G 320x240 game_j
video: 320x240, 32 bpp (4 Bpp), 50Hz
video: OpenGL texture 512x256x4 (320x245)

and

dgen -P -H 50 -G 320x240 game_j
video: 640x480, 32 bpp (4 Bpp), 50Hz
video: OpenGL texture 512x256x4 (320x253)

Although the resolution in fullscreen mode is bigger.
My system is osx 10.5.8 powerpc g4.

[A. Normal]

Hi Sunjoin,

First off, has it ever worked? If you're using v1.33, is this problem new since v1.32?

The command lines you provide do not enable fullscreen by themselves, I assume you use the fullscreen combo afterwards.

My guess is that the resolutions you want to use (320x224 and 320x240) are not supported by your hardware, and frankly unless it's an old CRT/TV, no need to look further.

What happens is that SDL probably tries to emulate something close to the mode you specify and fails miserably. The fullscreen resolution is probably the lowest supported by your monitor but stretching is certainly still required.

Thus, if you want to specify a fullscreen resolution, it's better to use the native resolution of your monitor (e.g. 1920x1080, 1280x720) or an integer multiple of it (/2, /3 or /4) if it's somehow too slow. DGen/SDL will take care of scaling/stretching accordingly, no need to do it yourself.

Make sure OpenGL is actually accelerated or disable it. There's no point of using OpenGL when it makes things slower.

[Sunjoin]

Hi A. Normal,

This trouble is new. In v1.32 was

dgen -P -H 50 -G 320x240 game_j
video: 320x240, 32 bpp (4 Bpp), 50Hz
video: OpenGL texture 1024x512x4 (640x496)

and

dgen -N -H 60 -G 320x224 game_u
video: 320x224, 32 bpp (4 Bpp), 60Hz
video: OpenGL texture 1024x512x4 (640x464)

So I can't change the OpenGL resolution in fullscreen NTSC mode, can I? I don't understand why

dgen -P -H 50 -G 320x240 game_j

returns

video: OpenGL texture 512x256x4 (320x253)

in v1.33. However it works faster on my system.

Usually I play in PAL mode, but unfortunately some games don't work in it.
I must use OpenGL because the screen is blinking in fullscreen mode without it.

[A. Normal]

There is actually a major difference between v1.32 and v1.33. The latter does not try to resize the resolution to match scaling parameters anymore (it's more logical in windowed mode to let the user resize as he/she pleases). The resolution you provide on the command-line is now used as-is.

In effect, in v1.32 the resolution was always doubled even when it did not make sense. I think you can get a closer result by forcing -S2 on the command-line.

However, forcing resolution with -G on the command-line prevents DGen/SDL from resizing later, even when going fullscreen. You shouldn't provide this parameter at all. If you do, use a resolution supported by your monitor.

If you absolutely want to limit the maximum resolution to make DGen/SDL faster, do not provide -G at all but -S1 (-S2 , -S2, -S3, -S4 etc.). It will only multiply the original screen size (the larger, the slower). The best fullscreen resolution should be automatically chosen accordingly.

Note that the OpenGL texture size does not matter since it's stretched by hardware to match the chosen resolution.

Is it still blinking without OpenGL by the way? Must be the same issue as the fbcon driver in Linux. Doublebuffering is broken on many systems, try disabling bool_doublebuffer. Does that help?

By the way, instead of doing -P or -N -H, you can use -R J, -R X, -R U or -R E to select a region and proper parameters accordingly, see manual. DGen/SDL does autodetection by default.

[Sunjoin]

Well...
I set the native resolution and I had used -S1 parameter. Thank you.

dgen -S1 -G 848x480 game_u
video: 848x480, 32 bpp (4 Bpp), 60Hz
video: OpenGL texture 512x256x4 (320x237)

Now I have to modify my dgenrc file.

Oh, and one more thing. It isn't blinking anymore with the native resolution. But it is still too slow and almost not working at all on my system without OpenGL. It's strange because I have a 1 GHz processor and 2 Gb of RAM.

[A. Normal]

OK, so you are using -S1 because -S2 is too slow?

That may explain why it's slow without OpenGL. If you force -S1 and disable OpenGL at the same time, it's fast but with a small picture, if you don't provide -S1, it's slow because stretching 320x240 to 848x480 is done in software, which is a CPU-intensive operation. When you mean "slow", I'm curious how many FPS is that? (enable bool_fps)

I've run DGen/SDL on slow/old hardware and found it usable with fewer than 500MHz. Make sure you optimize it correctly during compilation, try this:

./configure CFLAGS='-O3 -mcpu=G4' CXXFLAGS='-O3 -mcpu=G4' --disable-hqx && make

1GHz should allow you tu run at full speed with -S2, unless graphics operations are somehow slow (enabling bool_screen_thread may help in that case). Avoid using HQX on a slow machine. No need to even compile it.

The screen is not blinking anymore after forcing bool_doublebuffer to false?

[Sunjoin]

Yes it is.

I've tried to reconfigure the program with your flags.
bool_opengl = false
bool_doublebuffer = false
There are 7 frames per second (average 8, optimal 50)
One frame had been before I did the reconfiguring..
Yes, the screen is not blinking anymore.

bool_opengl = true
bool_doublebuffer = trrue
There are 35 frames per second (average 41, optimal 50)

I've decided to check the v.1.32 with your flags.
bool_opengl = false
bool_doublebuffer = false
There are 51 frames per second (average 48, optimal 50)

bool_opengl = true
bool_doublebuffer = trrue
There are 51 frames per second (average 47, optimal 50)
That's great!

[A. Normal]

Thanks for testing, I didn't realize you were the person who submitted bug #17 and that the bool_doublebuffer issue was already solved.

However, your FPS results surprise me as v1.33 is supposed to be faster than v1.32, at least according to my own benchmarks.

Was that using -S2 (or -S1) in both cases?

In case you aren't using -S1, the performance results with v1.33 may be explained by the different software scaler used by default. v1.33 uses "stretch" while v1.32 used "scale". Can you try the following and compare FPS results:

scaling_startup = scale # should be similar to v1.32

scaling_startup = none # should give the best performance

scaling_startup = scale2x # in some cases faster than "scale" and looks nicer

Thanks in advance.

[Sunjoin]

Yes, that was using -S1 -G 848x480 in both cases.

You are right. I've replaced the scaling_startup value with "scale" and it is working much faster now.

scaling_startup = "scale"
bool_opengl = false
bool_doublebuffer = false
There are 50 frames per second (average 49, optimal 50)
bool_opengl = true
bool_doublebuffer = true
There are 44 frames per second (average 45, optimal 50)

FPS values for "scale2x" and "none" are the same as for "scale"

I've found that in v.1.33 is a different resolution in OpenGL mode.

video: 848x480, 32 bpp (4 Bpp), 50Hz
video: OpenGL texture 512x256x4 (320x253)

In v.1.32 there was

...
video: OpenGL texture 512x256x4 (320x245)

I think that's why it's a bit slower.

[A. Normal]

OK, definitely better. The difference in texture height is explained by the different font used for the command/info bar. Its height was 5 in v1.32, 13 since v1.33.

You can set int_info_height = 5 to get the v1.32 size. You can even set it to 0 but lose the ability to see your own commands (they are printed on the console instead). I'm not sure it could explain the difference in FPS but it's worth trying.

[Sunjoin]

It's a pity that I can't use the software scaler in the soft mode or give to the program more resources. I have a small rectangle in the center of the screen without it.

[A. Normal]

I'm closing this ticket since I don't know what else to do about it. The configuration issue is solved, the performance regression may be addressed in the next release.