Printable View
Q1) I hear people say that some large commercial games use 2 different languages (usually C++ and Assembly). How exactly would you go about doing that (not that I want to try it, just curious)?
Q2) Why is it that my (rather crappy) computer can run full games smothered in textures and animation and run smoothly, yet when I make a program with OpenGL with a couple of textures floating around, it's super choppy? What do they do to make so smooth?
Thanks
For 1), typically you can use inline assembly with __asm or the like in compilers.
You can inline the assembly into C/C++ (how to do this depends on the compiler).
http://www.ibiblio.org/gferg/ldp/GCC...bly-HOWTO.html
And if you want to get the most out of your graphics hardware you have to know that to do, and especially what not to do. The guys that code commercial games are really good at what they do and also have the benefit of support from the hardware companies if they need it.
Post some of your code and perhaps people on the board can point out some obvious things to make it run faster.
/f
Modern compilers usually support inline assembler, so you can write small portions of code in assembler, and "mix it" into the C++ code directly. This is meaningfull when using for example SSE or 3DNow! (SIMD) instructions to speed up certain calculations.Quote:
Originally Posted by yaya
The first step, however, is to make the code work right, then profiling the application to find out where it is spending a lot of time in the code, and finally taking those bits of code and making them faster using various techniques, including translating portions of C++ code to more efficient assembler-code.
[/quote]
Q2) Why is it that my (rather crappy) computer can run full games smothered in textures and animation and run smoothly, yet when I make a program with OpenGL with a couple of textures floating around, it's super choppy? What do they do to make so smooth?
Thanks[/QUOTE]
I'm by far no expert on setting up OpenGL for speedy drawing.There's probably a lot of different things here - a list of some suggestions:
1. Maybe you are not double buffering?
2. Perhaps your drawing settings are not the most efficient?
3. Textures can be made in many different ways, and some are better than others...
--
Mats
using mipmaps can make a drastic improvement in blit speed, but then again it takes more memory.
Mipmaps actually have very little to do with speed and more with visual quality. They do take up more video memory but the effect of mipmaps on performance is next to nil.
The most important aspect of 3D programming is not what you draw but what you do not draw. A step further would be not what you don't draw but what you don't process. Fact is the less you do per frame the better performance you will get. This requires significant forethought into your design to accomodate both good graphics and good framerate. Personally I have yet to hit any major framerate issues in any of my code but that is because most of my stuff are little more than tech demos at the moment.
Big performance hits:
- Dynamic memory allocation during time critical loops or rendering loops
- Using O(n^2) algorithms and/or loops inside time critical code sections and/or rendering portions of the code.
- Sending too much vertex data over the bus to the card. The best way is to lock a portion of the buffer and render. This sounds odd but if you lock the entire buffer the video card cannot touch any portion of the buffer. So you have locked out the card while you process your vertices.
- Using brute force algorithms on extremely large data sets. Great speed gains can be made via simple well-known, well-documented spatial partioning algorithms.
- Creating vertices on the fly at run-time using brute force. This is very expensive and even moreso if you are computing normals on the fly.
- Trying to do too many operations inside of a pixel shader. These operations will be performed per pixel and may be better suited to a vertex shader.
- Poor post processing algorithms. Slow post process algos will eat framerates quickly.
- Poor LOD or no LOD system. Why waste tons of polies on items that are far from the camera?
- Attempting to render too many vertices per frame. This sort of sums up quite a bit of what I've already said.
- Using high res textures for every triangle in a scene. The more resolute the texture the more work the card has to do. Reserve high detail for those items that are close to the camera/viewer.
- Using a lot of Win32 and Win32 GDI calls. Win32 was never meant to be the fastest code on the planet and has little or no place in high performance graphics applications.
- Frequent locking of buffers and surfaces. The idea in modern graphics is you never want to explicitly touch the underlying texels/pixels unless it is done inside of a vertex or pixel shader.
If you find that your graphics code under OpenGL or Direct3D runs so slow that you must use inline assembly then your improperly using the API. OpenGL and Direct3D are plenty fast enough without using hand-tuned assembly code. Also be careful because your hand-tuned assembly code may actually be slower than the equivalent C++ to assembly compiler-generated code. Also just because you have that powerful beast of a video card and super powerful API does not mean that poorly written C++ code will execute lightning fast. The worst algorithm and the worst code can bring the best hardware to its knees.
Though mipmaps uses more memory, they use at most an extra 1/3 of the original texture's size, so it's not that bad (can be proven using geometric series).