Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 26 Feb 2009
Offline Last Active Dec 07 2011 01:19 PM

#4889508 Displaying text in OpenGL. why so hard?

Posted by Nanoha on 01 December 2011 - 12:51 PM

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

#4870627 [C#] Checking the amount of items in a List?

Posted by Nanoha on 08 October 2011 - 04:46 PM

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)
        Console.WriteLine(" \"{0}\"", items);
        first = false;
        Console.WriteLine(", \"{0}\"", items);

#4865419 3D Movement

Posted by Nanoha on 24 September 2011 - 02:18 AM

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)
        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;
        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.

#4863529 Might just be my way of seeing things, but........

Posted by Nanoha on 19 September 2011 - 03:37 PM

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.

#4862702 Cube Class

Posted by Nanoha on 17 September 2011 - 01:20 AM

Unrelated to your problem but this bit:

void Cube::Set_Position(Vec3f p)
        _pos = p;

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.

#4861589 Component Based Entity System Question

Posted by Nanoha on 14 September 2011 - 09:30 AM

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:


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

#4855824 Facts about John Carmack

Posted by Nanoha on 31 August 2011 - 05:25 AM

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

Lol, I liked that one.

#4855170 How to find average alpha in texture?

Posted by Nanoha on 29 August 2011 - 12:56 PM

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?

#4842885 Thread-safe iteration/traversal

Posted by Nanoha on 31 July 2011 - 12:19 PM

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.

#4836296 variable problems

Posted by Nanoha on 17 July 2011 - 03:50 AM

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

#4833076 GIMP Brush Blending

Posted by Nanoha on 09 July 2011 - 07:02 AM

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.

#4831046 game programming with librarys

Posted by Nanoha on 04 July 2011 - 11:08 AM

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.

#4829711 Calculating how much to move to some position

Posted by Nanoha on 30 June 2011 - 12:42 PM

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?

#4829705 Calculating how much to move to some position

Posted by Nanoha on 30 June 2011 - 12:25 PM

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.

#4825348 Desturation as I die...

Posted by Nanoha on 20 June 2011 - 01:19 AM

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.