C0lumbo

Aside from actually rendering it, then reading it back with glReadPixels or something, no. There's no simple method for simulating even very basic texture sampling functionality on the CPU in OpenGLES.

I would just use a texture lookup, i.e. don't even bother providing colours for your vertices, just provide UV coordinates into a texture containing the colours you want with the colour steps you want.

 

If you didn't actually want the colour to step like the second image in the original post, then an alternative might be to convert your RGB values into HSV values in the vertex shader. They'll then interpolate through the hues, and you can convert back in your pixel shader. I suspect the texture approach is more straightforward.

I guess most of the solutions you're likely to come across are intended to solve different problems. When you have one surface roughly coplanar to another surface but you want one surface always on top (typically decals or shadows), then that is when to use z bias, z offsets or modified projection matrices, etc.

For you, the situation is different, you want your water plane to intersect your land geometry, just with a bit more precision. I can think of a couple of things you could try:

1. You might be able to modify your projection matrix near and far planes to increase your effective Z-resolution. Moving the near plane forward can be particularly effective, especially if it's currently very close to zero.
2. Could you modify your land geometry/height map so that it doesn't end up near zero for too long? e.g. If (vert.y > 0.0f) vert.y += 0.1f else vert.y -= 0.1f
3. You could try a user clip plane when you render your land geometry instead of using the z-buffer. Not sure if that'd give you more precision or not, tbh, but maybe worth a try if you're running out of ideas.

One option is to use fixed point integers. That is, your integers (presumably) have 32 bits, decide on how many of them should be fractional (I use 12 fractional bits for my fixed point numbers).

 

It can take a while to get to grips with, you need to be comfortable with bit-shifting, and you'll need to find or write a decent library to manipulate fixed point numbers as there's no built in support, but it's a good solution in certain circumstances. I'm using them at the moment because I have plans to add lock-step multiplayer to my RTS and I don't want to have to worry about floating point inconsistencies across different compilers, processors, optimisation settings, etc.

I do think the software approach will beat the vertex shader approach, so you should probably go ahead and give that a shot.

But - I think you should be able to manage more than 16 cubes per batch. Firstly, you don't need a full 4x4 matrix - you can switch to 4x3 matrices and implicitly assume that the last row is 0, 0, 0, 1. You might need to transpose your matrices to achieve this.

Also, I don't think you need two arrays of matrices. I assume one of the matrices is for your normals, and one for the positions. But you can usually use the same matrix for your positions and your normals and simply ignore the position for the normals.

So, by my reckoning you should be able to manage 128/3=42 cubes each batch. Your GLSL code might end up looking a bit like this (untested, not compiled):

uniform float4 g_vMatrices[42*3];

...

vWorldPos.x = dot(g_vMatrices[iCubeIndexAttribute*3], float4(vPositionAttribute, 1.0));
vWorldPos.y = dot(g_vMatrices[iCubeIndexAttribute*3+1], float4(vPositionAttribute, 1.0));
vWorldPos.z = dot(g_vMatrices[iCubeIndexAttribute*3+2], float4(vPositionAttribute, 1.0));
vWorldNormal.x = dot(g_vMatrices[iCubeIndexAttribute*3], float4(vNormalAttribute, 0.0));
vWorldNormal.y = dot(g_vMatrices[iCubeIndexAttribute*3+1], float4(vNormalAttribute, 0.0));
vWorldNormal.z = dot(g_vMatrices[iCubeIndexAttribute*3+2], float4(vNormalAttribute, 0.0));


Oops - just realised you'd then need to transform the positions by the viewproj matrix which will take up a few more uniforms, so you'll end up with only 41 cubes per batch.

This form of transparency is known as colour key. You could find some answers perhaps by googling "opengl colour key".

As an approach, it's very much out of favour and is a bit awkward on modern graphics pipelines. Basically, your options are to hack something into your pixel shader to detect and reject pixels with the magenta colour, or to preprocess your texture (either offline, or as you load it) to add an alpha channel to your texture (an alpha channel is a fourth colour channel which is often used for transparency). I'd recommend adding the alpha channel.

Perlin noise is often very useful for generating levels, although there isn't enough detail of the problem to know whether it's applicable to you. Regardless, it's worth learning about if you're doing randomised procedural generation of pretty much anything.

Ordinarily, I'd expect you to just upload a whole new array of bones and have a separate draw call for each mesh.

Your vertex shader would only need to know a mesh ID if you're specifically trying to implement instanced rendering for hardware skinned objects, which is a perfectly viable thing to try and achieve, but is a bit exotic and perhaps not a 'for beginners' topic. In DirectX I suppose you could use SetStreamSourceFreq to get per vertex data into your vertex shader without having to duplicate it into each and every vertex, In OpenGL you might be looking at using something like http://www.opengl.org/registry/specs/ARB/instanced_arrays.txt or http://www.opengl.org/registry/specs/ARB/draw_instanced.txt, availability of these will depend on your OpenGL version and implementation. The simpler approach would be to just create multiple copies of your mesh in your vertex buffer, incrementing the per-vertex mesh ID for each one.

For skinning, yes, the approach of having a vertex attribute for the bone index is pretty standard. For smooth skinning, most implementations allow for a vertex to be associated with up to 4 bones, so there's often up to four integers which are indices into your bone matrix uniforms and four floats which are the weights for each of those bones.

In DirectX you can squeeze the 4 bone indices into four bytes (assuming your bone count is <= 255). I would be surprised if that's not also possible in OpenGL.

In some cases it can be worth having different versions of your vertex shader for different numbers of weighting, so that you use a simpler shader in the event that each vertex is associated with fewer than 4 bones.

The normal way of doing this would be to get rid of your meshID vertex attribute and use a single vec3 for the position vector (often a world matrix would be used instead of a position vector). Your vertex shader would never need to know which mesh it is rendering, you'd simply upload a different value into your position vec3 before you render each mesh.

The only reason I can think of for using a meshID which looks up into an array of position uniforms would be if you were trying to achieve instance rendering. The goal of instance rendering is to draw multiple meshes with a single draw call to improve performance. It sounds like you're not trying to do this, but you're maybe basing your code on a sample that did do instance rendering.

The problem is that an engine that hasn't been used in a finished game is not 90% finished. Until it has been through that cycle of bug fixing and being tested on multiple hardware, etc, there is still a lot of work to be done.

I can't imagine any games studio seriously considering using an engine that hasn't been proven in some way. Also, the engine runtime is only a part of the equation when a studio evaluates tech - the tools and art pipeline are at least as important, as is decent support from someone who knows the engine well and ideally a strong community of other users. It sounds like none of these things are in place.

Oh - and if 8 years of professional experience programming in games is insufficient for someone to get grips with the engine, then there's something seriously wrong with the engine.

Peter Molyneux obviously thinks there's still life in the god game genre http://www.kickstarter.com/projects/22cans/project-godus and >11,000 backers are willing to put money towards seeing it get made, although Project Godus looks more Populous than B+W. I'm also trying to do a god game atm, although my plan is a bit of a cross between Civilisation, Populous and a few other influences. There's also http://www.kickstarter.com/projects/simonroth/maia?ref=live which is a bit of a sci-fi take on the god game genre.

I think the genre is an under-served niche, which makes it a good target for a low budget indie title.

Personally I found the creature from B+W annoying. I was God but I had to micro manage this stupid idiot who never did what I wanted or expected, kind-of took away that all important sense of power for me.

And even though you sound aware that it'll be a gigantic task to make one, don't forget Hofstadter's law:

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

I still get confused by pointers.

Does the source code snippet create a constant of datatype char* and name it pGameMap[]? if so how can I assign a string to a char* type? That is overly complex for me to conceptualize without a little breakdown.

It's a little complicated to explain exactly what that code is doing. Essentially, each line of "XXXOOOXXX" becomes a NULL terminated string and pGameMap is an array of pointers that point to those strings, I used [] instead of specifying a size of the array so that the compiler can infer the number of strings by the number of entries. C Strings are simply an array of char (8 bit numbers) where a value of 0 indicates the end.

In terms of you using it, your sample code would become:

[source lang="cpp"]//assuming you are going up.//translates well into all 4 directions. if(pGameMap[cury-1][curx]=='O') {     cury-=1;}else {//collision sound}[/source]
Other things to watch out for are that you would not be allowed to modify pGameMap at runtime which might be an issue if you want a dynamic world (you could copy the data from pGameMap and modify that though). Also I'd recommend throwing a few asserts into your code to make sure all the strings are the same length and that there's a safe border of X around the edge of the map.

That'll work. For the sake of your sanity, if you plan on doing large maps, then it might be worth plugging in code so you can load in your index array from a .bmp or something. Failing that, at the very least you could create your map from a string, so you could use the XOOOOXXOOO style notation. Something like:

[source lang="cpp"]const char *pGameMap[] = {    "XXXXXOOOOOXXXXX",    "XXXXOOOOOOOXXXX",};[/source]

You could convert that into a bool array, or just do your tests directly on the string seeing as a char is no bigger than a bool.

I agree that you probably just need to multiply S and R the other way around.

Personally, I don't think non-uniform scaling for objects is so bad. The main gotcha is that for correct lighting you need to use a different matrix for your normals than for your vertices - instead of just lopping off the translation part of the matrix, you need to calculate the inverse transpose. If you're using fixed function, then I believe this is handled automatically, but if you're using shaders then they may well be implicitly assuming uniform scaling.