Archived

This topic is now archived and is closed to further replies.

cppdude

Why are NeHe's tuts so slow?

Recommended Posts

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

Share this post


Link to post
Share on other sites
if you''re using openGL, and your card supports the extension, you can do it with this code using openGL extensions. if you don''t know what openGL extensions are or how to use it look it up


PFNWGLSWAPINTERVALEXTPROC pFunc = NULL;
if ((pFunc = (PFNWGLSWAPINTERVALEXTPROC) wglGetProcAddress("wglSwapIntervalEXT")) != NULL)
pFunc(0);


if you''re not or your card doesn''t you can sometimes do it from your windows desktop properties dialog box. it all depends on your video card driver. all newer cards allow you to disable vsync google it on the web.

-me

Share this post


Link to post
Share on other sites
if your using an older voodoo card, that''ll be why. They don''t support GL directly, (especially in a window). This was the reason for 3dfx ''quake 3 compatible'' drivers that popped up when the game came out.

Share this post


Link to post
Share on other sites
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...

Nevermind...

Share this post


Link to post
Share on other sites
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.

-me

Share this post


Link to post
Share on other sites
quote:
Original post by Palidine
[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.

-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

Nevermind...

Share this post


Link to post
Share on other sites
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.

http://216.239.51.100/search?q=cache:FmFNqXOPlQwC:www.benchmark.pl/ranking.php%3Fa%3Dl%26id_games%3D11+kyro+vsync&hl=en&ie=UTF-8

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.

Share this post


Link to post
Share on other sites
quote:
Original post by a person

quake3 by defualt does not wait for vsync 9well at least not my copy).


its actally the defaule opengl state even on quake2
here is the source frome q2source file r_misc.c line 176:

    
/*
** GL_SetDefaultState
*/

void GL_SetDefaultState( void )
{
.....

GL_UpdateSwapInterval();
}

void GL_UpdateSwapInterval( void )
{
if ( gl_swapinterval->modified )
{
gl_swapinterval->modified = false;

if ( !gl_state.stereo_enabled )
{
#ifdef _WIN32
if ( qwglSwapIntervalEXT )
qwglSwapIntervalEXT( gl_swapinterval->value );
#endif
}
}
}

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...

Nevermind...




[edited by - daher on July 20, 2002 3:28:04 PM]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Nevermind...

Share this post


Link to post
Share on other sites
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.

good luck with your opengl coding.

Share this post


Link to post
Share on other sites