C0lumbo

However, it sounds like deferred lighting still requires a forward renderer for transparent, reflective, or refractive objects. Is that correct? I could understand if this is the case for transparent objects, but not for reflective/refractive objects since you could just render the scene to a cube map with deferred lighting applied to it. Also, if I'm wrong and reflection and refraction is possible, then why not just make all transparent objects refractive with a refraction index of 1? Sure, cube maps can be expensive, but then again, everything is at least a little refractive. It could us to abuse refraction and reflection more since the maps are updated anyway.

Now, here's the biggest problem I face: all of these are pretty tough on mobile hardware. MRTs won't be an option on mobile hardware until Open GL ES 3.0-compliant devices are mainstream since Tegra 3's the only hardware I know of that support it as an extension... My shaders for mobile allow you to have up to 1 of each light enabled: global (directional), point, and spot light, but that's quite a bit too. Would supporting light maps be the best way to go for mobile devices?

The reason transparent objects are usually done with forward rendering is because you have to render in a specific order. If you just rendered using your reflection cube map, then you wouldn't be able to have multiple layers of transparency. Also using a cube map for transparency would probably create artifacts because reflection cube maps are usually lower resolution.

I think that if you're targeting current mobile hardware then deferred lighting is not really that wise a choice. If you're playing a long game, or you're just playing with it then maybe that's OK, but fill rate is so restricted on many mobile chipsets and MRT support so limited that I'd advise against it. There's an article on light prepass rendering which is probably more viable than full deferred on mobile, but I think you're still going to get better results with forward rendering http://www.altdevblogaday.com/2012/03/01/light-pre-pass-renderer-on-iphone/. You mention light maps, if they're a viable approach for your project then use them as they perform very well on powervr chips.

The one you see most often from modelling tools is made by starting with an icosahedron and subdividing each triangle. As I think you're getting at, triangles aren't very good cells for a strategy game.

But, if you take your subdivided icosahedron and truncate it (http://en.wikipedia.org/wiki/Truncated_icosahedron), then you get an awesome shape sometimes known as a buckyball, which is made up of lots and lots (number depends on how subdivided the icosahedron was) of hexagons (which are great for strategy games) and 12 pentagons (which are rather inconvenient). However, if you can live with those pesky pentagons somehow, then this is a great option.

If you want square cells (or just a simple life), then as AllEightUp says, take a cube, subdivide it, then warp it into shape. When you warp your cube into a sphere, the squares become misshaped and inconsistently sized. This approach http://mathproofs.blogspot.co.uk/2005/07/mapping-cube-to-sphere.html is slighty better than the obvious approach of just normalising each vertex.

Here is how I create each particle for rendering:

                    // -------> Position, color, U, V
float fVerticalOffset = up_value_from_your_code;
vertices[i*4+0] = CUSTOM_VERTEX(p1, color, 0.0f, 0.0f + fVerticalOffset );
vertices[i*4+1] = CUSTOM_VERTEX(p2, color, 0.0f, 1.0f + fVerticalOffset );
vertices[i*4+2] = CUSTOM_VERTEX(p3, color, 1.0f, 1.0f + fVerticalOffset );
vertices[i*4+3] = CUSTOM_VERTEX(p4, color, 1.0f, 0.0f + fVerticalOffset );

How do I animate (change) the texture UV to make the texture move up/down? I tried playing around with the UV values, but I couldn't get the texture to move up/down.

Modified your code snippet to show you.

Hello Juliean

 

I have thought of that but when ive drawn the following situation i was thinking it will still give wrong results: Imagine a transparent plane A and another transparent plane B:

A
B
A
B

 

^

|

Camera

 

Now i first render the instances of A (orderd by depth) and the the same for B. Wouldnt the second A (closer to the camera) blend with the other A and not at all with the instance of B further away?

 

Greetings

Plerion

You still might be able to use a limited amount of hardware instancing in this case. For instance, if 4 'A's appeared in a row, you could render the 4 of them with a single draw call.

The other thing to look at is techniques so that you don't need to sort your objects back-to-front. In your current example, your trees are mostly on/off alpha. You don't go into details about what artifacts you're getting when you don't sort. If you have great chunks of objects missing, then you can easily improve on that with an appropriate discard/clip added to your pixel shader.

If you're worried about more subtle feathering artifacts on the edges of your leaves, then they can be trickier to deal with. It helps to render the opaque stuff first and do any coarse back-to-front sorting you can manage. You might also improve the look by fiddling with the alpha threshold you use for discard/clip but the whole thing is an awkward balancing act. This Wolfire blog post suggests an approach of drawing everything twice : http://blog.wolfire.com/2009/02/rendering-plants-with-smooth-edges/

Another approach is looking at alpha-to-coverage if you're multisampling.

The typical use case for shaders might look something like this:

Start Frame

Setup some render states

Select shaders.

Draw Call

Draw Call

Change some render states

Draw call

Change Shaders

Draw Call

etc.

End Frame

All the triangles in any given draw call are going to use the same shader. However, you can change shaders between draw calls, so in your case you can simply use a different shader for your character.

Alternatively, if you want to avoid applying an effect (in this case changing colour according to position.y) to certain triangles but for some reason you don't want to change shaders or split up a draw call, then you can differentiate the triangles somehow and add some appropriate logic to your shader. For example, you could set the vertex colour alpha of your player character's verts to zero, then use that value within your shader to disable the effect, either with an if statement, or by including the vertex alpha in your effect's equation in such a way that when vertex alpha is zero, the effect becomes disabled.

For EFIGS (English, French, German, Italian, Spanish) the ANSI range between 0-256 should suffice.

When you add more exotic languages (e.g. Japanese), then there's really two options:

1. Tie an offline font generation tool into your localisation spreadsheet so that you can generate a list of required glyphs, and output just the ones that are required, plus maybe a few extras for user input (e.g. roman alphabet, common punctuation and hiragana/katakana alphabets).

2. Generate the glyphs you need on the fly from a truetype font using a library like FreeType.

The advantage of #1 is that the performance and memory impact is more predictable, it's the approach I've always used on console/handheld games. The advantage of #2 is that it's more flexible, particularly for user input.

I'd say that if your user input is quite a small part of the game (e.g. player enters their name for multiplayer), then use approach #1 as it's probably easier to implement and easier to test. I think Chinese/Japanese games players are quite used to having restricted characters for name entry.

If text entry is central to your app (e.g. a messaging app or something), then go with option 2.

Is the class CEntity::CBullet known at the point of deletion?

That is, is CBullet.hpp included in the source code file that the function EndContact is in?

If not, and CEntity::CBullet is just forward declared (with 'class CBullet;' somewhere) then that could explain the behaviour you're seeing. Although I believe most compilers would warn you.

edit: There's a discussion about this behaviour here: http://stackoverflow.com/questions/4325154/delete-objects-of-incomplete-type

If it's a one man project (i.e. you are the coder and you're also the person who's going to be setting the values for all your items), then personally, I wouldn't bother trying to do anything fancy with spreadsheets, XML or databases. I'd just define the tables of data directly in code. I would, however, make sure that access is strictly controlled through functions so that I could later on implement loading later on if it becomes worthwhile.

The moment you go data driven, there's a moderate amount of work writing code to load in your data files and to check for errors (missing fields, etc) which you can simply skip by keeping it simple. However, if you do decide to do it properly, then all approaches are fine, but I'd probably recommend using a spreadsheet, which you can save out as a .csv file (comma separated values), and load that in code. The loading code can be fiddly, but a spreadsheet is a reasonably nice way to view and edit your data, and you might find uses for formula functionality (e.g. calculating total cost of all your items to assist with balancing your economy).

From experience on mobile platforms (GLSL ES) it is massively faster to use specialised shaders with no conditionals.

I don't have much experience on modern desktop hardware but I've heard they cope pretty well with conditionals, particularly if the conditionals can be evaluated from uniforms (as opposed to, say, vertex data or texture data).

I suspect that cubic interpolation rather than quadratic interpolation is the correct tool for this job. This website (http://freespace.virgin.net/hugo.elias/models/m_perlin.htm) describes 1D cubic interpolation in the function Cubic_Interpolate.

To extend this to 2D, I think you would need to do 4 cubic interpolations on the horizontal, then feed in those 4 results for one final cubic interpolation for the vertical.

This isn't really answering your question but might help you sidestep the problem. I find that the most portable and hassle-free way of z-biasing is to switch to a slightly different projection matrix, typically, I push the near Z out by a small amount.

I don't think OpenGL creates windows or has any functions at all relating to window management. Typically, the operating system provides the API for window creation and management and the interface between OpenGL and the window. e.g. On Mac there's the AGL functions (https://developer.apple.com/library/mac/#documentation/graphicsimaging/reference/agl_opengl/Reference/reference.html).

So I think if you want to get useful answers then you need to specify your platform, and whether you are using any sort of cross platform library which may be managing your windows for you (like SFML or SDL).

Please note that the indices of the corresponding joint vertices might still be different, so the GPU should not be able to discard triangles before the vertex processing stage, meaning that it still has to transform each vertex before finding out which triangle is degenerate.

If you have an unusual situation where this is particularly common, then you might find you're better off using a triangle list instead of a triangle strip. Triangle lists can be optimized to make better use of the post-transform cache and can end up faster than strips even on fairly strip-friendly geometry, so if you have some special case which makes your geometry strip-unfriendly then I would imagine you'll get better performance with a triangle list. I'd echo the other posters though, that in the grand scheme of things it's unlikely to make much difference.

I think the answer is that the side of the squares are (radius * root2) = 1.414213 * radius.

I suck at showing working, but the trick was to imagine the right-angled triangle made where the radius at 45-degrees is the hypotenuse, and the other two sides represent half the square edge length.

The shape you're trying to draw is not a convex polygon, so using GL_POLYGON is wrong. I think GL_TRIANGLE_STRIP is a better fit. In switching to a triangle strip you should change the 'for' condition to <=.

Also, your second glVertex2d call looks very wrong to me. It should be exactly the same as the first, but using radius2 instead of radius (or (radius + radius2) depending on what you want radius2 to mean).