Nanoha

Displaying text is indeed quite hard with OpenGL. I wouldn't use lines, I'd either go for the texture (you put all letters on a image and draw bits of it around the place) or Freetype. I've not tried freetype, it may be hard to understand but the texture bit is alot of work. A long time ago I used this: http://students.cs.byu.edu/~bfish/glfont.php it worked well. Its the texture type implementation.

Displaying text slowly like you have shouldn't be too difficult. You have 2 strings, one is the text in its entirety, the other is the part your actually showing. Every so often (miliseconds/ticks, whatever time your game uses) you add a little more to the displayed text (substring).

Its not a neat solution, for the first item just write it, then for subsequent items write a comma then write the item. Maybe:

bool first = true;
foreach (string items in mInventory.List)
{
    if(first)
    {
        Console.WriteLine(" \"{0}\"", items);
        first = false;
    }
    else
    {
        Console.WriteLine(", \"{0}\"", items);
    }    
}

Are you trying to make a door of sorts?

What your doing looks somewhat correct. This might possibly work:

bool movingUp = true; // flag to show if we're moving up or down
float moveSpeed = 1.2f;
float maxY = 20.0f; // Max value y can be
float minY = -20.0f; // min value y can be

while (1)
{
    if(movingUp)
    {
        cube[0][5]._pos.y += 1.20f;
        // Chek we've not gone too far and swap direction
        if(cube[0][5]._pos.y >= maxY)
        {
            cube[0][5]._pos.y = maxY
            movingUp = false;
        }
    }
    else
    {
        cube[0][5]._pos.y -= 1.20f;
        // Chek we've not gone too far and swap direction
        if(cube[0][5]._pos.y <= minY)
        {
            cube[0][5]._pos.y = minY
            movingUp = true;
        }
    }
}

I don't really know what cube[0][5] is so you could be more desriptive with your indices (magic numbers that no one knows what they do), define them with a descriptive name. That code will likely go very fast, possibly making the cube look like its flickering. You could use some kind of time variable and move it based on that instead.

Depends what your goal is, if your making a game then why slow yourself down or hold yourself back  with the litle things. No one can possibly know everything so ultimately your going to be using something you don't understand (blackboax). You just don't need to understand everything. If your goal is to learn (or create something new) then go for it, do every little thing - it can be very rewarding.

Unrelated to your problem but this bit:

void Cube::Set_Position(Vec3f p)
{
        _pos = p;
        glPushMatrix();
        ci::gl::translate(p);
        glPopMatrix();
}

The push/pop/translate part does nothing. You push the matrix, translate it but then just pop it again (reverting the changes you just made). you should remove that part.

Each of my components have a component loader (simple factory), my entity factory has all these "loader" objects. The graphical one  does whatever it need to (loading models, attaching things and what not) - it knows how to add things to the scene and so on. The component doesn't need to know these things (at some point it might). I can define my entities using xml like:

<Entity>
   <Components>
      <Graphical>
         <SceneNode>
            <Mesh>
            </Mesh>
         </SceneNode>
      </Graphics>
   </Components>
</Entity>

The entity factory checks if it can load a given component type, if it can - then it goes ahead uses its sub factory to do so. As I'm using factories, once the entity factory is initially created, I do longer need to pass around anything like the scene/physics and so the factory can be used pretty much anywhere without problem.

My Graphical component just holds a "SceneNode" pointer, thats enough to do what I need with it (move the visuals mainly).

Carmack doesn't like to keep doors opened because opened visible portal reduces FPS

Lol, I liked that one.

Do you have to do it "dynamically"? Sounds like you just want to know if there is an alpha channel or not. Surely its easier to work this when you load the texture? What does your loading code look like? You could perhaps use the format of the texture to save yourself some time too (if its RGB for example then you know there's no alpha).

What kind of values are you getting? Is that 10th mipmap 1 pixel in size?

I'm far from an expert on this matter but I'd say design to avoid adding/removing while iterating. Have it so you must "check out" an iterator(or just a token of some kind) and only allow adding/removing when all iterator are in. You can queue things for adding/removing instead of outright denying them. Consider a double buffer of sorts, while itersting one list all new things are added to a second list. You then add them all once you stop iterating.

if your changing map_height/map_width at runtime then its not possible to do (you can allocate with new instead). If those values are NOT going to be changing then just define them as constant.

const int map_height = 1;
const int map_width = 1;
terrainbox terrain1[map_height][map_width];

Of course they need to be known before you declare your terrain. Otherwise will have to do somethign like:

terrainbox *terrain1 = new terrainbox[map_height*map_width];
// Make sure to delete it at the end with
delete [] terrain1;
terrain1 = NULL;

Althought its declared as just an array (not a 2 dimensional one), indexing should still work but you might have to do this:

terrain1[x][y] now becomes terrain1[x+y*map_width]; (or maybe terrain1[x*map_height+y]; depending if you want your array to be row or column major).

Paint it to a seperate layer, if pixel is not coloured then colour it with the paint value, otherwise do nothing (unless your brush has some falloff). You can render this layer over the top with alpha blending. Once you release the mouse then you apply the layer to the layer your actually trying to draw on. Its sort of doing the "big array" thing you didn't want but slightly differently. Blending alone won't solve your problem as the effect you have is blending, the effect you want is not blending (its logical). Sounds like your doing render to texture, just get 2 render targets. One you render to while the brush is down, once its released you render it onto the "canvas" target and clear it ready for the next time you start painting.

If you look at something liek Ogre3d, it works with a number of things (opengl, diectx and more). All through a common interface. There's also no need to rebuild anything when switching between different API/libraries. I think it would be alot of work  to get to that point though.

So you you only wanted to move 1 tile at a time down only one axis at a time (the longest axis)? Or have I misunderstood?

new_position = old_position + (speed * (target_position - old_position))
step1: new_position = 100 + (1.0f * (338-100))
step2: = new_position = 338
Now im flying!

target_position - old_position needs to be normalized before scaling for speed, it'll end up being eithe -1, 1 or 0 which will work out ok with speed. It makes more sense if these are vectors rather than just numbers.

new_position = old_position + (speed * normalize(target_position - old_position))
step1: new_position = 100 + (1.0f * normalize(338-100))
step2: new_position = 100 + (1.0f * normalize(238))
step3: new_position = 100 + (1.0f * 1))
step4: = new_position = 101

if speed was 10, you'd be at 110 now which makes sense.

I think you have a point. I've never really found it a problem though. I guess its also a good way to remove "health" from the ui.