Brother Bob

The reference is what makes the parameter reference the original object being passed instead of making a local copy.

bool Fmod_LoadSound(char *filename, FMOD::Sound &pSound)
{ ... }
 
FMOD::Sound sound_shoot;
Fmod_LoadSound("data/sound/_shoot.wav", sound_shoot);

The asterisk should rather be seen being a part of the type itself than acting as a reference. If you are having troubles wrapping your head around pointers, just wrap them in a typedef and treat them as any other value. Pointers are no different than, say, integers when it comes to being passed as arguments.

typedef FMOD::Sound *fmod_sound_ptr;
 
bool Fmod_LoadSound(char *filename, fmod_sound_ptr &pSound)
{ ... }
 
fmod_sound_ptr sound_shoot;
Fmod_LoadSound("data/sound/_shoot.wav", sound_shoot);

Here, you have a variable of some type, it is being passed by reference to the Fmod_LoadSound object, and you can then get a pointer to the original variable being passed by taking the address of the parameter; &pSound.

The fact that it is a pointer and not an object of some class type, or another primitive type, is not relevant. But the pointer is hidden behind a typedef to not confuse the pointer belonging to the original type and the pointer as a result of taking its address.

If you want to understand how pointers and references, and pass by pointer and pass by reference, work, then don't learn it with a type that is already a pointer. Just learn it with a regular integer, and progressively change the integer to a typedef:ed custom type, and to a pointer type, and then remove the typedef. This is essentially the core of your problem:

void foo(int v)
{
    v = 42;
}
 
int main()
{
    int v = 0;
    foo(v);
    std::cout << v;
}

Go from here, and gradually replace the integer with other types, and with typedefs, and with pointer types.

The expression &sound takes the address of the variable sound, which is a parameter to the function and is thus a local variable. If you intend for &sound to reference the sound_shoot pointer, then you need to use a reference or a pointer to the original pointer.

bool Fmod_LoadSound(char *filename, FMOD::Sound *&pSound)
{ ... }

You're passing the variable screen by value, so changes to it in the init function are only made to the local copy of it and not to the one in your main function. You need to pass it by reference (preferred), or by pointer.

bool init(SDL_Surface* &screen, std::string windowTitle)
{...}

Yes, that statement was not correct in that context and I even contradicted myself later, but it was more in the context of just replacing one with the other. Compensate properly for a specific case, and it works for that specific case: we both agree on that.

Yes, I assume that as well. But a difference in projection does not have to mean a difference in coordinates. With proper setup, he can indeed draw the same things and get the same result and that was the point of your and my reply. They are fundamentally different types of projection because you cannot blindly replace one with the other. The w and d in your code has to be calculated. That's fine, and the calculations is going to involve, in one way or another, the expressions I gave: w and d are going to depend on the FOV and the Z, and will only be valid for that particular FOV and Z. Your w and d are nothing more that compensation for the differences between orthographic and perspective projection.

He said he wanted 2D with layers, so your w and d, or my xrange and zrange, will necessarily have to be recalculated for each Z. An orthographic projection still allows layering and depth, but there's no need to recalculate anything for different depths, and the coordinate system can be directly and explicitly specified with the desired ranges. That is why I ultimately asked the question if his perspective approach is really necessary, or just based on the no-so-uncommon erroneous belief that your program cannot have multiple types of projections.