limited API usage..
Ok, I've been doin some programming im openGL.. its very nice and all but I feel like all the work has already been done for me. The only thing I really need is a way to take advantage of 3D hardware etc.. when calculating a frame. I know how to project a polygon onto the screen, what I want the API to do is to let me take advantage high speed hardware and not trying to be smarter than me (allthough it probably is hehe). Any thoughts about this anyone ?
Edited by - Jesper T on October 20, 2001 9:12:18 AM
no way... you''d have to ask every vendor for their card specific interface.... sorry..
cya,
Phil
Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states
cya,
Phil
Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states
no way... you''d have to ask every vendor for their card specific interface.... sorry..
cya,
Phil
P.s.: Write a software engine :o))
Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states
cya,
Phil
P.s.: Write a software engine :o))
Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states
Almost the whole OpenGL pipeline, from transformation, projection to rendering is done in hardware nowadays. Everything you would do ''per hand'' would be a waste of CPU performance. See OpenGL as your interface to the hardware. Don''t worry, there''s enough other things to do if you try to write a 3D engine, what is not done by OGL, eg. good HSR, physics, good lighting, etc...
Damn, I''m really happy the days of software engines are gone, now I have to time to concentrate on the really important things of my engine, and not about the render core itself.
- AH
Damn, I''m really happy the days of software engines are gone, now I have to time to concentrate on the really important things of my engine, and not about the render core itself.
- AH
> hmm well I like to do the other parts too, but not at the cost of speed though.
I know, it''s rather interesting to code a software renderer, it''s a great project if you want to learn about the internal functions of a polygon render device.
But nowadays, you should stick with the OpenGL API. Even parts that are not hardware yet, and you might perhaps be able to code something more efficient that does the same thing, be careful. 3D technology is expanding at an incredible rate, tomorrow your function (that took you weeks to optimize) might already be implemented in hardware. If you use OGL the way it''s meant to be, then your project will automatically take advantage of this new hardware feature. That''s the nice thing with OGL.
As I said, look at HSR and physics if you want a real challenge, current games are very poor at that.
- AH
I know, it''s rather interesting to code a software renderer, it''s a great project if you want to learn about the internal functions of a polygon render device.
But nowadays, you should stick with the OpenGL API. Even parts that are not hardware yet, and you might perhaps be able to code something more efficient that does the same thing, be careful. 3D technology is expanding at an incredible rate, tomorrow your function (that took you weeks to optimize) might already be implemented in hardware. If you use OGL the way it''s meant to be, then your project will automatically take advantage of this new hardware feature. That''s the nice thing with OGL.
As I said, look at HSR and physics if you want a real challenge, current games are very poor at that.
- AH
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement