ok... know that uses very math... but is there any tutorial for i create my 1st shooter game?
- how draw the images(position, size and angle);
- how create the camera and the move?
is there any tutorial for i start?
without using directx or opengl or other library
even if you do not use a graphics library, you will have to use a library to talk to the graphics card driver itself.
I suppose you could write your own driver too, but that would require a lot of knowledge about your graphics card, and a modern graphics card is about 1/5th of a step down from being a full computer itself.
If you want to go this route, maybe see what you can do using only something like bitblt from the library, which just dumps a 2-d pixel array to the hardware. You could then try to make 3-d mapped to 2d frames in your code etc. Start there. If you can get that going, then you may consider trying to get to the card itself.
This kind of thing is going to be overwhelming for a single person to do from scratch.
it may still be possible to kick cards in to like VGA mode and dump directly to them at some resolutions. You can also look at those ideas, but this is backwards compatibility ancient junk that the hardware supports, not the way of doing things. But at least you would directly talk to the card that way...
the calculations are well known and not difficult (to code, they are a little complex to get your head around at first). You can look them up. Some stuff is like that: I coded up a quaternion library for a flight sim in < 2 days, and it took me a month or 2 before I really felt comfortable using the things. Nothing to give you an ulcer like coding up math you don't understand from a wiki page!
you want the graphics card itself to do some of the math for speed, and that is where talking to the card will begin to get rough. Just dumping pixels on it, that may be relatively simple: bios can do it when you boot up...
there are other things you will want. you may need quaternions. you will need rotation and translation matrix. You will need normal and image onto a surface texture mapping. There will be lots of individual pieces, but again, its all well known.
yes, z is normally the forward to back axis in standard math coordinate systems (which you will find that many graphics libraries do not use for various reasons).
You can define any coordinate system you want, and many packages actually do that, could be a math efficiency, I don't really know why they do weird stuff.
the screen does not have z but you are mapping 3d to 2-d. You have to be aware of the z to get it in the right 2-d location. To put it another way, look at a real life photograph of something. You can tell what is in front of something else: its a 2-d map of the real 3-d world but you can see what it represents pretty well as to relative positioning etc. Or if I put 2 people on a football field one at the 10 yard line and one at the 50. You can tell that one is way behind the other due to relative size, same as you can block out the moon with your hand at arm's length from the earth but not so much if you were about to land on it.
3D graphics is mostly linear algebra. If you want a book, Strang's Introduction to Linear Algebra, ISBN 978-09802327-7-6 has my strong recommendation. https://math.mit.edu/~gs/linearalgebra/
The book is remarkably easy-to-read for a math textbook and has a strong focus on the material in practice.
What you'll want to do is write a software renderer. A simple one can be completed in a weekend. https://en.wikipedia.org/wiki/Software_rendering
No extant software renderer can remotely compete (in performance terms) with code that uses special-purpose hardware, but it's a great learning experience.
If you are not willing or don't have the time to really dig into the mathematics, you'll be able to find lots of tutorials on the fundamental stuff behind 3d graphics.
The starting point is a way to present a single pixel to the user. You can use a multimedia library like SDL2 to do this, and leverage only its put_pixel function https://wiki.libsdl.org/SDL_RenderDrawPoint
to do all the work.
If you don't feel like writing your own mathematics code, GLM, the OpenGL Mathematics library, can provide 3- and 4-dimensional vectors (not the container) and matrices, which are fundamental to the math you'll need to do: https://glm.g-truc.net/0.9.9/index.html
for start what is really kill me is 1 thing: how can i convert X,Y,Z to X,Y?...
The point here is that objects that are farther away are smaller. Thus if z -> positive -> farther away you can determine a certain factor (for instance 0.1) which you multiply to all x/y values. If you try that you will soon see that you also want to move the object (like for start a rectangle) i.e. adding a certain value to x/y.
You see that it is not that difficult. Finding a reasonable factor isn't that easy but doable...
Might be easier to understand if someone could give a concrete example.
Let's say he wants to draw a cube at location(x=100, y=100) with a width and height of 100.
How to calculate all the 7 other points?
// Generates a really hard-to-read matrix, but a normal, standard 4x4 matrix nonetheless
glm::mat4 projectionMatrix = glm::perspective(
glm::radians(FoV), // The vertical Field of View, in radians: the amount of "zoom". Think "camera lens". Usually between 90° (extra wide) and 30° (quite zoomed in)
4.0f / 3.0f, // Aspect Ratio. Depends on the size of your window. Notice that 4/3 == 800/600 == 1280/960, sounds familiar ?
0.1f, // Near clipping plane. Keep as big as possible, or you'll get precision issues.
100.0f // Far clipping plane. Keep as little as possible.
An image is 2D... I don't see what the Z axis has to do with simply loading an image (texture).