1280x1024 fov question
- Thread starter malcolm
- Start date
1280x1024 is part of old XGA standard. (as well as 1024x768 and 1600x1200, but not 1280x960)
possible reason why IBM used 1024 lines instead of 960 is that 1024 fits nicely on square (squareroot(1024)=32) while 960 does not. (squareroot(960)=30.983866769...) and back in days of MCA, it was mostly likely easier to implement it fast enough than 960 mode.
so black and white 1280x1024 mode takes 160 bytes per line and with 1024 lines it makes exactly 160 kilobytes.
Only VGA modes are directly visible on upper memory area (256Kbytes ram) and for vesa modes, you have to command GFX card to change correct visible area to upper memory window. (don't shoot me If I don't remember right.
) And XGA wasn't no execption. with 8 bpp each line is 1.25 kilobytes on 1280x1024 mode. Again the whole back buffer is then 1280 kilobytes. this makes exactly 5 times more than regular VGA can address while 960 makes 3.75 times (960 / 256). So Memory efficiency is greatly improved. so, in 1280x1024x8bpp we have 5 256KBytes "pages". Still if I recal right , XGA differs from competive VESA standard, addressing frame buffer on "windows" more than full lines as VESA did. afaik, it had frame buffer divided on 5 windows so that writing to first 256KBytes area, data went from 1x1 to 256x1024 area. next 256KBytes went from 257x1 to 512x1024 and so on. With 960 lines would have been much harder to implement.
wheeh... had to pick up my TI-85 and some old Dos programming and PC-hardware books from bookself... hopefully someone got something about all that.
possible reason why IBM used 1024 lines instead of 960 is that 1024 fits nicely on square (squareroot(1024)=32) while 960 does not. (squareroot(960)=30.983866769...) and back in days of MCA, it was mostly likely easier to implement it fast enough than 960 mode.
so black and white 1280x1024 mode takes 160 bytes per line and with 1024 lines it makes exactly 160 kilobytes.
Only VGA modes are directly visible on upper memory area (256Kbytes ram) and for vesa modes, you have to command GFX card to change correct visible area to upper memory window. (don't shoot me If I don't remember right.
) And XGA wasn't no execption. with 8 bpp each line is 1.25 kilobytes on 1280x1024 mode. Again the whole back buffer is then 1280 kilobytes. this makes exactly 5 times more than regular VGA can address while 960 makes 3.75 times (960 / 256). So Memory efficiency is greatly improved. so, in 1280x1024x8bpp we have 5 256KBytes "pages". Still if I recal right , XGA differs from competive VESA standard, addressing frame buffer on "windows" more than full lines as VESA did. afaik, it had frame buffer divided on 5 windows so that writing to first 256KBytes area, data went from 1x1 to 256x1024 area. next 256KBytes went from 257x1 to 512x1024 and so on. With 960 lines would have been much harder to implement.wheeh...
had to pick up my TI-85 and some old Dos programming and PC-hardware books from bookself... hopefully someone got something about all that. Nappe1 said:1280x1024 is part of old XGA standard. (as well as 1024x768 and 1600x1200, but not 1280x960)
possible reason why IBM used 1024 lines instead of 960 is that 1024 fits nicely on square (squareroot(1024)=32) while 960 does not. (squareroot(960)=30.983866769...) and back in days of MCA, it was mostly likely easier to implement it fast enough than 960 mode.
so black and white 1280x1024 mode takes 160 bytes per line and with 1024 lines it makes exactly 160 kilobytes.
Only VGA modes are directly visible on upper memory area (256Kbytes ram) and for vesa modes, you have to command GFX card to change correct visible area to upper memory window. (don't shoot me If I don't remember right.
wheeh...
Thank you Nappe! I always wondered what just why it was 1280x1024 instead of 1280x960. I knew it had something to do with the old XGA standard, but didn't know why it would have used 1024 lines even then.
Might come from the ancient times when computers (and video game systems) used TVs as monitors. In order to create an acceptable output they had to take the vertical screen resolution into account. The 240, 480, 720, ... resolutions were used for NTSC output, the 256, 512, 768,... resolutions for PAL.
One small benefit for 1280x1024 though.
When coding, the most important factor for resolution (for me) is how many lines of code I can fit on the screen. The width of the screen is less important. So when coding, I would definitely opt for 1280x1024 over 1280x960.
(I do however concider anything below 1600x1200 a pain, so I rather not have 1280x1024 anyway. )
When coding, the most important factor for resolution (for me) is how many lines of code I can fit on the screen. The width of the screen is less important. So when coding, I would definitely opt for 1280x1024 over 1280x960.
(I do however concider anything below 1600x1200 a pain, so I rather not have 1280x1024 anyway.
)Basic said:(I do however concider anything below 1600x1200 a pain, so I rather not have 1280x1024 anyway.
for me, 1600x1200 is too small for coding already. one reason more to go card with good multi display features.
I propably would use 1792x1344@85Hz, but AIW Radeon signal quality starts losing sharpness. screen comes blurry. (you cannot see it instantly but with in few minutes you really notice it. especially on normal sized icon texts.)and display is still that HP P1110 (21" flat Trinitron, 1792x1344@85Hz, but now using 1600x1200@85Hz)
You have to make a difference between the aspect ratio of resolution, 3D-transformation, and screen.
If you render a scene with 120° horizontal fov and 90° vertical fov, you have to display it on a 4:3 screen in fullscreen mode (or in a window that is physically 4/3 as wide as it is high) in order to get a 'correct' result. The resolution doesn't matter in this case because the viewport transformation takes care of this.
Most games use this 4:3 transformation aspect ratio, so their 3D graphics will look correct on any 4:3 display regardless of resolution
When handling bitmap objects, the situation is different, because they are usually made based on the assumption that pixels on a screen are square. When running 1280x1024 on a 4:3 screen, pixels aren't square, so bitmaps won't look correct.
However, many 17"-19" TFT displays have a native resolution of 1280x1024 and an aspect ratio of 5:4, so pixels are square but full screen 3D is a bit stretched, though only slightly.
If you render a scene with 120° horizontal fov and 90° vertical fov, you have to display it on a 4:3 screen in fullscreen mode (or in a window that is physically 4/3 as wide as it is high) in order to get a 'correct' result. The resolution doesn't matter in this case because the viewport transformation takes care of this.
Most games use this 4:3 transformation aspect ratio, so their 3D graphics will look correct on any 4:3 display regardless of resolution
When handling bitmap objects, the situation is different, because they are usually made based on the assumption that pixels on a screen are square. When running 1280x1024 on a 4:3 screen, pixels aren't square, so bitmaps won't look correct.
However, many 17"-19" TFT displays have a native resolution of 1280x1024 and an aspect ratio of 5:4, so pixels are square but full screen 3D is a bit stretched, though only slightly.
Nappe1:
I agree that it's better with even higher res than 1600x1200. At work I'm currently running 1920x1440@75Hz with a G400 and Hitatci CM828 combination. It's the first time I've worked at one resolution for more than a month without whishing for more screen space.
Yes, I'm one of the lucky people that aren't the least disturbed by 75Hz monitor refresh, unless I'm realy tired to begin with. If I've just run the monitor at higher refresh, I could see the flicker, but just for a minute or so.
That monitor is btw a great bang for the buck, CM823 is even better.
Xmas:
[nitpick]
120º horiz fov and 90º vert fov doesn't make it 4:3.
tan(120º/2)/tan(90º/2) != 4/3
[/nitpick]
Thanks for the info on flat panels, I've wondered whether a 1280x1024 flat panel were 4:3 or 5:4 (in mm, not pixels of course).
[Edit]
Corrected an error in the nitpick after Hyp-X nitpicked it.
I agree that it's better with even higher res than 1600x1200. At work I'm currently running 1920x1440@75Hz with a G400 and Hitatci CM828 combination. It's the first time I've worked at one resolution for more than a month without whishing for more screen space.
Yes, I'm one of the lucky people that aren't the least disturbed by 75Hz monitor refresh, unless I'm realy tired to begin with. If I've just run the monitor at higher refresh, I could see the flicker, but just for a minute or so.
That monitor is btw a great bang for the buck, CM823 is even better.
Xmas:
[nitpick]
120º horiz fov and 90º vert fov doesn't make it 4:3.
tan(120º/2)/tan(90º/2) != 4/3
[/nitpick]
Thanks for the info on flat panels, I've wondered whether a 1280x1024 flat panel were 4:3 or 5:4 (in mm, not pixels of course).
[Edit]
Corrected an error in the nitpick after Hyp-X nitpicked it.
Basic said:
actually, for me there's no absolute refresh rate that's enough. with small monitor (14" or even smaler) even 60 Hz is fine. But when monitor gets bigger, refresh rate that is ok, goes higher. especially on lower res modes. If I ever have to use 640x480 desktop with this monitor, anything below 100Hz hurts. But then 1024x768 and upwards, 85Hz is enough.
of course it is also depending what you got used to. Before I got this monitor I had *cough* absolutely amazing *cough* 15" KFC (whopping 75Hz at 800x600!!111) so when this tube arrived, it felt like the whole damn room was turning when watching replays in brand new Rally Masters. (big thanks to Digital Illusion guys.
it looked pretty awesome on G400 16MB driving 21 incher. )hmmh... Basic, you are coder from Linköping, right? are you sure that you aren't working at DICE?
*nappe1 selects Pinball_Fantasies.mod from winamp and turn volume to north...
EDIT: actually... I'd took a look of few things and now I don't suspect that you are working at DICE... but perhaps at UDS?
UDS HQ is located at Norrköping which is pretty close. Hyp-X said:
I actualy think they should use the fov of the persons view to the screen to calculate this instead of the game fov.
Now in games when youre looking at something in the midle of the screen and you turn to the right so its in the left it will stretch very unnatural.
The fov coordinates of the screen pixels should be different based on the persons fov and the game fov.
I dont know the math but im sure this is very easy.
So basicaly what youll get is a lot of curved lines but thats the way it should be when you zoom to keep correct geometry.
Also in 120 game fov the objects in the centre of the screen will probably be 2 times bigger if you calculate it like this...
Now almost the whole screen is used up by the stretched out geometry on the sides of the fov.
They could use a standard of 40degree eye to screen fov and maybe let the user change it in the options.
They could also let you select the aspect ratio of the screen and maybe the angle youre looking at it (i want my display to be perfectly straigth in front of me but ive seen a lot of people dont seem to care that much
well they probably wont bother changing those options either then i guess...)Needing different refresh rate for different resolutions, never expeienced that. But I agree that larger monitors need higher refresh. That's because the peripheral vision is more sensitive to flicker, and with larger monitors, part of the screen may go out in the peripheral vision.
Even I see 75Hz flicker if the monitor is in the corner of my eye.
And Sorry, no DICE or UDS connection here. I was however once upon a time in a game developper team that I think have a few games out now. But I was only with them in the very early days, and none of my code made it into any games. If I contributed anything, it was only some analysis, and general discussion about "this can be done", "that is difficult", "that can be solved with an algorithm like this". But the real coding for their first game started after I left them.
I'm not involved in any gaming or 3D graphics work now.
malcolm:
If you use the fov of the persons view of the screen, then you'd be dead in 5 seconds. (Unless you have a surround gaming setup.) If you want to fit a 120º fov on the monitor and keep the geometry correct, there's only one solution - press your nose onto the monitor.
I think you mean some kind of fish-eye effect, but that's not perspective correct in any way. But such things can be done in the vertex shader if all triangles is highly tesselated. Nvidia have a fish-eye-demo.
Me personally, I want this.
(Old text, but the idea should still work.)
Even I see 75Hz flicker if the monitor is in the corner of my eye.
And Sorry, no DICE or UDS connection here. I was however once upon a time in a game developper team that I think have a few games out now. But I was only with them in the very early days, and none of my code made it into any games. If I contributed anything, it was only some analysis, and general discussion about "this can be done", "that is difficult", "that can be solved with an algorithm like this". But the real coding for their first game started after I left them.
I'm not involved in any gaming or 3D graphics work now.
malcolm:
If you use the fov of the persons view of the screen, then you'd be dead in 5 seconds. (Unless you have a surround gaming setup.) If you want to fit a 120º fov on the monitor and keep the geometry correct, there's only one solution - press your nose onto the monitor.
I think you mean some kind of fish-eye effect, but that's not perspective correct in any way. But such things can be done in the vertex shader if all triangles is highly tesselated. Nvidia have a fish-eye-demo.
Me personally, I want this.
(Old text, but the idea should still work.)
Basic said:
well, I decided give a try...
both companies have done some marvelous games. DICE's Pinball Fantasies was fun until my dad scored over 690,000,000 points on in PC version Stones'n'Bones table. after that... well, you propably know the feeling when loosing to your old man.
UDS again, did the Ignition. It's still my most played game up to date. with split screen and Voodoo support, it was awesome fun. I don't recal when I started to writing stats to MS-Works spreadsheet on splitscreen matches, but 1000 "statted" races (or 200 campionatos. "campionaatto" is our own term for 5 fist Pro level championship races.) line was broken on march 2000. we are still playing it, whenever I meet my old friends.
and of course, it doesn't really matter what you are doing, as long as you are enjoying it.
Nothing is more evil than doing something just for the money.Basic said:
The fish-eye thing is probably what i mean.
And it is the only correct way to fit a 120 camera fov in a 40 view fov.
This is what i meant ofcource, you wouldnt want to use a 40 game fov.
You can not have 120 in 40 with the correct way you say.
Whats important is to get all objects on the screen to be the correct size in the persons field of view.
If you calculate something for a 120fov on the side of the screen it will be almost two times the size because it is meant to be looked at from almost two times the distance than you are.
