OOP and Games
Hi. I am just wondering why Cg is not object oriented. As a developer who practices unified process and uses UML, I am just concern that these will just be thrown out of the window once I wet my feet in game programming.
What are the adverse effects of OOP on games?
Patience is just letting time pass by doing nothing.
June 15, 2002 04:49 PM
Object Oriented programming isn''t going to go anywhere for a long time. So there is nothing to be worried about on that end.
As for your question. Perhaps you don''t fully understand what Cg is, so I''ll get into it a bit. Cg is simply a C interface for the pixel/vertex shader interfaces on the latest video cards. So lets get into this. What are pixel and vertex shaders? Pixel and vertex shaders are implemented on the Geforce3, Geforce 4(not MX), ATI Radeon 8500, and some of the video cards comming out onto the market in the next few months. They allow programmers to basically create a little program that modifies data, but instead of running in software mode all the code for the pixel/vertex shaders is run on the video cards hardware (if you have hardware that supports it that is). The video hardware that these things are being preformed on is fairly slow for instance the speed of the Geforce 4 TI series of video cards is 300mhz, you want to make the code you execute on the processor fairly small and fast. Now Before Cg was around all pixel and vertex shaders had to be programmed in some type of assembly language for speeds sake. Now that the processor speeds on the video hardware are starting to speed up, it''s safe to create a higher level shader language to enable users to use the pixel/vertex shaders at the cost of some speed. And this is where Cg comes in. C is the next logical step in shaders it''s one step above Asm programming. Perhaps in another year or so as the video processors get faster and faster we''ll see a C++ implementation of Cg but as of now that would be 2 layers of abstraction on top of the asm code and it would most likely hurt the preformance of the shaders.
This problem does not occur in common games however. The fact that C is a tad faster than OOP C++ doesn''t become as much of an issue when your talking about computer processors that are in the 1 - 2 gigahertz range. It''s very common to see people OOP C++ or similar languages in order to provide re-usability to their code, and most often it''s seen when working in large projects where every one writes a little component for the end product. The trade off here is a slim ammount of speed vs the ability to re-use the code and work in a fairly large team. Of course you could always write your game in Object Oriented C (which can be done) but it''s often too much work for such a slim benefit.
As for your question. Perhaps you don''t fully understand what Cg is, so I''ll get into it a bit. Cg is simply a C interface for the pixel/vertex shader interfaces on the latest video cards. So lets get into this. What are pixel and vertex shaders? Pixel and vertex shaders are implemented on the Geforce3, Geforce 4(not MX), ATI Radeon 8500, and some of the video cards comming out onto the market in the next few months. They allow programmers to basically create a little program that modifies data, but instead of running in software mode all the code for the pixel/vertex shaders is run on the video cards hardware (if you have hardware that supports it that is). The video hardware that these things are being preformed on is fairly slow for instance the speed of the Geforce 4 TI series of video cards is 300mhz, you want to make the code you execute on the processor fairly small and fast. Now Before Cg was around all pixel and vertex shaders had to be programmed in some type of assembly language for speeds sake. Now that the processor speeds on the video hardware are starting to speed up, it''s safe to create a higher level shader language to enable users to use the pixel/vertex shaders at the cost of some speed. And this is where Cg comes in. C is the next logical step in shaders it''s one step above Asm programming. Perhaps in another year or so as the video processors get faster and faster we''ll see a C++ implementation of Cg but as of now that would be 2 layers of abstraction on top of the asm code and it would most likely hurt the preformance of the shaders.
This problem does not occur in common games however. The fact that C is a tad faster than OOP C++ doesn''t become as much of an issue when your talking about computer processors that are in the 1 - 2 gigahertz range. It''s very common to see people OOP C++ or similar languages in order to provide re-usability to their code, and most often it''s seen when working in large projects where every one writes a little component for the end product. The trade off here is a slim ammount of speed vs the ability to re-use the code and work in a fairly large team. Of course you could always write your game in Object Oriented C (which can be done) but it''s often too much work for such a slim benefit.
The reason for a move from assembly to a higher level language isn''t necessarily processor speed; it''s most frequently the development of an accurate optimizing compiler. If our current compilers weren''t optimizing their (asm) output better than most programmers can, we''d still be writing in assembly as a matter of necessity to squeeze performance out of our applications.
Same thing with Cg.
Same thing with Cg.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement