Brother Bob

Actually, now when I think about it, your algorithm is much worse than that. Since you only encrypt a byte at a time, and the sequence of random numbers is fully known, you effectively only have a 8-bit XOR cipher. Not only is brute force viable, but even manual brute force BY HAND is viable since you effectively only have an 8-bit key and thus 256 combinations to manually examine.

The strength of an encryption algorithm is not how noisy the image is, but how hard it is to reverse the process without knowing the key.

If you have a 32-bit seed, you only have 2³² different possible random number sequences to evaluate. If you know or assume, for example, that the image is a sprite sheet with black background, you can just decrypt the first few pixels and see if they are all black. If they are, you can assume you have found a key that can decrypt the whole image and proceed to decrypt the entire image.

Sounds like an extremely weak cryptographic algorithm if you can make just a tiny assumption about the data it contains.

Keep two lists, one for turn order as played by the game, and one for the turn order as displayed to the user. The displayed turn order can be calculated to any length given the game turn order, and can be recalculated at any time an initiative changes.

Why do you need to keep track of the turn order for multiple turns ahead? If the initiative of a unit doesn't change dynamically, then the turn order to infinity is perfectly predictable given a unit's next move. However, if the initiative change dynamically (for example; special item to boost initiative by X for Y rounds), then it would be a bad idea to store multiple moves ahead to begin with.

My initial idea: Store all units and their next move in a priority queue sorted by the time for the next move. Items will be popped in order of the time of next move. When you pop a unit from the queue at time T, put it back into the priority queue again with time T+20-initiative. You can find out the complete sequence of times to move a unit by adding multiples of 20-initiative to the unit's time.

The old API had several types of textures for different meanings of the same single-channel data. You had GL_ALPHA for alpha only channels, GL_LUMINANCE grey scale with unit alpha channel, and GL_INTENSITY for grey scale and alpha. Since you couldn't program the pipeline with the same flexibility as before, you had to give meaning to the texture data to ensure that reading a single channel texture would populate the four color channels with the proper data. For example, a GL_LUMINANCE texture value of L would generate the RGBA color value (L, L, L, 1), but you had to use an different texture format if you instead wanted the RGBA color value (L, L, L, L) (note the difference; 1 or L for the alpha channel).

With today's flexible programmable pipeline, you have no longer the need to tell OpenGL your intended use of the texture data. You just expand the channels as you like with the swizzle operator. OpenGL no longer has to know about your intent with the texture, only your shader has to.

There is no reason any more to have three different formats for the same single-channel texture. Just do whatever you want with the single channel in your shader.

The chance of GL_RED being deprecated is zero, until the entire API fundamentally changes again as it did with 3.0 and the core profile. GL_RED is the way to specify a single channel texture, just like GL_RG, GL_RGB and GL_RGBA are the ways to specify a 2, 3 and 4 channel texture, respectively.

Use the GL_RED format for single channel textures.

Depending on how comfortable you are with undefined behavior and implementation details, you can in fact sort the bit representation of IEEE floating point values as integers. As long as the integers are positive and finite, I believe that, for floating point values A and B, if A<B, then reinterpret_cast<int &>(A)<reinterpret_cast<int &>(B). So bit representation of a float can be used as a sort key for floating point sorting.

Negative numbers, however, will be sorted in reverse order and either less than or greater than the positive values, depending on whether you treat the bits as signed or unsigned integers. Also note that positive and negative zeros, although comparing equal as floating point values, will be sorted differently as integers.

I assumed your code had the correct parameters for the callback, but apparently it takes two parameters; the key and the state of the key. Just change the wrapper callback to

static bool keyWrapper(int key, int action);

and adjust the rest of the code accordingly.

First, to register the callback you need to make the function either a static member function, or a non-member function. Let's make it a static member:

class Camera {
    ...
    bool onKeyboard(int);
 
    static bool keyWrapper(int);
};

The static member needs to wrap the static member or non-member function call to a member function call with some instance of the camera class. Let's assume you have a global pointer to your camera. The wrapper function calls the keyboard handler on the global instance of the camera:

Camera *cameraInstance = nullptr;
 
bool Camera::keyWrapper(int key)
{
    return cameraInstance->onKeyboard(key);
}

Then set the camera pointer to your camera object and register the wrapper function.

Camera myCamera = ...;
ameraInstance = &myCamera;
 
glfwSetKeyCallback(Camera::keyWrapper);

Since GLFW doesn't handle member functions, you need to wrap the member function call in a static or non-member function call, and handle the object from the outside.

Clear the old bits before OR:ing in the new value.

m_sortKey = (m_sortKey & ~0x0001FFFC00000000) | (id << 34);

Drop the size from the index equation. Pointer arithmetics already takes the size of its type into account.

Where is there a bug?

The size is fixed to 10 entries.

Pointless? I am sorting the scores so they are listed highest to lowest.


Please point out the bug specifically.

Trienco already stated what exactly the bug is. If the played didn't made it into the high score list, then you don't add it. But then you proceed to sort and delete the last item anyway.

Basically, your code adds a new entry to the list if and only if some condition is met, but unconditionally removes one. The net effect is that you may add an element but always removes one. If the condition to add the element is not met, the size of the list shrinks by one entry and you no longer have your 10 highest scores.

One easy way has already been proposed; add the new score, sort the list, and remove the last one. If the new score didn't make it into the top 10, then it will be the 11:th entry and will be removed. You don't need to figure out if or where to insert it.

It's all about precision as a function of zNear to zFar, not so much about a specific zNear -- if zFar is short, you can get away with a smaller zNear than if you had a zFar that is a greater distance away.

 

Although it's written in OpenGL terms, this pageexplains what's going on, and has a calculator that you can play with to explore how different zNear/zFar combinations affect precision.

The ratio of the near and the far plane matters when you chose the scale of the scene based on your clip planes. But I'd say you more often chose your clip planes based on the scale of your scene, and then the far clip plane is pretty much irrelevant.

Go to the link you posted and set Z distance to, say, 10 and see how the precision at that depth is affected by the values of the near and far clip planes. If you start with, for example, znear=1 and zfar=1000, you will see the precision at Z=10. Increase the far plane and you will see that it has almost no effect on the precision of your scene at the depth you are interested in. You can push it all the way to infinity without changing the precision at Z=10 by any significant amount.

Changing the near clip plane, on the other hand, significantly changes the precision at Z=10.

If you have a predefined scale because you have your models made already, then you often don't have to bother with the far clip plane; just push it out as far as necessary, but be sure you push the near clip plane as far out as you can possibly accept because that alone is what determines your effective precision at the scale you have already designed your scene.

I believe it would be like this.

int (x::*mypointer)[10] = &x::arr;

x xObj;
int *p = xObj.arr;