Lauris Kaplinski

Which programming laguage(s) are you using?

How heavy-duty will this GUI be? Will it just be some forms, lists, buttons or do you need to implement your own specific controls?

Qt is good choice. I personally prefer Gtk+. WxWidgets is also free cross-platform widget set.

Unless you are professional modeler and your art is reasonably generic I doubt that you will sell much. Prepackaged game content market is not as big as people may think.
Usually the best suggestion is - focus on what you are best at first. If you are programmer, start with programming + placeholders. If you are modeler start with modeling + some quick prototyping in Unity or some other similar tool.
Once you have reached to certain stage and are confident that your idea works, it will be the time to think how to organize other aspects of game development.

It is impossible to tell wether you have undertook too big task without knowing more about you and your game ;)

I have been in similar situations where I see how my code has grown into unmanageable mess. But usually at that moment I have already "seen the light" - i.e. what should have been done differently from the beginning.
I suggest not abandoning your current project - you have most probably already invested much time into the design of concept, gameplay etc. But be no afraid of starting over - as long as you consider it your learning project. Of course finishing crappy game is usually better than not finishing clean and elegant one - but on the other hand rewriting everything is better than abandoning it.

1) I have mostly used Code::Blocks and Emacs. C::B is easier, especially if you have used other IDEs before.

2) I always install mc (file manager for terminal). Most useful things come preinstalled, but you have to manually add development packages - starting from C++ and SVN and ending with development versions of basic libraries.

3) It is very useful, especially if you want to peek "under the hood" of working Linux system. Once you feel comfortable with it, it is usually much faster to do simple file operations in shell than using mouse.

I do not know any other way.
Even worse - to have proper refraction it is not enough to simply render all your scene to texture, because you have to render it using "refracted" camera viewpoint. There may be areas that are not directly visible to camera but become visible via refraction.

Normally such problems are solved via level design - avoid placing too many semitransparent objects in such way that they need expensive processing.

Are you using floating point or integer textures. Do not forget that the latter can only hold values in range 0.0...1.0
Thus if you are reading (and storing) your position (and normal) values from texture you have to transform these:

Storing

vec4 outputcolor = 0.5 * (vec4(1.0, 1.0, 1.0, 1.0) + position);

Reading

vec4 position = 2.0 * (vec4(0.5, 0.5, 0.5, 0.5) + texture( gPositionSampler, In.TexCoord ));

If you are posting in beginners forum then you shouldn't use goto in your code
Once you reach advanced level... well, then you know yourself.

I suggest you to write at least minimal widget library (or better yet - use existing). It is not very hard, but makes extending your UI later much easier. Something along the lines:

class Widget {
public:
	int x, y, width, height;
	// Mouse events
    virtual bool onMouseMove (int x, int y);
	virtual bool onMouseButtonDown (int button, int x, int y);
	virtual bool onMouseButtonUp (int button, int x, int y);
	  virtual bool onMouseClick (int button, int x, int y);
	// Render method
	virtual void render (SDL_Surface surface);
	// Constructors etc...
    Widget (int x, int y, int width, int height);
};

class Container : public Widget {
public:
	std::vector<Widget *> children;

	// Example
	virtual bool onMouseButtonDown (int button, int x, int y);
	// Other method implementations

	// Constructors, destructor...
};

// Exmple method implementation of container class
// Other methods have similar logic
bool
Container::onMouseButtonDown (int button, int x, int y) {
	for (child = children.begin(); child != children.end(); ++child) {
		if ((x >= child->x) && (x < child->x + child->width) && (y >= child->y) && (y < child->y + child->height)) {
			if (child->onMouseButtonDown (button, x, y)) return true;
		}
	}
	return false;
}

class MenuButton : public Widget {
	// Image/surface etc. data
	// State
	// ...
};

Basically you send processed events to topmost object of your widget hierarchy. Depending on mouse location they will be rerouted to proper widget object.
I higlighted only the absolute bare-bones of such system. But it can be extended to handle things like automatic reformatting of widgets when screen resolution changes etc. The important point is to abstract your event handling code (i.e. showing menu image) away from main loop into extensible, self-contained class.

• You are right, this is not something you should worry about, unless you have profiled your program and identified it as a performance bottleneck. Plus chances are that if it will be the bottleneck then simply passing destination as function argument will not help you.
• Yes, modern compilers should optimize out such assignments in release (optimized) mode.

Do it the easier way:

	...
	vu[0] = vertices[k + 1][0] - vertices[k][0];
	vu[1] = vertices[k + 1][1] - vertices[k][1];
	vu[2] = vertices[k + 1][2] - vertices[k][2];

	vv[0] = vertices[k + 2][0] - vertices[k][0];
	vv[1] = vertices[k + 2][1] - vertices[k][1];
	vv[2] = vertices[k + 2][2] - vertices[k][2];

	... Now calculate your normals from vu and vv ...

	if (k & 1) {
		// Invert normal for all even triangles
		normals[k][0] = -normals[k][0];
		normals[k][1] = -normals[k][1];
		normals[k][2] = -normals[k][2];
	}

I.e. just invert the normal. You probably have to test by trial and error, whether you have to invert normal for even or odd triangles because it depends on which convention is used by model format.

• You should not iterate from 0 to nvertices - 1, but instead either from 0 to nvertices - 3, or 2 to nvertices - 1. For example try to analyze what happens, if i = nvertices - 1 in your cycle.
• You have to flip the direction of calculated normal each step. This is beacuse the order of triangle vertices alternates between CW/CCW while triangle strip is used. This seems to be the problem why you are having wrong normals.

A segment of triangle strip - notice how the first triangle should be 123 and second 324 to be CW

In my system Material is the most "intelligent" class. I have the following hierarchy:

• Vertexbuffer, Indexbuffer - contain all vertices and indices of certain geometry. VB has flexible system of vertex attributes - i.e. there are slots for "normal" attributes like 3D coordinates, normals and UV, but one can add as many extra attributes as needed.
• Mesh - binds together VB, IB and Material(s), also has 3D transformation and bbox assigned to it. Mesh has list of fragments, each fragment can be rendered with different material. ::display() method of mesh submits a renderdata to list for later processing (renderdata has link to VB, IB, transformation and material).
  Multiple meshes may share materials and vertex/index buffers.
• Shader, Program - these are just frontends of OpenGL shader and program objects. ::bind() method of program sets it as active OpneGL program but does not set up uniforms - the latter is left for material.
• Material - the heavy duty class. Material has one or more programs (i.e. shader frontends) (depending on render pass, the same mesh fragment - having same material - may be rendered with different shader). In ::render() method of material the renderdata is parsed, uniforms set up, relevant attributes of associated VB bound and glDrawElements... called.
  Multiple materials may share programs.

The idea behind my design is, that all geometry objects have pretty similar structure while the materials vary a lot. Materials have also access to global rendering data (like GBuffer textures etc.). Material also "knows" which attributes associated shader needs and may only bind subset of all attributes in VB - for example in depth pass it can use separate depth shader and ignore normals/uv/colors...

Your ::Contains method seems to have too many checks. Normallly you only need 4 tests for 2D containment detection.
If you want to only put entity into node if it is fully contained in it, you have to test that:

Entity.minx >= quadtree.minx
Entity.maxx <= quadtree.maxx
Entity.miny <= quadtree.miny
Entity.maxy >= quadtree.maxy

I would agree with mhagain about stepping up to OOP. Java or C++ are good choices, although if you are comfortable with C then maybe C++ might be a better choice - but either either way you cannot go wrong.

Personally I suggest learning Java. C++ is a bit too similar to C and thus you will end up doing many things "the C way", instead of "C++ way". Once you have learnt OO with separate language you can better understand the nuances of C++.

Otherwise - C is excellent first language. Although it has some complex parts - like memory management and pointer arithmetic - it is otherwise small, compact and powerful. And it gives you the "feeling of being close to metal" - i.e. understanding better how computers crunch through high-level data structures. While you can be good programmer without knowing low-level details, having more insight never hurts

So I'm working on a roguelike, and I have a question about drawing the map and all the entities and items that reside on it. The way I have it programmed at the moment, is the board is a 2 dimensional array of tiles. Each Tile has its own char to represent it, and contains an Entity member. This way, when the draw method is called, each tile spits back either its own icon, or if it has an Entity, the Icon belonging to the entity. These chars are all concatenated into the string that is eventually thrown to the display.

You are not actually appending data to string for each tile are you? This is probably quite slow operation...

I would love to be able to simply replace char at index in a string, but I haven't found that such a method exists. (Even if it does, are the underlying mechanics similarly iterative, so would it even save anything over the options described above?)

I suggest storing everything in byte[] array and building string to be displayed in one step later. You can reuse your array between display events, thus avoidng allocation and GC. And building string in one go should be A LOT faster than appending to it constantly (appending involves probably many reallocations).
Then you can iterate over tiles, set all icons in byte array, then iterate over entities and replace icons at their locations.