PureBasic Forums - English

Nah that looks right, except you used float instead of double.

Also, that pi despite being different from #PI should still produce almost the same result.

And you are storing the pi value in a float which does not have enough precision to hold such a big erm... I mean "small" float number, again doubles is the thing here.

Anyway, I ported my online calc, you can find the source under the zlib license here:
http://www.purebasic.fr/english/viewtopic.php?t=37014

Normally you would not need the string parsing procedure since you would obviously have the old aspect hardcoded (be it 4:3 or 16:10 or 16:9) as what the developer designed the game under, same with oldfov.
The newaspect would be fetched from the user's current resolution at game startup or when they change resolution in the game for example.

Vertical FOV is not included as that is normally a fixed or automatically scaled value in almost all games (or game engines), and as I said the standards out there counts the height of a screen as being 1 thus you see aspect ratios like 2.35:1 etc. (the 1 is vertical aspect)

The reason we also see 4:3 etc is because to a consumer 1.3333333333:1 looks just damn ugly so the shorter decimal form is just easier to read for people.

It shouldn't be too hard to roll your own vertical FOV calculation based on my code either, the math should be pretty much the same.

Enjoy!

Ahhhhh...OK...got ya.

This is just one of those things that I don't have any real experience with, games that is, because I really don't play too many games. So its mostly a curiousity thing which was prompted by a question from a friend. But after reading around the net and this thread and now your code I can understand why people might think or want to adjust this stuff although a lot of the stuff i've read seems a little nit-picky and doesn't really make any difference.

Thank you very much

True, it's a lot of nitpicking.

But if you look at http://www.widescreengamingforum.com/wiki/index.php/FAQ
You will see the different way to handle aspect differences.

Personally there are only 3 correct ways, Hor+ or Anamorhic/Letterboxing/Pillarboxing or Pixel based (few games these days).

Mirrors Edge use Anamorphic to retain the artistic design,
Half-Life 2 use Hor+ to extend the sideview without messing up the height (which could cause characters to loose the head or feet)

An amusing thing with games that use Vert- is those who have 3 monitors for superwide screen, they'll probably be staring at the bellybutton of a character.

If you check the WSGF forums they did certify/review the widescreen of a game recently where the PC port was totally messed up on widescreen. (ironic since the game originally was designed for consoles and 16:9 screens)

Another issue with Vert- for example is when subtitles or dialog selection or HUD interfaces get chopped off.

The worst issue folks usually have with Hor+ is only the GUI being put on the left or right screen (in case of tripple screen setups) and maybe a lack of font scaling (so the font gets really tiny etc.)

Mirrors Edge review at WSGF pointed out something interesting, some of the guys there hacked superwide support, and the font seem to scale up so it was easily readable on a 5040x1080 resolution.

Back in the old days a game was either 320x240 or 640x480 (pixel doubling sometimes as well) resolution, it was only when 800x600 began to appear that scaling support had to be considered. THen the odd sized 5:4 screens appeared.
Now we got 5:4, 4:3, 16:10, 15:9, 16:9, 2.35 (or close to that), and 2x variants of the previous, and 3x variants of the previous.

The interesting thing is that as far as the aspect goes (regardless of resolution), if the developers selected 90 degree vertical FOV then it stays 90 for all those aspect ratios above, only the horizontal FOV is actually need to be changed. Obviously some folks want to adjust the vertical too for a more zoomed in/out view but...

The applications I make I make sure to be able to support up to 32768x32768 resolution (maximum on Windows as far as I can recall),
and any aspect ratio and I treat vertical as being :1
Ideally I should support any DPI (thus font scaling etc.) but thats' a huge pain to get right at least for me currently so higher resolutions make the text/gadgets smaller rather than same "size" but with more pixels (aka details)

Someone semi-joked about the idea of a "Web" OS in that it the OS behaved like a HTML rendering engine on displaying stuff.
That idea may not be as silly as one might think as these days with multiple aspect ratios, resolutions and types of devices you have to adapt to a lot of weird stuff.

A normal application do not need to worry too much, unless you want to support high DPI setups that is.
A fullscreen game on the other hand will need to handle horizontal FOV and aspect ratio properly.

But beyond that there is no need to worry too much, unless you plan to take directly advantage of multiple monitors. (displaying different information on the left and right monitors on a 2 or 3 monitor setup for example, haven't seen any fullscreen games support that yet)
Allowing the user to choose where to place HUD or GUI elements or in-game info/stats/camera "windows" would go a long way to do that though.

Heck, not all modern games support a mousewheel even, let alone the 4th and 5th mousebutton. How long would it take a pro game dev or console porter to add support for that? A couple hours tops? And the user value would be huge compared to the work hours to add it.