Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support widescreen resolutions #29

Open
GoogleCodeExporter opened this issue Sep 16, 2015 · 21 comments
Open

Support widescreen resolutions #29

GoogleCodeExporter opened this issue Sep 16, 2015 · 21 comments

Comments

@GoogleCodeExporter
Copy link

It has been requested to support widescreen resolutions in the
RiceVideoLinux video plugin.  The most straight forward way to do this is
to use pillarboxing.

It has also been noted that some video plugins (for which the source is not
available) support widescreen with an extended clipping frustrum to render
a larger volume of the scene.  This would be an excellent feature but may
be difficult to implement or have unavoidable side effects.

Original issue reported on code.google.com by [email protected] on 29 Mar 2008 at 6:29

@GoogleCodeExporter
Copy link
Author

Original comment by [email protected] on 29 Mar 2008 at 6:29

@GoogleCodeExporter
Copy link
Author

Issue 54 has been merged into this issue.

Original comment by [email protected] on 8 Jan 2010 at 5:18

@GoogleCodeExporter
Copy link
Author

Almost done!

It's more difficult that it can seems. -_-

Original comment by [email protected] on 12 Mar 2010 at 2:39

Attachments:

@GoogleCodeExporter
Copy link
Author

Hmm, for some games I prefer the current behavior (simply cropping the outside 
of a
larger 4:3 resolution) :-/.  Admittedly I'm on the ancient source tree, though 
(not
2).  Is there a better way to utilize screen real estate?  My plasma will 
probably do
something goofy with this w/auto scaling, so it should be an interesting 
experiment.  

Original comment by [email protected] on 12 Mar 2010 at 3:02

@GoogleCodeExporter
Copy link
Author

What config should be like?
What about choose among keep aspect, stretch and zoom in a config dialog?

Original comment by [email protected] on 12 Mar 2010 at 3:03

@GoogleCodeExporter
Copy link
Author

Is there a better way to utilize screen real estate? << Not for now. :/
What config should be like? << The test you see is made by me.

I'm currently trying to dev this feature. But more I advance, more I think I'm 
not
using the good solution.

Here, I'm working on "offset all"... But I'm block. I thinks it's not the good
solution. Maybe a "real" dev will help me to find a better way.

I suppose the simplest way should be to create 2 framebuffers and blit the 
small (for
ex 4:3) to the big (ex 16:9)...

I will continue as I do unless a dev told me a better way...

Original comment by [email protected] on 12 Mar 2010 at 3:27

@GoogleCodeExporter
Copy link
Author

Aaaaaaarghh!!!!

Original comment by [email protected] on 12 Mar 2010 at 4:07

Attachments:

@GoogleCodeExporter
Copy link
Author

I have the impression that I can't dissociate the windows size from the buffer 
size...

Original comment by [email protected] on 12 Mar 2010 at 4:54

@GoogleCodeExporter
Copy link
Author

A widescreen hack (like in dolphin and PJ64's override aspect ratio) should be 
top priority!! just look how gorgeus the Zeldas look with PJ64 in 16:9 -- like 
if the engine was made with 16:9 in mind. even the text boxes stay in the 
middle with a 4:3 size, like most 16:9 games!

Pillarboxing? MEH. that would be completely stupid, the user can choose to have 
a 4:3 sized window for that, a 16:9 window would just be bigger with wasted 
black space.

However, it's true some games, like SM64 do not handle it correctly. 
Mupen64Plus should default to stretching, and Aspect Ratio Override should be a 
check box in Rice's configuration - so that the normal user will not experience 
weirdness, and the one who knows will expect it.

Original comment by [email protected] on 15 Jul 2010 at 4:43

@GoogleCodeExporter
Copy link
Author

P.S. you could look at dolphin's GL Video plugin source - I'm perfectly aware 
that the GC and the N64 are completely different, but at least you could get an 
idea of how to do it...

Original comment by [email protected] on 15 Jul 2010 at 4:44

@GoogleCodeExporter
Copy link
Author

Currently there is no "checkbox" in version 2 :(.  Somebody needs to write a 
decent frontend to the plugin configuration files.

Original comment by [email protected] on 15 Jul 2010 at 2:23

@GoogleCodeExporter
Copy link
Author

nevermind the checkbox, it was just an example of how it would look in a GUI.
and anyways, the checkbox would activate an OverrideAspect (or something like 
that) option in RiceVideo.cfg

right now, v2 is just not meant for people who need GUIs to understand :S

Original comment by [email protected] on 16 Jul 2010 at 10:20

@GoogleCodeExporter
Copy link
Author

@mikeloco14: I've "a little" work on the dolphin GL Video plugin. But with it, 
it's easy because it use "new features" of OpenGL, and, in the case of "ratio", 
dolphin plugin use framebuffer. The dolphin's GL Video code is more clear 
because Rice is much older and has evolved over time.

I'm not enough good to add framebuffer to the code myself But it's sure it 
would be a huge feature.

About the choice to add pillarboxing it's because, currently, if you try to put 
a 4:3 game in full screen on a 16:9 screen, game is streched (could the a 
"poor" hack for people wich want to play with 16:9 games ^^ ).

IMO, and having worked a bit in the Rice Video code, a good way could be to 
rewrite the "hardware part" (OpenGL) of the code but this (the "hardware part") 
is very integrated to the code (it's a real "spaghetti code", depending of many 
options).

The best way could be to rewrite it from zero (copy-pasting many of the 
"software part" code wich work well) but it's completly impossible for now 
because the N64 scene is not active anymore and a video plugins for N64 is very 
complicate to write.

There is dev wich work on mupen64plus for XBox (and many others platforms) and, 
I suppose, will write a Video plugin DX9 compatible. I don't know where the 
project is and if it will be out one day. But rewrite a clean video plugin for 
mupen64plus would be the best way toi avoid this "poor probs" (problems in 
integrating pillarboxing and the ratio/pixel is indicative of a fund problem in 
the code...).

Has I said, I'm not enouth good to rewrite a video plugin from zero, but if 
someone is and would like to be helped, I can do it! :)

The prob is the same with the lack of GUI: The API has been rewrite too and old 
GUIs are not working anymore. Devs are needed to either make the old GUI 
compatible, or create a whole new GUI.

If you think you are able to do that, don't hesitate, you will be helped! :)

Original comment by [email protected] on 18 Jul 2010 at 11:29

@GoogleCodeExporter
Copy link
Author

@dorian.fevrier: of course I won't! I suck at programming ;)
but then, as for the pillarbox, that's true, I forgot about monitors stretching 
4:3 (I'm always on my macbook, and laptops don't stretch.)
just remember to label it 16:9 Pillarboxing or something like that to avoid 
confusion...

Original comment by [email protected] on 19 Jul 2010 at 9:15

@GoogleCodeExporter
Copy link
Author

Nothing comes out right there are only outlines!

Original comment by [email protected] on 29 Aug 2010 at 4:57

@GoogleCodeExporter
Copy link
Author

In case other people have an issue, a good workaround, when possible, is to 
create custom 4:3 resolutions that match the vertical resolution of your 
screen.  For example, for 1920x1080 you make a 1440x1080 resolution, and so on 
and so forth for 960x720, 1200x900, etc. etc.  Then set game resolution to 
match what you made available and SDL will induce the driver to change to that 
mode, pillarboxing the output.  To do in nVidia on Windows, for example, nVidia 
control panel, change resolution, customize, create custom resolution.

I didn't dig into it, but SDL documentation *suggested* that SDL should have 
been pillarboxing automatically if used correctly, which would make this 
something worth investigating between SDL and core, not the video plugin.

Original comment by [email protected] on 9 Dec 2012 at 2:45

@GoogleCodeExporter
Copy link
Author

At least there should be a way to stretch the image to 16:9 full screen, 
Glide64 should be able to provide an example how to do that. The android port 
also seems to have this feature in both Rice and glN64 plugins. If GE or other 
widescreen games are set to 16:9 output as well, the result is quite nice. And 
a centered PillarBox is much better than a left-side one.

Original comment by [email protected] on 8 Jan 2013 at 4:24

@GoogleCodeExporter
Copy link
Author

Another workaround its the pcsx2/pc way, simply override the res in the games, 
and add that hack as a cheat. Of course you'll need to do some research on each 
game, but if you get zelda/rayman/shadowman etc and the other "jewels" it would 
be enough for most people.

Original comment by [email protected] on 30 Apr 2013 at 5:32

@GoogleCodeExporter
Copy link
Author

Okay well for anyone who's interested, I'm going to find the code where it 
makes an SDL_Window, and force that window to be borderless, and centered 
within the horizontal position of the current screen resolution.  So you just 
specify a 4:3 resolution that fits within the vertical resolution of your 
display, and there you have it - correct ratio, just you have to hide the 
taskbar, and your desktop will be visible on the sides.  But it will work well 
for my arcade machine I'm building, where I want to hide the sides of the 
widescreen monitor I'm using, to create a traditional 4:3 viewing area.

Shouldn't be an issue to override Windowed mode in this way, the current 
implementation just floats the window randomly somewhere on the screen, it's 
not even centered, and you can close the game with ESC, no need to press the 
red X.

Original comment by [email protected] on 22 Dec 2013 at 10:17

@GoogleCodeExporter
Copy link
Author

@19:

...or, if you're using Openbox, KWin, or any other window manager with 
per-application settings, you could just configure the WM to launch it in a 
certain position and without borders. That'd be simpler than going code diving.

Original comment by [email protected] on 22 Dec 2013 at 10:24

@GoogleCodeExporter
Copy link
Author

If you want an advanced graphics plugin with such advanced features then you 
have to support this campaign to reach more than 10000 dollar (7000 already 
gathered): https://www.indiegogo.com/projects/gliden64-graphics-plugin

Original comment by [email protected] on 2 Sep 2014 at 6:42

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant