Felix Ungman

There's only one way to deal with leaks: Find them and fix them.

 

Leaks don't necessarily come from new/malloc statements in your own code, they could also happen indirectly if you don't call the proper cleanup methods in library code.

 

There are two methods to find leaks:

- Use a static analyzer that examines logical errors in your code.

- Run the executable using a memory profiler and watch for unreleased resources.

 

With good tools tiny leaks should be as easy to detect as massive ones.

Good thing they put parentheses around those literals!

 

edit:

Oh gosh, I didn't even realize the TEN issue... That's horrible.

 

 

I don't understand, the only problem is that it's not complete? Here's an excerpt from the full definition:

#define EIGHT  (0x08) 
#define NINE   (0x09)
#define AYE    (0x0A)
#define BEE    (0x0B)
#define CEE    (0x0C)
#define DEE    (0x0D)
#define EE     (0x0E)
#define EFF    (0x0F)
#define TEN    (0x10)
...
#define NINETEEN (0x19)
#define AYETEEN  (0x1A)
#define BEETEEN  (0x1B)
...
#define NINETYEFF (0x9F)
...
#define AYETYDEE  (0xAD)
...
#define EFFTYEFF  (0xFF)

I managed to get this to work by a lot of optimizing, basically using the original setup.

- Going from sobel to cross filter for faster edge fragment shader (half the number of texture reads). Not as pretty but OK in this context.

- I was sloppily using a lot of fragment discards in many shaders, now I only do a few edge triangles in a special shader.

- Lots of small tweaks as suggested above and in the imgtec document.

 

I didn't use the alpha channel for the depth buffer, it seemed to produce artifacts, and I didn't notice any performance gain (although I'm not sure I did it right). I guess I could do more research to see if this is feasible some how, but the frame rate is ok now so I'm leaving it as a future to-do item.

The presence of 'auto' is becoming wide spread and is a really really bad practice.  [...]
 
In regular code, there is no benefit in using it (other than lazyness) and inherits all the problems from weakly typed languages: [...]

 

I used to program a lot of C# and was of the same opinion regarding its auto-equivalent, the "var" keyword. Then I played around a bit with F# which completely changed my mind. F# is a strongly typed language but encourages you to not specify any types anywhere. It makes you have to write readable code without the help of type "tags" sprinkled thru out the code. It's a very good exercise. Going back to C# a completely refactored the codebase I worked with to use "var" for all variables except the "built in" types (in C# int, float, decimal, string are language specific aliases to System.Int32 etc). The code got shorter and much more readable.

 

Now, the type system in C++ is much more complex than C#, so I'm not advocating the same principle here. But I still think that liberal but purposeful use of "auto", when done right in the right context, can be a good coding style.

It seems to me that if indexing would be a significant optimization, then you preferably would want some kind of shared-node structure where you don't need to post-process vertices. But that might not always be easy to do, depending of where the vertices are originated.

In theory, you could actually recursively include objects using some funky C++ template programming.

template <int level>
struct Menu
{
	Menu<level + 1> subMenu;
    ...
};

template<>
struct Menu<3> // hierarchy ends here
{
    ...
};

static void foo()
{
	Menu<0> menu;
	menu.subMenu.subMenu.subMenu; // ok
	menu.subMenu.subMenu.subMenu.subMenu; // error, no such member
}

Not that this is the way to do it, but it illustrates that C++ is flexible enough to do this kind of perverted solution.

There are some caveats when using LINQ, such as understanding how lazy evaluation works (and especially when querying against databases).

For example, if you only iterate thru the query once, you're better of not making an array, but just do a foreach on it, such as:

var components = (
			from component in ChildComponents
			orderby component.UpdateOrder ascending
			where component.Enabled
			select component);
foreach (var component in components)
			component.Update(gameTime);

If you on the other hand are going to iterate thru it many times, then you better cache it into an array, otherwise it will query and sort it each time you iterate.

That said, I don't think you can write a non-LINQ version of that particular code (i.e. tens of items once every game loop) that will provide you with significantly better performance. It should perform about the same as any non-LINQ version.

Hello guys, I want to create a game engine and i am confused with things. Can anyone say the things i need to know please..

The things you need to know are:
- a programming language
- a graphics library
- a sound library
- a library for mouse/keyboard/gamepad input
- at least three game designs that could be implemented by the game engine, preferably as different from each other as possible (within the scope of the engine).

Also, keep in mind the difference between allocation/deallocation and construction/destruction. If the enemy holds projectile objects (e.g. an std::vector<projectile>) you don't need to do anything extra, all destructors are called automatically. But if it holds object *pointers* (e.g. std::vector<projectile*>) you need to decide on ownership. It's usually a good idea keep allocation and deallocation responsibility together. If it's the enemy object that allocates and stores projectiles, it should likely deallocate them too in its destructor.

[edit]

Ah, reading the OP I see the enemy doesn't hold projectiles. However, the principle that keeping allocation and deallocation together is still good advice here. And in any case, neither the birth and death of an object instance should be controlled by that instance itself. The former is just counter-intuitive and the latter too controversial.

I think as a general rule, the more and harder obstacles you put in the game, the more control has to be given to the player. One option is to match a simple control with non-fatal obstacles (like Tiny Wings, where all you loose is your momentum). The other option is to add more advanced gesture for more advanced moves (while keeping the basic gestures simple), like tap-and-drag, second tap, tilting (accelerometer), etc. But one thing's for sure, good gameplay takes a lot of tweaking. You have to start with some general idea and then tweak, adjust, tweak and then tweak some more.

My personal choice would be C# too, but language-wise they are similar enough that learning one and you will cover 90-95% of the other. I think that the frameworks and IDEs are more important factors than language syntax in this case.

I think both politics and economics are excellent game design elements. There are a lot of game-like aspects there, complex networks of interactions, that generate rich strategies. Using politics as the theme can work too. If the game is good there's certainly the niche of "sofisticated" simulation/strategy gamers to pick it up. If I remember correctly, Chris Crawford's Balance of Power, a geopolitical simulation set in the cold-war era, was quite successful for its time.

There are only two reasons to roll your own framework:

1) You think it's fun and want to learn something new *and* there are no time/budget constraints.
2) You're in the business of making frameworks, and the framework is a product in itself (or a vital part of a product).

For hobby projects, you might want to do it for reason 1. But for commercial projects, neither of the reasons apply, and you should consider going with an existing framework (even when it doesn't meet you needs perfectly).

There are recursive functions that are not tail recursive. That is, not every recursive call is a tail call. A classical example is:

int fib(int n)
{
  if (n < 2)
    return n;
  else
    return fib(n-1) + fib(n-2);
}

Note that the last operation is the addition of the results of the recursive calls, there are no tail calls to optimize.

I couple of aspects are:
- Text is much more readable, even in small font sizes. Not only are individual characters much sharper, but the overall text layout is much better.
- Animated objects move much smoother. Even with crude graphics, the movement of game objects can be much more precise.
- With smaller pixels you have more control over the layout. Thinner lines and boxes gives you more space to work with.
- More pixels means you can add more detail. Not by cramming in more stuff in less space, but rather playing with different levels of emphasis.

Of course this is, and should be, all very subtle, and nothing that you should notice at a glance.

Some more reading:
https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html