quote:Original post by Palidine also, nehe''s tuts don''t disable vsync, so if you''re maxed out at 60FPS or 30FPS or whatever the refresh rate of your monitor is, that''s why.
with disabling vsync i get around several hundred FPS on most of his basic tuts
-me
why would you need these extra frames if your monitor wont display them? if you disable vsync your game wouldn''t run on some machines. for example: Kyro chipsets needs vsync to work properly. otherwise the user will get his monitor turned off because of signal errors...
quote:Original post by daher why would you need these extra frames if your monitor wont display them? if you disable vsync your game wouldn''t run on some machines. for example: Kyro chipsets needs vsync to work properly. otherwise the user will get his monitor turned off because of signal errors...
clearly. but you disable vsync when you are developing so that you can see how fast your engine actually is. you don''t leave it disabled in the release build except in a "test my FPS" type of build in function.
Original post by daher why would you need these extra frames if your monitor wont display them? if you disable vsync your game wouldn''t run on some machines. for example: Kyro chipsets needs vsync to work properly. otherwise the user will get his monitor turned off because of signal errors…
clearly. but you disable vsync when you are developing so that you can see how fast your engine actually is. you don''t leave it disabled in the release build except in a "test my FPS" type of build in function.
-me
sorry for this but you actually gave this solution to cppdude who was talking about having a decent framerate on quake3 and btw quake3 doesn''t disable the vsync. so the guy thought that if he disabled vsync, he would get a decent framerate for nehe''s tuts. this just doesn''t seem the right solution
ummm, vsycn being off is quite important since you cen get more out of the video card.
lets say you moniter is refreshing at 100hz. thats 100 frame per second (ie 10ms per frame). yet the game needs 11ms per frame (ie 90 frames per second if vsync is off). so the game runs at 50 frames per second instead of 90. now i ask you, which would rather run at?
explaination why:
|----------|----------|----------|----------|----------| vsync |-----------__________|-----------__________|----------- game
- for the game means actual rendering time _ means wasted time waiting for the vsync to actual draw the image
sure triple buffering can help allieviate this, but now you have less vram to work with, and triple buffering helps only to a point.
anyhoo, any card that required vsync to be on has something quite wrong with it. vsync only means that you wait till the moniter refreshes before transferring data to the primary surface. without waiting for vysnc you would transfer as soon as you had the data rendered. thus if the card did not support vsync being off, it REQUIRES a back buffer. after some research however i found you to be silly and not know what you speak of.
shows benchmarks of the card with vysnc turned off. thus the card may keep it on internal, it definatly would not drop the singal to the moniter because someone did the most normal thing of not waiting for vysnc.
furthermore, needing to wait for vsync is just silly for ANY hardware to work properly. its just a matter of deciding when you transfer the data to the primary surface. also, old ati rage and voodoos were able to handle transfers without waiting for vsync. heck, old isa video cards could transfer without waiting for vsync.
when we say trun off vsync, we mean not wait for vsync when transfering (or flipping) the back buffer to the front buffer or simply drawing directly to the front buffer.
quake3 by defualt does not wait for vsync 9well at least not my copy).
please by all means post and show me a place that says the kyro can only transfer to the primary buffer on vsync. because if thats true, then you cant use it in dos, since most dos apps did not bother waiting for vsync. cant use it with many windows apps either, since many of them dont wait for vsync either.
simply put, transfering data to the primary buffer is a fundamental part of a video card. furthermore the only artifacts you get from not waiting for vsync is things like tearing which are cosmetic.
quote: please by all means post and show me a place that says the kyro can only transfer to the primary buffer on vsync. because if thats true, then you cant use it in dos, since most dos apps did not bother waiting for vsync. cant use it with many windows apps either, since many of them dont wait for vsync either.
It happends here with me on a 19" flatron monitor when ( ie: playing on 800x600x16 fullscreen ) non of the nehe's tuts works. i keep getting the (signal out of range) text on the monitor... i don't got the time to search for it on harware forums... but i have read it somewhere too. i'll check n tell ya back...
EDIT: The problem is not with the Video card, its that some monitors doesn't expect any signals between video periods. and yes dos games cannot be played here...
thats the thing, a properly working card dont send any extra data to the moniter. it merely allows you to update the actual vram, while a refresh occers. the signal out of range may simply mean that you set the vsync rate to a bad value. try lowering it to 60hz (supported by all modern moniters (ie 13in and up) at 800x600. if you have to search hardware forums, then its not truly vsync not being waited for as the problem since the box/site/manual would have to state this limitation. normal video cards dont have such a silly and obviously terrible flaw.
i would bring the card back and say its broken if it truly cant handle an app that dont wait for vsync.
if its the moniter, then i would bring that back as well. my old c64 did from the 80s has no problem with writing to vram during vsync, the moniter did not care either. my old magnavox 386 (with some isa card) connected to a magnavox 13in moniter did not show this either. i seriously never heard of this. in fact your moniter even displaying the message instead of showing a garbled screen means that the moniter is MUCH more advanced then the ones i used back in the day with no problem.
i know ChangeDisplaySettings() with bad parms on some cards causes the refresh rate to change. this may be yoru problem and why your getting out of range singal errors. you dont change turn sync to refresh (or called turning off vsync since its less words). you instead deal with WGL_Ext_Swap_interval (may have typed that wrong though its similar to that).
though i think you just need updated drivers since you may be running software opengl. make sure that you correctly have an opengl ICD installed (ie the drivers should install it). or copy the opengl32.dll from the quake3 directory to your apps directory. make sure that you are getting an accelerated device as well. furthermore the opengl app needs to use the same color depth as the desktop otherwise it may not be accelerated. also the kyro may not supported windowed acceleration. you shoudl also not be messing with refreshrate or vsyncrate values in anything. the way to turn off vsync is to use the SwapInterval extension.
quake2 sync to vsync is off by default. how do i know? well deleting my config.cfg and running the game (which starts in software mode). i switched to default openGL. amazingly enough "sync frame to refresh" was "no" by default.
the code you posted dont show the default value at all. it merely shows that when its modified it does stuff and the ismodified should be false after if its checked and true. ie shows nothing.
hmmn... I think i was mixed up with a lot of things... New drivers fixed the problem ( although it seems a lot weird to me )... and q2 value as "no" just exploded my mind...
Thanks to a person for correcting some stupid ideas in my mind... i should fell a sleep before i can code anymore...
a lot confused... sorry for these mistakes! and hey a person i''ll catch ya sometime with yours
your welcome. and thank you for actually going over what i wrote instead of just assuming you were correct. we all have bad days and get confused on some topics, its nice to know that there are ppl on gamedev can help straighten things out (i have been corrected a few times myself because of some confusion i had or late night posting).
dont be sorry, just be glad you learned from them. if you did not learn from them, then its time to be sorry, heh.
