I''ve been playing around with the examples given but have noticed that they run slow on my PC. The examples in particular are lessons 11 and 12. Basicly I''m trying to create a 3d engine (or at least something I can use to create a demo with) for a project, but it has to be able to run on at least a celeron 400 with a graphics card which has 32mb. So far the complex examples don''t run too well. Can anyone suggest something I can do (should I continue to try OepnGL or should I try DirectX)?

youre prolly doing someit strange to get software rendering my setups about the same though with a vanta card and i do about 250000 decent tris a second.
performance comes with time what ever speed your engine starts off with i guarantee in 6 months it''ll be 2-3x quicker

http://members.xoom.com/myBollux

Not sure what I could be doing wrong. The lessons run quiet slow (whether I run the pre compiled code or compile it my self using VC++).
the test system being used is win98 on a celeron 400, TNT2 with latest drivers as well.
Is there something I''m missing or should download?

r u sure they''re slow? with that system 80000-100000tris a sec means you''re doing it in hardware which is good enuf to start with. + there r 101 ways to increase your rendering performance from that but its a slow process mate theres no magic solution


http://members.xoom.com/myBollux

Are you sure you have the latest drivers? I have a TNT 2 Vanta too and a month ago when I started with OpenGL I noticed it was really slow. Then I tried running GLSetup and suddenly everything OpenGL related was 30 times as fast as it was before!

Maybe it works for you too. If you want to try:
www.glsetup.com

I have this same problem. Game programmers these days believe that everyone has some marvellous hi-tech video card. Im not even going to mention what i have (bloody horrific), but after fiddling around with what my setup can cope with, i can get noticable results on even a pentium 75.

If you dont have a flashy brand-name video card, start re-arranging the tutorials to get the best results on your computer. At least you have a 32mb video card. :/

- Wav

Thanks for the posts, thought I was going to get flamed or newbie bashed. I''m going to download GLsetup and see if it helps.

As for lessons running slow, 11 and 12 are very choppy (the flag runs almost like a slideshow). I know it takes time to get things to run fast, I was just wondering whether I had compiled them wrong or that maybe I needed a beefy machine, or maybe that I just had wrong drivers or something.

The project I''m working on is hopefully going to be my final project at uni (as long as I can learn either OepnGL or another API). I was going to aim for a very min system (voodoo 2 at the most), but was told I could aim for something high end (high end in the eyes of my advisor). Thats the reason why I''ve been asking about the speed.

Thanks for your help *8)

GLsetup didn''t help at all, lesson 11 still looks like a slide show *8(

I don''t think that GLSetup would do anything for a TNT2 because TNT2 is -fully- OpenGL compliant. As far as I am aware, GLSetup is for games primarily, and is for using 3D accelerated features of cards which are not fully OpenGL compliant. Anything from the TNT2 by NVIDIA will be essential for OpenGL developers, as NVIDIA are now leading how OpenGL is being developed (The stencil buffer was invented by NVIDIA, and I have noticed that it doesn''t work on my Voodoo3 as it is not supported).

It is true that new programmers these days ask more experienced programmers for their secret to generating faster code... The only secret is practise. One thing I would advise learning is Assembly - a solid understanding of Assembly and computer science will allow you to make optimisations. I mean, for example, a well practised and well known optimisation technique for a program which uses sin and cos a lot: Use lookup tables where the result of sin(n) is stored in an array. Lookup tables are used even in the latest games for many things such as lightmapping.

Hardcore optimised Assembly is only really used today in game engines where there are areas of code which are crucial to game performance, such as matrix calculations.

There is no single optimisation which will make your program magically run faster, however, it is your job as the programmer to balance your engine - identify the bottlenecks in your code - find ways to make it faster to balance it out.

About your question regarding using DirectX... Don''t bother... Direct3D immediate mode has the worst design ever... I only use DirectX now for the DirectInput components mainly. Admittedly D3DIM is good in the respect that if your card doesn''t support a certain feature, D3DIM has several software renderers which can perform the job. However, in terms of ease of use OpenGL is the one I recommend. It''s easy to use with all the power you could ever possibly need.

And the reason those demo''s are slow on your computer. Lesson 11) I think that''s because the effect is quite processor intensive, and as your processor is quite slow, it''s slowing down the program. Your card is easily capable of rendering the scene at an acceptable framerate, but the example app isn''t even optimised. Just glancing through the code it''s apparent that several optimisations could be made to significantly increase the speed.

12) That program again runs seemingly slowly on my computer, but I think that it''s down to how the input is received. If DirectInput was used to obtain input from the keyboard (Rather than relying on Windows to send you the info you require) and the rotation amount was increased - I think the program would seem much faster. (The rendering pipeline is quite small as most things are pre-computed, so it''s not that)

I don''t think that GLSetup would do anything for a TNT2 because TNT2 is -fully- OpenGL compliant. As far as I am aware, GLSetup is for games primarily, and is for using 3D accelerated features of cards which are not fully OpenGL compliant. Anything from the TNT2 by NVIDIA will be essential for OpenGL developers, as NVIDIA are now leading how OpenGL is being developed (The stencil buffer was invented by NVIDIA, and I have noticed that it doesn''t work on my Voodoo3 as it is not supported).

It is true that new programmers these days ask more experienced programmers for their secret to generating faster code... The only secret is practise. One thing I would advise learning is Assembly - a solid understanding of Assembly and computer science will allow you to make optimisations. I mean, for example, a well practised and well known optimisation technique for a program which uses sin and cos a lot: Use lookup tables where the result of sin(n) is stored in an array. Lookup tables are used even in the latest games for many things such as lightmapping.

Hardcore optimised Assembly is only really used today in game engines where there are areas of code which are crucial to game performance, such as matrix calculations.

There is no single optimisation which will make your program magically run faster, however, it is your job as the programmer to balance your engine - identify the bottlenecks in your code - find ways to make it faster to balance it out.

About your question regarding using DirectX... Don''t bother... Direct3D immediate mode has the worst design ever... I only use DirectX now for the DirectInput components mainly. Admittedly D3DIM is good in the respect that if your card doesn''t support a certain feature, D3DIM has several software renderers which can perform the job. However, in terms of ease of use OpenGL is the one I recommend. It''s easy to use with all the power you could ever possibly need.

And the reason those demo''s are slow on your computer. Lesson 11) I think that''s because the effect is quite processor intensive, and as your processor is quite slow, it''s slowing down the program. Your card is easily capable of rendering the scene at an acceptable framerate, but the example app isn''t even optimised. Just glancing through the code it''s apparent that several optimisations could be made to significantly increase the speed.

12) That program again runs seemingly slowly on my computer, but I think that it''s down to how the input is received. If DirectInput was used to obtain input from the keyboard (Rather than relying on Windows to send you the info you require) and the rotation amount was increased - I think the program would seem much faster. (The rendering pipeline is quite small as most things are pre-computed, so it''s not that)