Efficient coding techniques

Discussion in 'Game Development (Technical)' started by techbear, Dec 31, 2005.

  1. Grey Alien

    Indie Author

    Joined:
    Nov 29, 2005
    Messages:
    2,797
    Likes Received:
    0
    nice thread, kinda reassuring to know I'm already doing the right things.

    I use text files for levels (and objects) and after making a few for testing the game, I then like to make an editor to speed things up and be more "visual".
     
  2. Gilzu

    Moderator Original Member

    Joined:
    Jul 27, 2004
    Messages:
    368
    Likes Received:
    8
    Take the "right" things with a pinch of salt. Polymorphism usually means more overhead = a bit slower code.

    everything has its cons and pros.
     
  3. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    "Slower code" doesn't really mean anything when you're talking about a match-3 game. You'd really have to be hammering the system with effects (or doing something intensely stupid in your code) to have performance problems in a puzzle game.

    Go for the cleaner code, I say.
     
  4. Pogacha

    Original Member

    Joined:
    Jan 21, 2005
    Messages:
    605
    Likes Received:
    0
    Polymorphism is always faster than a switch (Entity.Get_Type()) ... and more practical than a function pointer ...

    Edit: "everything has its cons and pros." I agree ... but in this case you win in all points
     
  5. Gilzu

    Moderator Original Member

    Joined:
    Jul 27, 2004
    Messages:
    368
    Likes Received:
    8
    Who said I was aiming toward a puzzle game? :D platform & action are more my type, where FPS counts.

    1. (if we're already on the subject) why not use the ANSI's typeid operator?
    2. I really doubt if its much faster than a switch statement. Function calling is always a drag (pun intended - you drag your stack). That's why they invented Inline.
    3. Since I already mentioned it, Inline functions is a nice efficient technique to speed things up.
     
  6. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    Inline is also a good way to bloat your memory footprint and cause cache misses. Code optimization is a great topic. :cool:
     
  7. HairyTroll

    Original Member

    Joined:
    Jul 29, 2004
    Messages:
    582
    Likes Received:
    0
    If the incorrect algorithm is used then all the profiling in the world is for naught. For example:

    - Using a bubble sort instead of quicksort, or
    - Traversing a linked list to find a object instead of using a hash table lookup, or
    - Redrawing the screen on each frame instead of only updating the dirty rectangles.

    The knowledge of and choice of algorithms is generally what separates a good programmer from a code-monkey.
     
    #47 HairyTroll, Jan 6, 2006
    Last edited: Jan 6, 2006
  8. HairyTroll

    Original Member

    Joined:
    Jul 29, 2004
    Messages:
    582
    Likes Received:
    0
    One more thing that helps when creating efficient code is the ability to generate code on the fly, ie. during program execution. This allows an algorithm to take advantage of specific runtime behaviour that is unknown at compile-time.
     
  9. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    Man, that sounds like debugging nirvana!
     
  10. princec

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    4,873
    Likes Received:
    0
    That's how Java works...

    Cas :)
     
  11. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    Is that why it's so slow?

    *ducks*

    I kid!
     
  12. Vorax

    Original Member

    Joined:
    Jan 21, 2005
    Messages:
    349
    Likes Received:
    0
    No, that's why Java is fast :) Cas is referring to the miraculous JIT capability of dynamic runtime profiling, pathing and code rewriting. It's the reason Java keeps getting faster and faster.

    But my guess is Hairytroll was not reffering to JIT runtime miracles...but rather to Lisp
     
  13. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    I know, I was just fooling around.

    I guess the point there is that Java is writing code on the fly, not the programmer behind the keyboard. HUGE difference there in terms of debugging.
     
  14. Grey Alien

    Indie Author

    Joined:
    Nov 29, 2005
    Messages:
    2,797
    Likes Received:
    0
    Actually originally my match-3 DID draw the whole screen each frame and although this was fine on most PCs it wasn't much good on old ones, so I changed it all to a dirty rects system and now it runs on 300MHz PCs.
     
  15. Fabio

    Original Member

    Joined:
    Sep 30, 2005
    Messages:
    499
    Likes Received:
    0
    What's wrong with that? My LoadFont() routine loads a bitmap and produces x86 machine code (to draw characters in a pre-compiled way).

    Text() then uses these "draw chars" run-time compiled pieces of code.

    Once I finished it (it didn't take long, also because I already had my x86 assembler class) I never needed to debug it, I also then reused and extended the code for compiled sprites (wait a moment, that's more or less cloning! ;) ).

    It's a piece of software I'm quite satisfied of, even proud, all but a "debugging nirvana". And I can't think of a better (more productive) example of "generate code on the fly".
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer