Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


haegarr

Member Since 10 Oct 2005
Online Last Active Today, 12:36 PM

#5177230 Animation Manager ?

Posted by haegarr on 31 August 2014 - 11:05 AM


As an example, for a 3d character. "Static" would be something like a running animation. Overwrite would be something like a melee (so you can run and hit something at the same time). Additive would be aiming, the rotation of the head and arms to modify depending on where you are aiming.
 
So now there are some conflict as when a melee animation is happening, then there shouldn't be any aiming, otherwise it would distort the melee animation.
 
I know i've read about state machines but i can't wrap my head around some ideas. ...

Look for the keywords

* animation blending: mixing animations on the same parts using weights,

* animation layering: overriding animations or suppressing them,

* animation masking: applying an animation only to the parts that are marked (e.g. specific body parts of a skeleton).

 

A state machine is useful to select animations, but its isn't useful for the mentioned purposes. The construct to control above mechanisms is often called animation tree or blend tree.




#5176156 FBO: Render to Texture not working!

Posted by haegarr on 26 August 2014 - 03:10 AM

A guess: Are width and height both POTs? You use GL_TEXTURE_2D as attachment. Maybe you need to use GL_TEXTURE_RECTANGLE.

 

I see that you speak of "doubling 320 x 480" ... that may hint at that they are not POTs.




#5176145 FBO: Render to Texture not working!

Posted by haegarr on 26 August 2014 - 01:44 AM

1.) In create_render_target you are creating a render buffer as well as a texture, and attach both to the same attachment point COLOR_ATTACHMENT0. That makes no sense. Use a render buffer or else a texture for a single attachment point. Since you probably want to use the result later for mapping, it should probably be a texture.

 

2.) Does rendering require depth buffer? Your FBO lacks a depth buffer.

 

 

EDIT: No really related to the problem, but glBindFrameBuffer( GL_FRAMEBUFFER, 0 ) should also be invoked when returning due to an incomplete buffer.




#5176033 room escape engine

Posted by haegarr on 25 August 2014 - 12:02 PM

What exactly is a room escape game?

 

When looking at the game you referenced in the OP, it seems me to use the classic point-&-click graphic adventure mechanics. So perhaps ... you may find the Adventure Game Studio fit your needs.




#5175972 How to program tile transitions (C++/SFML)

Posted by haegarr on 25 August 2014 - 05:10 AM

A possible technique for what Servant describes is named texture splatting. It can be done with a manually generated map but also with a map derived automatically from the surrounding tiles. The latter process is described in detail in Charles Bloom's good ol' article here.




#5175950 Storing level data in grids

Posted by haegarr on 25 August 2014 - 02:19 AM

I want to place a new room I've created on the [--] grid, and I can't for the love of God figure out how the heck do I automate the process of linking the new room to the rooms below and right side. ...

We're speaking of editor functionality here. What programming language do you use to program the editor? I'm using some pseudo code in the following:

 

Possibility 1: 2D array

 

Allocate a 2D array with the size specified within the level creation dialog, say N by M cells. The array stores pointers to Room structure instances. Initially the array elements are all set to nil, denoting that no room is associated with that cell. Each cell in the grid uses 2 numbers as address, directly useable as index into the 2D array. If a new room is placed at index (n,m), then the editor checks for neighbored rooms as follows:

if (n>0 and array2d[n-1, m] != nil ) then "room to the left exists";
if (n<N-1 and array2d[n+1, m] != nil ) then "room to the right exists";
if (m>0 and array2d[n, m-1] != nil ) then "room above exists";
if (m<M-1 and array2d[n, m+1] != nil ) then "room below exists";

What "room ... exists" may mean is explained below.

 

Possibility 2: 1D array

 

Perhaps 2D array are not your friend. There is this little trick with calculates a 1D array index from a 2D index. For a grid of N by M cells, an index (n,m) can be used to calculate

i := n * M + m

or alternatively

i := m * N + n

for an array of size N*M, of course.

 

Since this just is the indexing scheme, it can be hidden up until directly accessing the array, so the usage is the same as in possibility 1.

 

Possibility 3: associative map

 

The standard library of your programming environment supports an associative container, usually called a map or sometimes also dictionary. Such a map associates a key with a value. The key is the 2D index like above, or perhaps better the 1D index as shown above, while the value is a Room structure instance. A map has as many entries as rooms actually exist (as opposed to an array which has as many entries as cells are specified, i.e. equal to the amount of possibly existing rooms).

 

Asking a map for the existence of a room is a bit easier since an "index out of bounds" cannot occur. 

if (map(index(n-1, m)) != nil ) then "room to the left exists";
if (map(index(n+1, m)) != nil ) then "room to the right exists";
if (map(index(n, m-1)) != nil ) then "room above exists";
if (map(index(n, m+1)) != nil ) then "room below exists"; 

Again, what "room ... exists" may mean is explained below.

 

Possibility 4: sequence / vector

 

This possibility uses a self growing linear storage. As opposed to an array solution, there is not an entry for each cell but only for each existing room. The Room structure itself has a field that stores its own 2D or 1D index. Whenever you want to know whether a room exists, you iterate the sequence and compare the values of the stored room index fields with the given index. If such search is implemented as routine "lookup", it looks like so:

if (seq.kookup(n-1,m) != nil) then "room to the left exists";
...

And now ...

 

"room ... exists" in detail

 

So, when the above code enters an "room ... exists", you have to store the link correct inside the Room structure. Again, I don't know how this link should look like. You may store the pointer to the other room directly, or the 2D or 1D index. If we use "storage" for one of the possibilities shown above, that may look like so: 

if (storage(n, m))
    then "there is already a room in that cell"
    else {
        Room* newRoom = createRoom(n, m);
        Room* neighbor = nil;
        // looking to the left ...
        neighbor = storage(n-1, m);
        if (neighbor != nil)
            then {
                newRoom.leftNeighbor = neighbor;
                neighbor.rightNeighbor = newRoom;
            }
        // looking to the right ...
        neighbor = storage(n+1, m);
        if (neighbor != nil)
            then {
                newRoom.rightNeighbor = neighbor;
                neighbor.leftNeighbor = newRoom;
            }
        ... similarly for above and below ...
    }
}



#5175773 Storing level data in grids

Posted by haegarr on 24 August 2014 - 04:50 AM

I'm quite not sure what your goals are. The original mechanics seems me to be a 2D map (called "room") in side view, build by predefined tiles, a non moving sight, where explicitly modeled exits are used to switch over to the next room. You want a concept where switching rooms is no longer done, but the sight is moving so that the player avatar is more or less centered on the screen every time, and portions of the level (e.g. formerly other rooms) scroll in synchronous to the movement.

 

First issue may be that you deprive yourself of going into the 3rd dimension. An explicit exit may not only lead up, down, left, or right, but also backwards and forwards, and it allows to use an elevator or stairs in the backdrop (I remember such a feature in this kind of games).

 

Second issue is that, although you don't need exits from room to room in a level if you simply follow the concept "one room one level", you still have to model the transit from one level to the next.

 

Now coming to the question of how to store the data.

 

First of, notice that the data format in the editor and the data format in the game need not be identical. If you think about the different requirements in those use cases, you probably see that a structure suitable for the one case is not so suitable in the other. In the editor, you want to check whether a place is covered, move tiles around, check for validity / playability, and so on. During gameplay you are interested in whether movement in a direction is possible, a trigger must be fired, and so on. This means that the editor need to either distinguish between saving a project from saving a game level, or it needs to interpret the data in another way than the game engine.

 

Second, you have to decide whether you want to use blobs or regular structures. In the former case you load the level data and that's it. This is called "in-place loading". It shortens load time (okay, not to do much in that kind of game anyhow) since preparation is already done by the editor before saving, but it may require a more sophisticated addressing scheme. The latter case (regular structures) means to load data into a buffer, and building a new structure from it during interpreting the data. For example, you make a std::map (when using C++) from it, where the key in the map is given by the tile index.

 

Third, you have to think on the density of the map: How many holes may be there (i.e. where no tile is placed simply because the player cannot reach that tiles anyway)? A full grid makes sense mainly if holes are rare and small. For a sparsely covered map a linking scheme would be more efficient.

 

In a game like shown probably neither load time nor memory footprint are hard conditions, so probably any way will work. My personal preference is to "compile" editor data into game data, and to use in-place loadable blobs for game data.

 


... a way on doing this without changing how the old level works ...

What features exactly you want to preserve?




#5175193 Storing level data in grids

Posted by haegarr on 21 August 2014 - 01:59 AM

Explicitly modelled exits (and perhaps also entrees) grants a much greater flexibility:

1.) They allow the rooms to be stored in sequence in any order, since the rooms are linked.

2.) They allow also for not having an exit on a particular side.

3.) They allow to have more than a single exit on a particular side.

4.) They simply support for varying room forms and sizes.

5.) They give you a natural place where door locking happens.

6.) They give you a natural place for "look at exit" belonging data (if your game allows for that).

7.) They give you a place where specific onExit and onEnter handlers can be placed.

 

They allow for some spurious behavior, too:

8.) Conditional re-linking allows magic passages or adaptable mazes.

9.) Random choose from a set of entrees attached to a specific exit allows for spurious room sequels.

 

That said, I would not drop the mechanism of explicit exits / entrees without a good reason. However, you don't gave any detail in your opening post, so I may not aware of such good reasons you may have.




#5174945 Does a red and white RCA plug to 3.5mm keep stereo or does it go to mono?

Posted by haegarr on 20 August 2014 - 01:59 AM

You need both the white and the red plugs to be connected to get a stereo signal. If you connect only one you don't get the mono signal but just the left or right signal alone (a correct mono signal would be another mix of left and right signals).

 

Because such low frequencies as are emitted by subwoofers cannot be spatially located by humans, a subwoofers is not supplied with a stereo signal. However, a subwoofer is usually supplied with a signal preprocessed especially for it. I do not expect that plugging in a half stereo signal would do at all, regardless of potential signal level probelms and such.




#5174705 Weapon statistics visualization

Posted by haegarr on 19 August 2014 - 06:28 AM


I'm...not sure i see where you are going with this.

I'm just looking for an alternative way...

 

The background fact is: The player, using a given weapon, needs N seconds in average to destroy an enemy. Here N depends on the fire rate, momentum, and probability of hitting the (same) target. You don't want to express those values as numbers.

 

Although two weapons may show the nearly the same value for N, they may be differently effective because of the situation. A distant enemy may be shot with a sniper rifle which has a low fire rate but high precision. Due to the distance the player has enough time, and s/he doesn't waste ammo because the spread is low. So that weapon is fine for the situation of a distant enemy, and hence it may be memorized as such.

 

The other weapon is a machine gun, showing a much higher fire rate but also a much higher spread. Using it against a distant enemy will kill it also in N seconds (that was our condition), but at the costs of running out of ammo. So it isn't suited for this situation. However, if the situation is that the enemies approach in a throng and are relatively close, then a sniper rifle is too slow, and spreading is an advantage if each damage will slow down the hit enemy.

 

That said, I'd select the weapon based on the situation. Whether weapon A and weapon B differ just in N and 1.01*N is mostly irrelevant in a game (if it is though, like in a quartet, then perhaps using number is the best choice). So the alternative idea was to let the player test the weapons and classify them suitably for the situations the game may throw them into.




#5174682 Weapon statistics visualization

Posted by haegarr on 19 August 2014 - 05:16 AM

Don't know about your setting. I just throw some ideas around ;)

 

How does the player equip the avatar with armor? Are already pictures / representations used for this, which may be re-used for above purposes? Is it possible to introduce how hostile armor looks like during, say, a briefing?

 

Some situation dependent icons (for which also optical variations may exist):

 * A helmet for trench warfare,

 * a bulletproof vest for street fight,

 * a shield for defending a storming,

 * a metal plate for ironclad armor,

 * a crosshairs for sniping,

 * ...




#5174659 Weapon statistics visualization

Posted by haegarr on 19 August 2014 - 03:45 AM

It can be perhaps combined with training. E.g. in training with a weapon one actually learns to use it and how effective it is by shooting selected armor instead of dummies. A trainer may tell you something about the weapon, too, so that a preselection can be established.

 

During gameplay, the "statistics" may then be displayed as "effective against" with some thumbnail images of armor types. The player may also be allowed to use such an icon based system for memorizing their own preferences, e.g. a "use in case of" field can be populated with icons of armor at own decision.




#5174447 How to react on KeyPress + Release?

Posted by haegarr on 18 August 2014 - 08:25 AM

After the first run through display() both keyStates and keyPreviousState point to the same memory area. You probably want to use memcpy to copy the memory area pointed to by keyStates to the memory area pointed to by keyPreviousStates, but actually you copy the pointer keyStates to keyPreviousStates.

 

EDIT: To avoid such problems and clearly denote the situation, you should use const to make the variables read-only, in this case

bool* const keyStates = new bool[256]();
bool* const keyPreviousStates = new bool[256]();

Notice that this does not make the array elements read-only but just the pointers themselves.




#5173902 Help with Compilation Error: 0:2

Posted by haegarr on 15 August 2014 - 09:15 AM

That should not be complicated to find out using the debugger.

Seconded.

 

@OP: Here is a how-to (actually done without debugger, but using the debugger would have made investigations even easier; you should try it):

 

1.) With the hints given in above answers, you should be able to find the file within the C++ sources that is used to compile the shaders.

 

2.) If you investigate that CPP, you'll see that shader scripts are assembled into string variables. You'll see further that most of the shader scripts originates from the "content/shaders/" subfolder. Therein are 2 include files functions.si and header.si, a vertex shader pass.vs, and a fragment shader model.fs.

 

3.) Looking into the shader files, you'll see that there is a line "#version 130" which denotes the version of GLSL that the shader compiler should use.

 

4.) Looking at the error text, the keywords mentioned there are "precision" and "default qualifier", which both are missed.

 

5.) With this knowledge you visit www.opengl.org (or alternatively www.khronos.org) and navigate to the OpenGL specifications section. There you locate the GLSL specification that matches "#version 130", which you'll find as GLSLangSpec.Full.1.30.10.pdf. Download it, open it...

 

6.) ... and search for the keyword "precision". You'll find it explained in section 4.5 and especially 4.5.3 "Default Precision Qualifiers". At the end of that section you can read:

 

The vertex language has the following predeclared globally scoped default precision statements:

           precision highp float;
           precision highp int;

The fragment language has the following predeclared globally scoped default precision statement:

           precision mediump int;

The fragment language has no default precision qualifier for floating point types. Hence for float, floating point vector and matrix variable declarations, either the declaration must include a precision qualifier or the default float precision must have been previously declared. 

 

This leads to the conclusion that your fragment shader uses a float type but does not declare any precision for it.

 

7.) So ... going back to model.fs and see "yep, that's actually true".

 

8.) Correct the irregularity and try again.

 

 

Perhaps this isn't the actual solution, but anyway should demonstrate how to attack such a problem.




#5172278 Good render loop organization resources

Posted by haegarr on 08 August 2014 - 08:28 AM

The question you're asking has little to do with OpenGL itself. It is further a question with many possible answers. The following is one of them...

 

First of, there is not really a "render loop". Instead, (graphical) rendering is the very last step in the so-called game loop. Before rendering there are updates on input processing, AI, animation, physics, collision detection and correction, and perhaps others. This coarse layout of the game loop is usually understood as a sequence of so-called sub-systems. In this sense rendering is a sub-system.

 

When looking at the various sub-systems, question is how they all work. Is it possible that all of them have the same requirements? Unlikely! Instead, for different tasks during processing the game loop there are different data structures that are suitable to perform the particular tasks. This means that a data structure like the classic scene graph is probably not suitable.

 

I write this because the scene graph approach is often taught in books, and it seems me to be the case here, too. A scene graph is a single structure and looks promising on the first look, but it tends to become a nightmare the more tasks are tried to be solved with it. You asked for "high-performance", and such a scene graph does not belong to the same set of tools. This does not mean that scene graphs are bad per se; if the scene graph is used for a single purpose then it is as good as another structure.

 

Now, with respect to rendering the above thought has several implications. As can be seen from the sequence of sub-system processing, all the game objects must already be placed properly in the world, or else collision detection and correction would not have been done meaningfully. That means that "chaining of transformation matrices" is absolutely no thing of rendering at all. Instead, the process of rendering can be seen as follows:

 

1.) Iterate all objects in the scene and determine which are visible.

 

2.) For all objects that passes the visibility test above, put a rendering job into one of perhaps several lists. Here several lists may be used to a-priorily distinguish between opaque and non-opaque objects, for example. Such a rendering job should hold enough informations to later on let the low-level rendering do what it has to do.

 

2a.) Skin meshes may be computed just now, i.e. after it has been determined that they are visible.

 

3.) The lists will then be sorted by some criteria, e.g. considering the costs of resource switching (texture, mesh, shader, whatever) and, in the case of non-opaque objects, especially their order w.r.t. the camera view.

 

4.) The low-level rendering then iterates the sorted lists in given order, uses the data from each rendering job to set-up the rendering state (blending mode, binding textures, VBOs, shaders, ..., as much as needed but as less as possible) and invokes the appropriate OpenGL drawing routine.

 

You can see from the above again that OpenGL itself is not in the foreground, even we are directly discussing rendering now.

 

The question for rendering passes is the question for which kind of rendering you want to implement. Forward shading, deferred shading, ..., which kind of shadowing algorithm you want to use, and whether you want to support non-opaque objects. Besides this, each rendering pass is more or less the same as described above but obviously with different set-up and rendering states.

 

Organization of game objects can be done in various ways. However, from the above it should be clear that different aspects of game objects should be handled differently. A generally good approach is to prefer composition of game objects (instead of god classes or a wide spread inheritance tree).

 

 

Well, all this is perhaps not want to wanted to read, and I know that it is mostly vague. However, you must understand that a full fledged solution has many many aspects, and discussing them in a single post (or even thread) is not possible. This is, by the way, a reason why books tend to suggest the usage of scene graphs. It can also be understood as a hint for beginners to keep with the scene graph approach for now. In the end it's up to you to think about which way you want to go. However, decoupling things makes re-factoring easier. Decoupling is at least something you should consider.

 

Looking out for your answer ... ;)






PARTNERS