Talking about coordinates systems for 2D & 3D

[define-private-public]

I originally asked about this in issue #13, but can we talk about this a little more and leave some documentation around?

So as of right now I see that there is a 2D & 3D mode. Signified by the begin2d() and begin3d() procs. What are their respective coordinate systems?

I can understand if we want to use the flipped (x-axis) Cartesian graph (where (0, 0) is in the top left of the screen) for 2D drawing. As it is a very well known system. I think this is good for things like HUDs, GUIs, and other whatnot. Or if anyone is only comfortable making a game using that coordinate system, though I think that should be discouraged.

But when talking about sprites, static textures, and other things, I think they should be freely movable in a 3D space, where (0, 0) is at the center of the screen and we're using a standard Cartesian graph. We can toggle on/off an orthogonal camera. Are we looking down Z+ or Z- by default?

We also need to talk about origin points as well.

And since I posted this question earlier Here is that original question about sprite origins posted for reference:

I added a new question: What should we consider the origin of the sprite to be? I'm not talking about the origin within the .zsprite file format, that's already done. I'm talking about when it comes to rendering.

I know that traditionally in 2D games we used a Cartesian graph that was flipped along the X axis, with (0, 0) being the top left of the screen, and (0, 0) being origin of the sprite (which was also in the top left). But we're working in 3D, and that's where our sprites live.

I'd like to propose that we should use a normal Cartesian graph, with (0, 0) being in the center of the screen. As for the sprite, the origin of the sprite should be the absolute center. This might get slightly tricky when we have to deal with an animated sprite who's frames are non all of the same dimension, but I think this is the best solution.

Should all 3D objects obey this rule where there origin (unless otherwise noted) is at their geometric center? This includes sprites and static textures.

E.g. If I render a static texture at (0, 0). In 2D mode it's origin will be at (0, 0) and be put in the top left of the screen. But in 3D mode, it will place that texture smack dab in the center of the screen.

[define-private-public]

With this, I also don't think having a Camera and Camera2D objects. It can be confusing. It would be better to keep one Camera and then lock it into a 2D view.

[define-private-public]

I'd probably have to go back and updated the default origin for ZSprite frames to be at the center isntead of (0, 0) then. (And I'd have to update the sample "Blau Gesit," as well). I don't think that would be too difficult to fixup. I do want a decision on this soon.

[zacharycarter]

Sorry for not responding earlier. I went camping for the the long weekend and was too exhausted yesterday to do any coding.

I originally asked about this in issue #13, but can we talk about this a little more and leave some documentation around?

So as of right now I see that there is a 2D & 3D mode. Signified by the begin2d() and begin3d() procs. What are their respective coordinate systems?

I can understand if we want to use the flipped (x-axis) Cartesian graph (where (0, 0) is in the top left of the screen) for 2D drawing. As it is a very well known system. I think this is good for things like HUDs, GUIs, and other whatnot. Or if anyone is only comfortable making a game using that coordinate system, though I think that should be discouraged.

But when talking about sprites, static textures, and other things, I think they should be freely movable in a 3D space, where (0, 0) is at the center of the screen and we're using a standard Cartesian graph. We can toggle on/off an orthogonal camera. Are we looking down Z+ or Z- by default?

Your assumptions basically nailed how they work presently. 2d mode uses a left handed coordinate system with 0, 0 is the top left of the screen. By default we are looking down negative Z, so positive Z is coming out of your screen.

Now there is nothing stopping a user from using begin3dMode and then using textures / sprites etc at least in my opinion there shouldn't be. I believe this is how we'll have to accomplish billboarding etc...

Does that make sense?

To your point on the camera, I read your other suggestion about merging them and we could and then just have separate modes - Orthogonal | Perspective. I'll mark this as an issue and move it to the top along with the timer module in terms of priority.

[define-private-public]

Yeah that sounds good. When this is done I'll write up a small doc and a drawing or to to explain the two different systems.

Also, is there a proc yet to draw a texture (easily) in a 3D space? I haven't checked yet.

[zacharycarter]

Umm I'm not sure if there is but I'll cook up an example of drawing textures in 3d space.

[define-private-public]

Can you formalize a doc somewhere that explains the coordinate system? It doesn't really make sense to have this ticket lying around.