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!

Lauris Kaplinski

Member Since 02 Aug 2006
Offline Last Active Feb 18 2013 02:33 AM

#4992523 Index Buffer Issues

Posted by Lauris Kaplinski on 21 October 2012 - 01:05 PM

BY any chance are you using GL_LINES to draw your wireframe?

GL_LINES draws one line segment between each pair of vertices. GL_TRIANGLES draws triangle between each triplet of vertices. Thus if you have, for example, an index buffer:
It defines two adjacent triangles (sharing edge 2-3), but if drawn with GL_LINES, only two line segments (1-2 and 2-4) will be drawn.

Primitive types (GL_TRIANGLES, GL_LINES, etc.) define the topology of your mesh. In your case the topology is triangles so you have to use GL_TRIANGLES always.
glPolygonMode defines whether you want your triangles to be filled or outlined.

So you have to set glPolygonMode to GL_LINE and use glDrawElements with GL_TRIANGLES in your code for wireframe mode.

#4992084 loot / ammo / currency persistance across game-overs in level based game

Posted by Lauris Kaplinski on 20 October 2012 - 03:01 AM

Personally I like third option - make game-world, including enemies, (somewhat) persistent. I.e. if you die, your items will remain at that place and can be picked up in next try. If you use your precious rocket to weaken big boss, his defence will be weaker in next try. And so on...
Of course this approach probably requires very different level design. There will not be much fun if you drop all of your precious loot at big boss den...

But of your two alternatives I will definitely vote for the first. If player fails the first time because the level was too hard for him it is not fun if the next time level is even harder.

#4991852 What to know in order to write a mesh parser?

Posted by Lauris Kaplinski on 19 October 2012 - 12:11 PM

I'd like to learn how to write a Mesh Parser, using features in OpenGL from 3.3 and up (my drivers should support 4.3, I'm currently running 4.2).

Normally you shouldn't tie a mesh parser to your rendering subsystem. Write a parser that can extract all relevant information (usually vertex atributes, triangles and material definitions) from your mesh format into clear in-memory objects. Then write a rendering system, that generates VBO-s etc. from your in-memory data.
You can save some memory bandwidth by going directly from file to OpenGL buffers but normally it is not worth it.

The question is, I'm not sure what techniques/concepts would be good to understand first. I know how to write a binary search tree, if that helps - but maybe a QuadTree or even an OcTree would be more useful?

What sorts of meshes are you trying to parse? Terrain/large static structures should be handled differently from character models and small props. You probably need octree for the first but not for the others.
Start simple - write loader that generates single object/buffer. Once this works you may try octrees.

Also what would be good to know is what kind of file formats are most common in the OpenGL world. Should I use blender to draw meshes, export the files, and render them in OpenGL? Is it possible and pragmatic to write a single mesh parser which would just render whatever kind of mesh I throw at it?

What is OpenGL world? As you are here, you are probably keeping OpenGL game development in mind.
I'd suggest starting with OBJ for static objects, then MD5 for skinned characters. In that way you learn the basics of mesh composition - most file formats are very similar in basic logic, only layouts differ.
FBX is very common format in 3D pipeline. Most engines (include indie ones) use custom formats that will be exported from game editor.

I'm aware of prewritten libraries such as GLMesh which help with this (though I'm not sure to what extent they do), but alas my goal is to learn so I'd like to avoid using something like that :3.

Write parsers for some mesh formats to learn the basics. Once you know how this can be done, throw your code away and use library Posted Image

#4991354 Question about state machine

Posted by Lauris Kaplinski on 18 October 2012 - 12:58 AM

In this arrangement, I have two states. brain_states is for the AI, or the user if the state is STATE_PLAYER. physical_states are for movement. At first I tried to use only one state to do all of this, but couldn't do it and ended up seperating the mind and body into two states. Are two states enough, or too many? Is there a way to use only one state?

It is impossible to say whether two states is enough without knowing more about your game logic. But you eventually will find out it yourself if you write the code ;-)

As rip-off told - I strongly suggest separating controllers and models into separate structs.

struct Mind;
struct GameObject {
	int posx;
	int posy;
	float direction;
    int physical_state; /* Idle/moving... */
	struct Mind *mind;

struct Mind {
	int type; /* Player/AI/... */
	int state; /* Attacking, retreating... */
	struct GameObject *object;

Two-way link between mind and body allows you to go easily in both directions - from mind (for example planning) to movement and from body (for example collision hit) to mind.

#4990304 Picking My Game's Name

Posted by Lauris Kaplinski on 15 October 2012 - 02:05 AM

If you do not have a good idea just now, try to take the stepwise approach (borrowed from the excellent screenwriting book "Save the Cat" http://www.blakesnyder.com/)
  • Write down one-two sentence logline (What this game is about?). You may try many different ones.
  • For each one, try to find a name, that resonates with it (like Rybo5001 said)
  • Test these loglines. Approach different people, tell that you are creating a game about... called ... and ask, what they think about it.
  • Pick the one, that generates most interest in other people.
  • Iterate if necessary.

#4989818 So, What makes players to play a game over and over?

Posted by Lauris Kaplinski on 13 October 2012 - 10:57 AM

I do not agree with your notion about stories.

Look at some of the greatest books and movies. People may know these by heart but still read and watch them again. What means novelty and unknown content definitely is not the only reason that keeps you attached to story.

There probably has to be certain kind of emotional attachment - that can be caused either by people or places in story. Most games do not achieve that - and maybe interactivity is a hindrance here. But if present this attachment can be strong motivator to replay/reread/rewatch games/books/movies.

#4989228 Opinions on resetting difficulty+experiencing the same series of overarching...

Posted by Lauris Kaplinski on 11 October 2012 - 02:04 PM

I think to get around the kind of issue you describe I'll need to not have too much involvement between characters in any one character's playthrough, which I think may not be how you were envisioning your version of this kind of scenario in your game Posted Image. My characters will be operating in the same timeline, but with their own missions and paths that are not necessarily intertwined in each level. Eg when playing A, you won't often be directly involved with B and C in the same level at all. A is flying to some position to recover Blue Widget while B would be staying behind to defend their main ship. Because each character as I envision it now has their own "job" (eg A is a Scout, B is a Defender/Fighter), they will have different kinds of missions and objectives that are designed for their role and while they'll be going through the same journey from Day 1 to Day X, they will (mostly) be doing so in different locations, scenarios, and kinds of objectives.

Fair enough Posted Image

Keeping character-level interaction low certainly simplifies things. But in that case what will be the story that is told from different perspectives?
  • Backstory - just reveal different pieces of full puzzle in different paths. IMHO backstories are overused - but they may also be very addictive if you have/are a good writer.
  • No story at all - only general references to previous missions. Links between playthroughs are implemented simply via game mechanics.
The second variant is more interesting for me (although you can probably mix tory and game mechanics too).
For example it can be used to make quite logical level/difficulty system. At first playthrough you are completely free to choose pacing, mission order and so on. On second you are constrained by previous one. On third you are constrained by both previous one etc.

#4989092 Opinions on resetting difficulty+experiencing the same series of overarching...

Posted by Lauris Kaplinski on 11 October 2012 - 07:32 AM

I plan to do something similar in my game. There will be two sides of a single story - girl and boy viewpoints. The first playthrough will always be as a girl and the second character will only be unlocked after finishing with the first one. The main story will remain the same - and does not require second playthrough to be understood. But there will be many new details in story, game mechanics and environment to be explored.

One thing that has to be thought out is how to "force" player to be at the right place at right time if story requires so. I.e. if during the first playthrough character B was covering character A in certain quest then what to do, if player decides to ignore character A completely while playing with B?

In your example - what to do if something has to happen according to scenario A logic but not according to scenario B logic? Say computer-controlled player B defended the ship of A and destroyed enemy mothership (with big explosion). Now when playing as B player will not attack mothership, but simply keeps it away from A while mostly dodging missiles. So according to game logic mothership should not explode, but according to story logic it should.

My current plan is to be flexible with timings - i.e. all important events from the first playthrough will become "checkpoints" in second. The story will not advance until player has gone through them. But I have no idea whether it works.
Such things have to be solved in game logic level. But if done right they can make story much more engaging - at least for those players, who like familiarity.

#4989057 Opinions on resetting difficulty+experiencing the same series of overarching...

Posted by Lauris Kaplinski on 11 October 2012 - 05:19 AM

That is, should playing through all three characters be considered a requirement to reaching some sort of satisfying conclusion or should the player be able to finish one playthrough with Character A, B, or C and be satisfied with the ending, then play the others if they want to gain more interesting but not necessarily required insights into the overall events of the timeline? This is all in terms of revealing the overall story of this journey - each character will of course have their own missions that are relevant to their individual narrative and progression through this timeline.

I personally like the second option more.

But please understand that these are completely different game design options. The first is designing a game for a single playthrough of three-part story. The second is designing game for replayability.

In second case you could even do the following:
Save all relevant decisions/events of playthrough with character A. When replaying with character B, insert these events into story as computer-controlled events. When playing with C insert the events of both A and B. If playing again with A, insert B and C events, but let player to choose new storyline for A...

#4988332 approximate normal mapping...

Posted by Lauris Kaplinski on 09 October 2012 - 07:21 AM

@Lauris: sorry for my "newbie" question... Very shortly, how do you use the three values you mentioned (location of the surface point, location of the point in mesh geometry and normal at that point) in order to set a pixel value in the bump map? i

The value of bump map texture at given (UV) point should be the distance between true surface (full-detail model) and approximate geometry (actual model) surface along the normal of approximate model surface.
In other word - if you "apply" the bump map to low-poly model surface, the values of bump map texture pixels determine how much surface pixels have to be "moved" to get to their "true" positions.

#4987356 Is that way of using constructor really better ?

Posted by Lauris Kaplinski on 06 October 2012 - 04:28 AM

And if I need bananas, I'm going to eat good old fashioned apples!

assignment != initialization Posted Image

By the time your assignment is actually reached, your variables will have already been default-initialized (though it'd probably be optimized out* if the variable isn't accessed before your assignment).

And if something smells like banana, tastes like banana and looks like banana, then it probably is banana, even if it is advertised as an apple...
For all primitive types - and that included pointers - assignment is initialization. For all practical purposes. And programming (as opposed to theoretical CS) is practical discipline.

Btw, I find it very disappointing, that people are downvoting Ryan_001 for a shortcoming in C++ standard and suggesting practical solution to overcome it. Many people are using only subsets of C++ standard for various reasons - and calling them bad programmers, summer students or saboteurs because of that is pointless insulting.

#4987352 Still confused about "static"

Posted by Lauris Kaplinski on 06 October 2012 - 03:24 AM

I imply you are talking about C++ ...
Overloading "static" keyword is one example of the bad language design in part of C++ (it was partially inherited from C, but C++ made it much worse).

Ok, as of your questions:

One example of using static method is writing frontend to your object construction/fetching system:
class MyClass {
	MyClass (const char *id);
	// Either fetch existing object by id or create new if not present
	static MyClass *newMyClass (const char *id);

MyClass *myobject = newMyClass ("somename");
There are different patterns to achieve that, but the example above has nice feature of keeping object construction interface inside class.

Another example are methods, that operate on multiple objects
class Vector {
	// Get the length of single vector
	float length ();
	// Dot product of two vectors
	static float dot (const Vector& a, const Vector&b);
Now you could use "ordinary" method for "dot", but this has wrong implication that one of the "dot" components is somewhat special.

You also will use static methods as callbacks while interfacing with C libraries (and C++ code too if you want to avoid the mess with method pointers)

As of static variables, you have to make distinction between the ones declared inside class and the ones declared inside methods (scope).
If you declare variable static inside method, it makes this variable persistent between different calls to the same method (both for "ordinary" and static methods. It can be used, for example, in following pattern:
void myMethod () {
	static bool warned = false;
	if (some_error_condition && !warned) {
		// Warn user
		warned = true;

Static variables declared in class are simply global variables that are associated with class (i.e. acces privileges, namespacing etc.).

#4987266 Quantifying Difference Between Two Images

Posted by Lauris Kaplinski on 05 October 2012 - 03:53 PM

You need at least some idea, what kind of similarity you want to use as the basis:
  • The easiest is simply sum color differences of individual pixels (like turch suggested)
  • Another is to find euclidean distance between MxN vectors (like Alvaro suggested)
  • Now you may want to punish big differences proportionally more - in that case you may want to square the absolute differences before before adding them
  • If you want to give less weight to high frequencies you should downsample images before comparing
  • If you are interested in human percievable difference, you should transform your image to YUV or similar colorspace
  • If you want to add more importance to shapes you may want to apply some edge-detection
And so on Posted Image

#4986758 Clipping a plane to the view frustum

Posted by Lauris Kaplinski on 04 October 2012 - 07:32 AM

I think it will be easier to take all edges (i.e. line segments) of frustum, find the intersection points of these and your plane (you have 0 or 1 intersection point for each segment) and then wind those points.

#4986513 c++, sdl - how to make installer? .exe

Posted by Lauris Kaplinski on 03 October 2012 - 01:54 PM

Unless you have very special needs I suggest to not create installer package. Just create the proper directory structure, add all relevant .dll and data files and pack it into zip archive.

Personally I avoid installing anything that does not come from very well-known and reliable source - because more than often the uninstall feature is either poorly implemented or broken. Plus I do not see why simple games should need to save anything to registry, access files (except save files) outside it's installation directory and so on.