I tend to see a top-down camera as the default camera.  Therefore:

• In world coordinates, x is east-west, y is north-south, and z is up-down.
• In screen coordinates, x is left-right, y is up-down, and z is forward-back.
• In the default top-down camera, world x maps to screen x, world y maps to screen y, and world z maps to screen z.
• The camera can be moved and rotated arbitrarily, which means that usually there is no direct mapping from world coordinates to screen coordinates.

Using y for world up-down is just weird, because the up-down axis is obviously the "special" one and therefore it should not sit between the other two axes.  Likewise, using any camera orientation other than top-down as the default is just weird, because I always plan out my 3D spaces starting with a 2D top-down map.

As a reminder :

https://www.gamedev.net/forums/topic/595417-why-did-they-decide-to-point-z-up-in-quake/

And as Counter-Strike/Half-Life is based on Quake it's the same. About how to archive that, bunch of worldmatrix rotations, just look at the QuakWorld source

What’s stopping you from still using zup?

all of my games that I write in OpenGL are built on the idea that the zaxis is the up axis.

its all in the view matrix.

51 minutes ago, orange451 said:

What’s stopping you from still using zup?

 

all of my games that I write in OpenGL are built on the idea that the zaxis is the up axis.

 

its all in the view matrix.

That is true but doesn't we need to perform extra calculation to get that zup?
My theory of just rotation screen roll way did not made sense it appeared. I'm still down for getting zup if there
is a way to get it done without extra performance nor writing my own matrix library. I'm using qt.

2 hours ago, Fadey Duh said:

That is true but doesn't we need to perform extra calculation to get that zup?
My theory of just rotation screen roll way did not made sense it appeared. I'm still down for getting zup if there
is a way to get it done without extra performance nor writing my own matrix library. I'm using qt.

I'm not familiar with qt, but generally speaking, choice of coordinate system convention isn't a performance issue. At most it might lead to a couple extra math operations per frame (and it might not even require that).

As for having to write your own math code, if the framework you're using doesn't completely abstract away the underlying math, and if the math library you're using provides even the most basic matrix functionality (such as matrix multiplication and the ability to set matrix elements directly), you should be able to do it. (Getting the math right is of course a separate issue.)