Efficient coding techniques

[techbear]

For 2006, I resolve to re-think my code structure, based on a simple motto: "What's easiest for me?"

For instance, I've made lists and added space ships to them for YEARS now, but I've often settled for clumsy solutions that weren't well thought out. Now, I'm working with objects that automatically add and remove themselves from their proper lists, so I don't have to fool with it.

I've also become enamoured of the Immediate Mode GUI idea, which PROMISES to fulfill my requirements of "What's easiest for me?" by being simpler to code than traditional OOP GUIs.

So let's start a thread about techniques and tools that make it easier and simpler to make games. What piece of code saves you so much time, you can't wait to use it? What tool lets you replace a week's coding with an hour's pointing and clicking?

Thanks!

[mahlzeit]

Not necessarily a coding trick, but I always try to use plain ASCII files for level design. Certainly beats writing a dedicated level editor when you can simply use a text editor.

As far as coding is concerned, I use plain C as much as possible. When an array of structs suffices, I use that. No use in getting all object-oriented just for the sake of being object-oriented.

And don't write code that you don't need right now.

[Raptisoft]

Here's a little one I've been using for the last couple years-- I picked it up from Paul Nettle.

Suppose you have a class, right? And that class has a value called "Result." So, we have this:


class YoMomma
{
int theResult;
};


Now, normally, all over your code, you have YoMomma.theResult this and YoMomma.theResult that. Like


if (SnoopDog==YoMomma.theResult) GetJiggy();


Paul Nettle recommended that I always do it like this:


class YoMomma
{
int theResult;
inline int GetResult() {return theResult;}
};

if (SnoopDog==YoMomma.GetResult()) GetJiggy();


Okay, I admit, at first I scoffed... it seemed like more work for little or no gain. Then one day, I had been hard at work, and I realized that I wanted to always modulate one of my result variables when I read it. Like, I always want theResult to be multiplied by, say ScoreMultiplier.

Now I had the fun task of going through my whole program and making YoMomma.theResult into YoMomma.theResult*theScoreMultiplier.

But with that inline, it would have just been a matter of changing the inline statement.

So since that day, I always make all my classes return their information in that manner, just in case I want to change something at some point.

So I recommend doing this. Plus, the extra time it takes you to type inline will give me an advantage, since I can get out Chuzzle 2 before you finish Gem Shop 6.

[undersan]

Many of you probably have "approximate" float comparison functions like these. I think I got these versions from a Flipcode Code of the Day.

const float fFloatEpsilon = 0.000005f;

inline bool FloatApproxEQ( const float& fA, const float& fB ) {
return (fabsf( fA - fB ) <= (fFloatEpsilon * (fabsf( fA ) + 1)));
}

inline bool FloatApproxGE( const float& fA, const float& fB ) {
return fA > fB - fFloatEpsilon * (fabsf( fA ) + 1);
}

inline bool FloatApproxLE( const float& fA, const float& fB ) {
return fA < fB + fFloatEpsilon * (fabsf( fA ) + 1);
}


However, I never liked replacing...

if( fA == fB ||
fC >= fD )
{ ...

with

if( FloatApproxEQ( fA, fB ) ||
FloatApproxGE( fC, fD ) )
{ ...

because the latter version is just not readable. You have to think for a second to realize what comparisons are actually being used. So, I came up with some wacky C++ and preprocessor trickery to improve the readability:

if( FLOAT_APPROX( fA == fB ) ||
FLOAT_APPROX( fC >= fD ) )
{ ...

The FLOAT_APPROX macro is defined in the attached header. The macro still uses FloatApproxEQ, etc. to do the actual comparisons.

[Jesse Aldridge]

I like to first code whatever I want to do at a high level , and then afterwords figure out how to do it on a lower level.

For example:
Player::process()
{
handleArrowKeys();

if( getHealth() < getMaxHealth() * .25 )
startWarningNoise();

if( mouse.leftReleased() )
fireGun();

if( mouse.rightReleased() && canActivateSpecial() )
activateSpecial();
}Then, later, I'd figure out how to implement all of those functions. I find this really helps me make code reusable. It works because you initially code in whatever manner is most intuitive for you.


Not to sure about making point-and-click tools. I have a feeling it would take too long to make one that worked well. Thus far I've just striven for easy to use code. I was playing around with GameMaker (which has a point-and-click interface and a more advanced coding interface) for a while and found that after a certain point, it's easier to simply do everything in code. Still, if a point-and-click interface (or whatever) could (somehow) be made sufficiently powerful... well, that would be cool.

[Robert Cummings]

The only tips I'd like to share are:

- do not optimise

- expand where possible

- keep a rigid naming convention, for example images will be prefixed with i and sounds with s and so on: iExplosion, sScream, and so on...

Use classes for what they are best at: keeping data and code together.

[Olofson]

Enable all sensible warnings your compiler can generate, and deal with any warnings your code generates. (With GNU gcc, I use "-Wall -Werror" and a bunch of extra warning switches.) Note that some warnings depend on data flow analysis and other stuff that is not done unless you enable optimization.

Always aim to write code in a way that will have it fail in a "clean" way and as soon as possible if you make some mistake. Preferably, it shouldn't even compile if it's not totally correct, but unfortunately, that's impossible with most languages... Trying helps a great deal, though, especially with "unsafe" languages like C and C++.

Have functions check arguments and data, so they don't try to process just any garbage you throw at them! Serious error handling can save a lot of time.

If you have different types of machines and operating systems, try to test code, or your entire game, on as many of them as possible! Often, the differences between environments will reveal "sleeping" bugs quickly.

Serious memory debuggers, such as BoundsChecker (commercial, Win32 only AFAIK) and Valgrind (Linux x86 and AMD64, with OS X and *BSD in early stages) can be incredibly helpful. Valgrind is actually my main debugging tool nowadays!

[Huge]

1. Move all your "good" code out into common library/include directories. Even (especially !) if it's just a little 10 line jobby like "GetCurrentDate". Other things, like high-score structs, image loading etc. should be moved out too. Have a single include directory rather than trying to pull code in from other projects like "#include <../../old_crappy_game/something.h>". Put your good code into a ".lib" rather than a bunch of ".obj/.cpp" files pulled from other project directories. This is how you get code reuse - not by refactoring everything into objects, but by simply organising yourself in such a way that it is easier to reuse code than to cut and paste it (because we all know we are lazy).

2. Maximise your "good" code. Try to decouple your working routines from your particular project. That said, don't over design. Do it the easiest way first and then move it out once it's working well.

3. Use revision control (eg, svn, cvs). Even for a one-man-band, it's great. eg, "When did I change that over - oh I see, it was when I moved to the STL", and "oops - I wish I could undo that change - oh look, I can". Also forms a good backup if you put the repository on a separate machine.

[Bmc]

I like to first code whatever I want to do at a high level , and then afterwords figure out how to do it on a lower level.

For example:
Player::process()
{
handleArrowKeys();

if( getHealth() < getMaxHealth() * .25 )
startWarningNoise();

if( mouse.leftReleased() )
fireGun();

if( mouse.rightReleased() && canActivateSpecial() )
activateSpecial();
}Then, later, I'd figure out how to implement all of those functions. I find this really helps me make code reusable. It works because you initially code in whatever manner is most intuitive for you.



that's actually an excellent practice. I believe it's part of the Agile Software methodology.... put doing things off as long as you can.

[Robert Cummings]

Another tip: never keep a bugs list. Deal with bugs IMMEDIATELY there and then, never ever put them off.

They can and will slip by you. If any undesired behaviour or bugs occur, you must deal with them immediately on the spot: drop everything and focus on them.

[HairyTroll]

Keep everything in version control. I've been using Darcs (http://darcs.net/DarcsWiki) as it is much easier to use than CVS or Subversion.

[princec]

Switch to a platform that does most of the work for you (http://java.sun.com) :) No more wasting time tracking down bugs that can't happen any more!

Use an IDE that does the rest of the work (http://www.eclipse.org) for you - eg. makes CVS/SVN, refactoring, compilation, debugging, TODO lists, etc. all simple

Really learn OOP. Not just hiding members behind getters and setters. In fact that's not even really OOP.

Comment all your code properly. Very handy when you come back to it in a year's time.

Design for re-use.

The last two points can often be helped along by making your code public! The embarrassment of poorly commented shitty hacked pseudo-OOP code is often enough to help you clean things up at least a bit.

Cas :)

[HairyTroll]

Switch to a platform that does most of the work for you (http://java.sun.com) :) No more wasting time tracking down bugs that can't happen any more!

But, as Joel Spolsky says (http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html), don't start out learning programming using Java or you may as well put a paper bag over your head. ;)

[Mark Fassett]

* Whenever you write code to allocate dynamic resources, immediately write the code to release those resources.

* Avoid destroying dynamic resources in multiple places.

[Raptisoft]

Oh, and here's a few more tips I've found advantageous over the years. These aren't all coding tips, but I put them out there entirely for free for budding indies.

1. It's not necessary to delete objects any more. Computers have so much RAM these days that it would literally take hundreds of years to fill up the memory.

2. Not every bug is worth fixing! There's a certain threshold over which a user's intelligence should carry them. For instance, if you have a 6x6 grid onscreen, it's okay to allow a GPF if the user clicks outside the grid, because nobody is going to click outside the grid anyway.

3. "Polishing" is just a word that successful, sabotaging indies use to discourage the small guys and cloners, and keep them in longer dev cycles. Don't listen to these guys-- remember, Bejewelled is just simple geometric shapes, and it's the best selling game of pretty much all time!

4. RPGs and MMORPGs are gonna be the biggies in 2006. Working on anything else is a waste of time, it's all been done.

5. Options and settings screens take up too much development time, you'll lose your competitive edge. A smarter thing to do is just include all settings in an easy to edit text file. Everyone has notepad these days!

6. Don't worry about framerate drops on older machines. Anyone worth considering has a 2.14ghz machine with at least a radeon. Anyone without that isn't worth targetting-- they have no money.

7. Cloning a game is a good way to get some money coming in with little effort. In fact, to reduce the time and effort further, just use ascii art in console mode. Alternatively, just take an existing game and replace the image graphics, and put it out as your game. Work smarter, not harder!

8. Potential customers won't take you seriously unless your price is on par with games they can get in the store. Charging anywhere from $49.99 to $60.00 for an indie game is normal these days.

9. When possible, use a coding system like Java or C# to get your game done quickly. It's better to have three people who can play a game that's done in two months than a million people who can play a game that's done in six months. Just ask Svero.



Okay, hope this helps!

[oNyx]

But, as Joel Spolsky says (http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html), don't start out learning programming using Java or you may as well put a paper bag over your head. ;)
The article is pretty bad n pointless. Oh and he says that java isnt hard enough... and... well, just remember what this thread is about.

He also seems to believe that there is no recursion in java. Oh please. And whats great about recursion anyways? Its the easy (less efficient) way to do things.

Not necessarily a coding trick, but I always try to use plain ASCII files for level design. Certainly beats writing a dedicated level editor when you can simply use a text editor.[...]

I disagree completely. With some integrated editor your turnover rate is way higher. Writing an editor always pays off. Even with tiny games you can easily save several days.

I also believe that it ultimately results in a better game, because there will be more iterations per level. It allows you to experiment a bit and the leveldesign is more tested, because you'll often check how small changes turned out. The whole level design stage becomes more interesting or even exciting with a good editor.

Writing a simple editor takes only a few hours or maybe a week if its somewhat complex. I heard that you're 2-5 times more productive with Java compared to C++. So, maybe thats the reason?

[Rod Hyde]

My favourite coding toolkit, which I've rediscovered recently, consists of:

a pencil with an eraser
a pencil sharpener
a hardback A4-sized notebook

Writing down questions and challenging my design before I've committed it to code saves me weeks of coding time.

Oh, and a open window for throwing out dogma.

--- Rod

[Vorax]

9. When possible, use a coding system like Java or C# to get your game done quickly. It's better to have three people who can play a game that's done in two months than a million people who can play a game that's done in six months. Just ask Svero.


I know your trying to be sarcastic, but there's nothing wrong with using Java. Something written in Java can run just as well on just as many computers as anything written in C++.

PS: Hamsterball crashes on my kids P3 500, but Ultratron runs nicely on it ;)

[Karukef]

Switch to a platform that does most of the work for you (http://java.sun.com) :) No more wasting time tracking down bugs that can't happen any more!


Or use a platform that REALLY does most of the work for you (http://www.python.org), a platform so simple and efficient that you dont NEED hundreds of megabytes IDE to use it. ;)

(or ruby, if you have already sworn to never use python and need a backdoor escape away from C-family hell)

[soniCron]

Or use a platform that REALLY does most of the work for you (http://www.python.org)... ;) Or, use a platform that really, REALLY does most of the work for you (http://www.macromedia.com/flash/)! ;) *waits for someone to mention GameMaker*

[Octopod]

Rather than using plain ASCII for level building, use Photoshop to paint your level. Multiple layers for collision map, bonus map, actor map, etc.. Easy to export, easy to import, easy to edit.

Alexis.

[bodgey]

Rather than using plain ASCII for level building, use Photoshop to paint your level. Multiple layers for collision map, bonus map, actor map, etc.. Easy to export, easy to import, easy to edit.

Alexis.
It's getting hard to know who's being serious any more but this is actually similar to what I'm doing at the moment. I have a height map created in gimp and an xfig file has a picture of all the objects and walls on the level. I then parse it and create 3D models and collision data from the two files. It works quite well and eliminates the need for custom level editor.

Bojan

[Uhfgood]

Quote:
Originally Posted by Octopod
Rather than using plain ASCII for level building, use Photoshop to paint your level. Multiple layers for collision map, bonus map, actor map, etc.. Easy to export, easy to import, easy to edit.

Alexis.
It's getting hard to know who's being serious any more but this is actually similar to what I'm doing at the moment. I have a height map created in gimp and an xfig file has a picture of all the objects and walls on the level. I then parse it and create 3D models and collision data from the two files. It works quite well and eliminates the need for custom level editor.

Bojan


This is intriging, you do what now to what? I thought the reason you never put the level in one big image is because the image was, well, one big image, and that takes alot of memory and diskspace.

[James C. Smith]

All the games I worked on store there levels in human readable text files and it is possible to edit them. But we also always make a level editor. Many parts of the level editor are pre-written thanks to the “property system” we use which (among other things) can generate an dynamic GUI for editing data based on a homebrew “reflextions” type system for enumerating the members variables of a class. This same system handles reading and writing the text files.

I would have to say the "property system" is the coolest coding trick I know. See Reflexive’s “property system” and property editor

[bodgey]

This is intriging, you do what now to what? I thought the reason you never put the level in one big image is because the image was, well, one big image, and that takes alot of memory and diskspace.
My game is 3D so it's easy to generate a big level with enough detail using a small height map (this creates the ground).

The walls in the game, as well as locations of holes, balls, teleports, ... are drawn in xfig (a vector drawing program) which is again a very small file because it's vector graphics. From this file (as well as the heightmap for the vertical position of the walls) it's easy to generate 3D models of walls and teleports which can then be displayed. I hope that makes sense but I'm not too sure it does. :)

Bojan

[Teq]

I partially agree with the ascii levels, while its no excuse to not write a level editor, it still allows content development while you are writing it, though if its a 3d game with just a series of millions of coordinates that benefit soon disappears...

[Savant]

(or ruby, if you have already sworn to never use python and need a backdoor escape away from C-family hell)
I've never understood the "c* is hell" attitude. It's not. C++ is a very productive language in the right hands. And I knocked up an OpenGL framework yesterday via SDL in C# yesterday and it was relatively painless (aside from the 3D math I posted about in another thread but that's not the languages fault).

I see C# as the red carpet into the future. It's got all the good things in C++ mixed with the good things from Java with extra good things piled on top. Cross platform capabilities are on the way (or, if you're adventurous you can use Mono immediately), and the CLR compiler gets better with every release.

C# combined with .NET is pure coding love.

[princec]

That's because it is hell. Managed environments and 4GLs are the future for software development. Actually they're not the future; it's here now. Try getting a job coding apps in C++. Time is money and C++ takes a lot longer to do the same job as any of the other newer approaches mentioned in this thread. So that's my Top Coding Tip: make the switch to a higher level environment and concentrate more on what you want to happen rather than how the cogs work in the machine.

Cas :)

[Savant]

Hey, I'm agreeing with you! :) Any projects I do from this point forward are going to be C# and .NET. Forget anything lower level than that. I don't have the time.

[princec]

Even that's a bit too level for me these days... what I need now is a 4GL IDE that does all the fiddly bits with a drag-n-drop GUI!

Cas :)

[ZuluBoy]

For those of us who develop cross-platform games/applications for mobile devices, C is still the language of choice :rolleyes:.

[Savant]

Mobile devices reside on their own exclusive ring of hell anyway so that's fine. :)

[ZuluBoy]

Mobile devices reside on their own exclusive ring of hell anyway so that's fine. :)
LOL
Well, you are somehow right.

[Olofson]

That's because it is hell. Managed environments and 4GLs are the future for software development. Actually they're not the future; it's here now. Try getting a job coding apps in C++. Time is money and C++ takes a lot longer to do the same job as any of the other newer approaches mentioned in this thread. So that's my Top Coding Tip: make the switch to a higher level environment and concentrate more on what you want to happen rather than how the cogs work in the machine.

Though I really rather like C and always have been more or less obsessive about performance (started serious coding on the Amiga...), I totally agree.

As to the performance "issues" of higher level languages (in particular the JIT-less VM based ones), they're becoming less relevant as CPUs get faster - not because there are more cycles to "waste", but as a side effect of the old rule that "you spend 70% of the time in 30% of the code." Last I heard, it was 90% and 10%, and although a lot of the low level stuff has now moved to hardware (audio and video accelerators), game logic and other high level stuff isn't exactly going to account for a bigger share of the CPU time in the future.


(BTW, I'm not too fond of C++, and I don't consider it a real high level language, simply because it's too complex and too dangerous. C++ has it's uses, but I'm doing fine with C even for rather complex stuff, and when I want to go higher level, I'd much rather use a real HLL.)

[Gilzu]

1. Polymorphism. The jewel of OOP :) just create a class of CEnemy with nice virtual members (say, Render(), Update() ect. ect.) and then implement every Enemy as a derived object.

now, from the main program perspective youre all done for every future enemy. Just create the class with a new AI and features, and you wont have to change the main code since it uses the same virtual members (remember Render(), Update() ect?)

2. Pack everything. Its an obsession, I know. I just like when everything is packed neatly. Hmmm, Episode one is a rainforest? sure, pack it all in a nice resource file. Level info? AI scripts? throw them in too!

[kzar]

1. Polymorphism. The jewel of OOP :) just create a class of CEnemy with nice virtual members (say, Render(), Update() ect. ect.) and then implement every Enemy as a derived object.

now, from the main program perspective youre all done for every future enemy. Just create the class with a new AI and features, and you wont have to change the main code since it uses the same virtual members (remember Render(), Update() ect?)

I am making a 2d game engine at the moment and the bit I am kinda stuck on his how to link entitys and animations etc. I was thinking of using this exact idea of virtual functions for each differnt kind of entity's update and draw code but there is one thing I can't figure out.

Say you have a textfile for each kind of entity which describes all the animations and the attributes and things. You have a inherited class for each kind of entity which contains all the code and extra variables. But how do you link the two together when you load the textfile or make a instance of an entity?

Sorry don't think I explained that clearly at all.

[Sharkbait]

kzar,

If you take the approach of deriving a class for every entity type than you might as well hard-code the animations and other attributes pertaining to each type. If on the other hand you're refering to specific instance attributes (say, position, velocity etc.) you'll need a way to define type id's, for example, as integers or strings representing each type. For a managed language like Java or C# you could easily store the actual class names and allocate instances dynamically using reflection. With C++ or other 'non-managed' anguages, your best bet would be to have a switch or nested if-then statement to instantiate from the corresponding enemy class. The downside of this is that entity types are hard-coded whereas the dynamic C#/Java approach is not. Common attributes could easily be assigned by using hard-coded getter/setter methods. For type specific properties, a good approach might be to have generic getter/setter methods that accept an additional property id or name, such as setProperty("Health", 100) or getProperty("Gold").

Hope that helps.

[techbear]

No, you did. The answer is the Factory pattern. Look here: http://www.codeproject.com/cpp/ratkfactory.asp

Hope it helps!

[HairyTroll]

I am making a 2d game engine at the moment and the bit I am kinda stuck on his how to link entitys and animations etc. I was thinking of using this exact idea of virtual functions for each differnt kind of entity's update and draw code but there is one thing I can't figure out.

I have an abstract base class called Action, from which all my 'scripts', or 'actions' that any entity or 'MOB' (movable object) can perform will inherit.

The abstract base 'Action' class implements an update() method that each derived class must override. Each 'Script' inherits from this base 'Action' class allowing e.g. Explode.update(), Sinus-Bounce.upadte(), Rotate.update() etc. scripts.

I set an entity's (or MOB's) action by calling something like;


player1.setAction(new Explode(x, y, scale, speed, player1))


An entity, or MOB also has an update() method. The Engine calls this update() method each frame:


for each MOB call MOB.update(timescale);


Internally, an entity, or MOB, will call the Action's corresponding update() method. The Action knows the MOB it needs to act on, and will set the MOB's animation frame, x/y position etc. as appropriate.

Hope this helps.

-Luke

[kzar]

Yea thanks everyone, I have pretty much got my head around it now and have almost got a basic implementation working. :)

[Grey Alien]

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".

[Gilzu]

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".

Take the "right" things with a pinch of salt. Polymorphism usually means more overhead = a bit slower code.

everything has its cons and pros.

[Savant]

Take the "right" things with a pinch of salt. Polymorphism usually means more overhead = a bit slower code.
"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.

[Pogacha]

Take the "right" things with a pinch of salt. Polymorphism usually means more overhead = a bit slower code.

everything has its cons and pros.

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

[Gilzu]

"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.

Who said I was aiming toward a puzzle game? :D platform & action are more my type, where FPS counts.


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

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.

[Savant]

Inline is also a good way to bloat your memory footprint and cause cache misses. Code optimization is a great topic. :cool:

[HairyTroll]

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.

[HairyTroll]

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.

[Savant]

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.
Man, that sounds like debugging nirvana!

[princec]

Man, that sounds like debugging nirvana!
That's how Java works...

Cas :)

[Savant]

That's how Java works...
Is that why it's so slow?

*ducks*

I kid!

[Vorax]

Is that why it's so slow?

*ducks*

I kid!

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

[Savant]

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.

[Grey Alien]

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.

[Fabio]

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.Man, that sounds like debugging nirvana!

[..]

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. 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".