C0lumbo

There should be nothing stopping you from receiving more than one packet per frame. So a 40fps game should not be limiting you to 40 packets per second.

The server sending 100 packets per frame sounds wrong though. It could consolidate multiple game messages into a single packet and save a lot of bandwidth and CPU. Although if you're targeting desktop hardware then this is probably not a significant issue.

To receive messages on a thread, you probably just want to have the thread receive the message and just add it into some sort of thread safe queue, so that the main thread can consume the messages at an appropriate time.

I think the dark areas on your second image might be an optical illusion. They seem to disappear if I zoom close enough. (or maybe I just haven't had enough sleep recently!).

BTW, Is there any alpha testing going on?

Edit: Try softening the edges of your particles, by either removing the alpha testing, or blurring the alpha channel and/or the colour channel that's giving the sharp edges.

My gut feeling is that this is going to be at least as good a degree as any other if you want to get into the games industry as a programmer. But I'd strongly recommend you do some games specific stuff on the side. Learning C/C++ and/or putting together a game or demo together is going to massively improve your chances.

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