Thread: 2 Questions of curiosity...

  1. #1
    Not stupid, just stupider yaya's Avatar
    Join Date
    May 2007
    Location
    Earthland
    Posts
    204

    Thumbs up 2 Questions of curiosity...

    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

  2. #2
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    For 1), typically you can use inline assembly with __asm or the like in compilers.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #3
    Registered User
    Join Date
    Apr 2006
    Posts
    43
    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

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by yaya View Post
    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)?
    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.

    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Nov 2005
    Posts
    673
    using mipmaps can make a drastic improvement in blit speed, but then again it takes more memory.

  6. #6
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    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.
    Last edited by VirtualAce; 04-22-2008 at 09:30 PM.

  7. #7
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145
    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).
    MagosX.com

    Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. questions....so many questions about random numbers....
    By face_master in forum C++ Programming
    Replies: 2
    Last Post: 07-30-2009, 08:47 AM
  2. A very long list of questions... maybe to long...
    By Ravens'sWrath in forum C Programming
    Replies: 16
    Last Post: 05-16-2007, 05:36 AM
  3. Several Questions, main one is about protected memory
    By Tron 9000 in forum C Programming
    Replies: 3
    Last Post: 06-02-2005, 07:42 AM
  4. Trivial questions - what to do?
    By Aerie in forum A Brief History of Cprogramming.com
    Replies: 23
    Last Post: 12-26-2004, 09:44 AM
  5. questions questions questions.....
    By mfc2themax in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 08-14-2001, 07:22 AM