NVidia Tnt2, and a slow 3d engine
Hi, I have TNT2 (Vanta, 32 mb, pci) video card, but my little 3dengine run not very quickly. When i render nothing on screen (no polygons, etc..) my engine run at 230 fps, but when i render only a poligon (with display lists or vertex arrays) it run at 180 fps. I have created a tool, that help me to level creation (level style doom.. labyrinth, halls, etc..) a big level can have 200 polygons (very little) but when i run in the level, the speed is about 70-80 fps... and I have not put any models yet!!
I have try to implement compiled vertex arrays extension, but there isn''t differences
What I can do ? Help me please
* Sorry for my incorrect english, i''m italian *
Thank You very much!!
I''m not sure, if I''m right...
When you are running a game in fullscreen mode, the maximum number of frames, which can be painted by your monitor in one second, depends on the frequency you''re using. If the frequency is 60hz for example, you''ll only get 60fps...
Hope that helped... Try loading models! 80fps is just right, if the frequency is 80hz!
When you are running a game in fullscreen mode, the maximum number of frames, which can be painted by your monitor in one second, depends on the frequency you''re using. If the frequency is 60hz for example, you''ll only get 60fps...
Hope that helped... Try loading models! 80fps is just right, if the frequency is 80hz!
Hi, thank you for your answer, but i haven''t set the refresh syncronization.. The engine run at, for example, 80 fps, but when i move the camera and render a zone of the space that haven''t polygon the fps go to about 230 fps.. then there isn''t monitor refresh syncronization.
Thank you anyway
Thank you anyway
u sure the HAL device is created ? if bbuf/zbuf surface has wrong format, it can happen that software render is used; then u get low perf.
Anon, this is an OpenGL forum, so chances are he is using OpenGL *gasp*!
D3D stuff doesnt apply to his problem seeing as he is likely using OpenGL.
D3D stuff doesnt apply to his problem seeing as he is likely using OpenGL.
the Anonymous Poster does make a bit of sence, even though he''s talking about DX, the same thing applys with OpenGL. (kinda)
Check to make sure that the PFD you are using is supported by your video card. If not, your FPS will drop drastically, I ran into the same problem a while ago.
If you look around msdn.microsoft.com for a program called GLEN (GL Enumerator), it will tell you what PFD''s are supported by your video card.
Hope this helps.
Check to make sure that the PFD you are using is supported by your video card. If not, your FPS will drop drastically, I ran into the same problem a while ago.
If you look around msdn.microsoft.com for a program called GLEN (GL Enumerator), it will tell you what PFD''s are supported by your video card.
Hope this helps.
Hmm.. I think you have to give us more info ON how you are texturing and displayin gthis polygon I have similar specs and have no problems.
Theres one thing though.. obviously your FPS will get sky high by renderig nothing, since is not doing anything! and of course it will go down if you do something!
Anyway heres a laundry list to try.
First of all.
Check your FPS counter, are you sure your fps counter is giving you the right number? I remembered expending a good afternoon fixing some code because the FPS counter told me it was doing 12. It turned out I was doing something stupid in the formula and it was actually doing around 120 douh!
Check the code.
What else is the code doing each frame? if you are initializing opengl each frame or something or if you are running a bucle on the back or reading data from disk constantly you probably should change that in the code.
Check the states.
State changes will throw your time to hell if done uncorrectly.
You should only change states 1 time at the beginning if you are only using 1 poly.
Check the States part 2.
What render states are enabled? alpha and some extensions like bump mapping will decrease your polycount quite a bit. specially if used incorrectly.
Check vertex arrays..
It doesnt apply in this case but ..remember Vertex arrays have storage limits (2000 vertices I think) if you go over that limit, Hardware T&L cards will start swapping and that will cause a stall.. this might make your program very slooow.
Check rendering..
How many times are you rendering your poly?
have you considered using a display list for tests?
Check your compile.
Debug is slightly less fast code than release, other optimizations may have been missed on compilation.
And of course.
What else is running in the background? and how much memory do you have to do this? running an mp3 player in the back is never a good idea for profiling.
Theres one thing though.. obviously your FPS will get sky high by renderig nothing, since is not doing anything! and of course it will go down if you do something!
Anyway heres a laundry list to try.
First of all.
Check your FPS counter, are you sure your fps counter is giving you the right number? I remembered expending a good afternoon fixing some code because the FPS counter told me it was doing 12. It turned out I was doing something stupid in the formula and it was actually doing around 120 douh!
Check the code.
What else is the code doing each frame? if you are initializing opengl each frame or something or if you are running a bucle on the back or reading data from disk constantly you probably should change that in the code.
Check the states.
State changes will throw your time to hell if done uncorrectly.
You should only change states 1 time at the beginning if you are only using 1 poly.
Check the States part 2.
What render states are enabled? alpha and some extensions like bump mapping will decrease your polycount quite a bit. specially if used incorrectly.
Check vertex arrays..
It doesnt apply in this case but ..remember Vertex arrays have storage limits (2000 vertices I think) if you go over that limit, Hardware T&L cards will start swapping and that will cause a stall.. this might make your program very slooow.
Check rendering..
How many times are you rendering your poly?
have you considered using a display list for tests?
Check your compile.
Debug is slightly less fast code than release, other optimizations may have been missed on compilation.
And of course.
What else is running in the background? and how much memory do you have to do this? running an mp3 player in the back is never a good idea for profiling.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement