Gah! You''re right!
Cheers for the quck slap back into perspective zed.
Add ''premature software engineering'' to ''premature optimisation'' - my quadtree is inherited from and fully integrated with a general scenegraph - looks great and was fun to design/code, but really pretty pointless at the moment ;¬)
Best to get something working, then improve on that.
Still, any ideas on improving framerate when fillrate is the bottleneck? I know in general I should avoid drawing very large or small tris, but I don''t really know how to work out what is likely to slow stuff down in this stage. I''m assuming anything that makes the texture lookup / transformation take longer... but what is that?
I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrain (1 pass, 2 texture units, 1024x768, 32bpp) seems really crappy and I''m wondering if I''m doing anything seriously wrong. I just want to make sure I''m heading in the right direction as it were ;¬)
Thanks again,
Dan
Concatenating strips - can I fool gl*Pointer by overloading operator[] ?
I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrain>>Still, any ideas on improving framerate when fillrate is I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrainthe bottleneck?<<
use mipmaps
smaller textures
use texture compression
use lower internal texture formats
turn of zwrites
etc
>> I know in general I should avoid drawing very large or small tris<< <- i dont know this is supposed to help
>>I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrain<<
is pretty bad for gf2mx is this with all the triangles visable?
using plain old vertex arrays u should easily get 60fps for 256x256 tris at that resolution.
r u changing states very often eg binding different textures?
http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html
use mipmaps
smaller textures
use texture compression
use lower internal texture formats
turn of zwrites
etc
>> I know in general I should avoid drawing very large or small tris<< <- i dont know this is supposed to help
>>I know, I shouldn''t be worrying about this stuff yet, but < 12 fps for 256*256 terrain<<
is pretty bad for gf2mx is this with all the triangles visable?
using plain old vertex arrays u should easily get 60fps for 256x256 tris at that resolution.
r u changing states very often eg binding different textures?
http://uk.geocities.com/sloppyturds/kea/kea.html
http://uk.geocities.com/sloppyturds/gotterdammerung.html
Thanks zedzeek, I sorted my state changes out and doubled the fps ;¬)
Yeah, the <12fps was drawing all (or most of) the triangles. But it''s not 256x256 tris, it''s 256x256 verts the way i''m doing it = 255x255x2 = 130050 triangles. Does this sound reasonable?
I''ll try sorting the textures next and see how it goes.
Cheers mate.
Yeah, the <12fps was drawing all (or most of) the triangles. But it''s not 256x256 tris, it''s 256x256 verts the way i''m doing it = 255x255x2 = 130050 triangles. Does this sound reasonable?
I''ll try sorting the textures next and see how it goes.
Cheers mate.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement