I decided I should probably update what's going on with this project, because I haven't posted in over a week but I'm not killing it.
I've been thinking about looking into and switching to a proper 3D api. On one hand I want to be in the thick of this project and obscure as little work as possible behind other people's stuff, so that the end result is entirely mine. On the other hand, I want to see how Defined Sense of Atmosphere would function as a real game, and look at problems that arise after 3D has been established. After much deliberation I have decided on the ladder. The reason is that while what the program is currently displaying is not correct, I am fairly certain my method is meaning the issues lie in stuff like NAN errors that I mentioned previously. Errors like these really don't interest me much so I feel fine leaving them be. Once I finish the current set of problems I'll run into a the problem of shape collision, not what happens when you collide with something, but what the rendering engine does when any two planes intersect. This is something else I don't really care much about because I think it can only be done with a heuristics shortcut that I don't want to take. On top of all that I have a hunch that a 3D api may not obscure as much as I think since at the end of the day, it still has to remain flexible enough for the programmer.
So 3D api it is; however, there is one last issue. I'm sure Java has a fine 3D api but why use Java? I started with Java because it was convenient but if I'm going seriously pursue a game I might just want to switch over to C++ now for the speed and better performance.
Where am I during this massive change? Nowhere. For the past 3-4 weeks I have been focusing on finishing my summer class, pixel art, and vacationing at the beach, so I've been taking a break from programming and will continue to, at least until next week. The problem is that next week, I start my fall semester, and soon afterwards, a new job. So I'll be studying, working, networking, and being a friend, all of which, kind of has to take priority over personal projects, making learning a new language, and API very difficult. Perhaps I'll just use a Java 3D api and save myself some time, promising to update to C++ later (Valve time, of course). So, I'm putting this project in an official hold until further notice.
This was not a failure. I'm very happy with what I got out of it, more exposure to a subject that I love, a huge step forward in a long standing personal goal, and a chance to show off what I'm all about on this forum.
Now for a little explanation for Ethan's problem because it's something REALLY cool that's actually been around since v0.2. This is going to be pretty long winded but I don't have any practice explaining this so I'm kinda talking myself through it and taking you along for the ride.
For anyone that has been in the same situation as Ethan you may have also thought you were inside a cube since your entire vision was obscured. However, note that moving backwards "gets you out of the cube" but moving forwards doesn't. Indeed, you have failed at interpreting the screens information and should probably be pawned by bullets. Check it out.
At the beginning you might have noticed that the area only contains cubes which are made of flat surfaces and remembered that you have the full sphere of vision. Now you run toward a cube and find yourself at Ethan's screen. Work backwards, what would the world have to look like in order for you to see what Ethan is seeing. Something that you may not have noticed is that the world consists entirely of triangles, each square face of a cube is just two triangles. So every shape in the world is bounded by 3 sides, which are defined by 3 vertices. Where are the 3 sides and vertices in the shape covering Ethan's screen? Well, you can't really tell, they are pretty flush against the edge of your vision. Alright, but at least we know that all the vertices have to be very close to that edge, so lets figure out how a vertex gets to be at that edge. Time for an experiment and stick with me on this.
Put your face up against a wall and touch the wall with your finger. Now draw an imaginary line from your eye down the vision of your eye until it hits the wall, and then draw another imaginary line from your eye to where your finger is touching the wall. What is the angle between these two lines? 30, 45, 60 degrees? Move your finger around and think about this for a second. Now move your figure as far away from your head as possible, still touching the wall. What is happening to that angle? Keep going, beyond where you can reach, and you may notice that the angle will never increase past 90 degrees but it will get infinitely close. In order for that angel to be 90 degrees your finger what you have leave the wall and move next to your eye.
Great, where am I going with all of this? Our screen has 90 degrees out from the center of our vision, conveniently already marked for us. The inner ring has been there since v0.2 and this is exactly why. What we know about the edges and vertices of the shape covering Ethan's vision is that they are farther then 90 degrees out from the center of our vision. They are behind us. If you keep thinking about it, you will realize that in order for a point to reach the edge of our vision, the angle would have to approach 180 degrees.
So imagine 3 points anywhere behind your head and draw a triangle between them. Put the points anywhere you want, so long as they are greater then 90 degrees out from the center of your vision, and you will find that the triangle formed will NEVER be in front of your eye. The only way we could truly see what Ethan is seeing is if the surface was curved within the 3 vertices which we know it isn't because everything is flat surfaces. So what's going on here? It's a rendering error, plain and simple. Ethan has stumbled upon a situation that can not possibly happen in a correct rendering.
I'll save you some trouble and tell you the condition when this error happens: the triangle needs to intersect the line created by your vision, behind your location. I'll leave figuring out why the condition is such, to you.
I'll move on to what the correct rendering should be. Look back at the screen. When drawing a shape what I really want to do is obscure every point within the bounding edges of the shape with the correct color of that shape. When we have a shape behind us what points does it bound. An easy way to figure out where I'm going is to go back to my condition and find the point when the shape intersects the line created by your vision. Where does this point render on the screen? The point will be on the line of your vision but the angle to that point will not be 0 degrees, it will be... 180 degrees. Prepare to make a huge perceptional jump. The point is the entire outer edge of your vision. In order for this method of 3D projection to work, we need to bound our vision by a point so we explode the point into a line. The correct way to render something when it is behind you (as per the condition I gave above) is to color every point that isn't with in the normal bounds of the shape.
So what does this look like. I corrected this problem but never added it to a publishable version, so here are some screenshots. However, first an explanation of coordinates. In these pictures (and when you start the program), you are looking down the z axis, from the origin. The x axis is pointing down and the y axis is pointing right. So a simple way to think of these coordinates is positive x moves something down on the screen, positive y moves something right on the screen, positive z moves something into the screen. This means that the angle out from your vision will stay below 90 degrees so long as z is above 0, the angle will be 90 degrees when z is 0, and the angle will be above 90 degrees when z is negative.
Vertices: (-2,0,2), (2,1,2), (2,-1,2). All z's are positive, all vertices are in front, shape is in front, color all points inside of shape.
Vertices: (-2,0,-2), (2,1,-2), (2,-1,-2). All z's are negative, all vertices are behind, shape is behind, color all points outside of shape.
Now for some not so simple cases. I'm going to graph (1,-2,-2), (-1,-2,-2), and a third point. z is negative so both points are behind, y is negative so both points are to your left, but they have different x's so one will appear above and one will appear below. Two new points, (0,2,3) and (0,2,1) are both in front and to the right; however, the shapes graphed with these two points render very differently.
Here is (1,-2,-2), (-1,-2,-2), (0,2,3).
Here is (1,-2,-2), (-1,-2,-2), (0,2,1).
So that's pretty much it. There is so much I'd like to show in this explanation, but I just don't have the time or the resources. If you want to get more into this stuff, PLEASE feel free to talk to me, because math and computer science are two of my passions and I love explaining what I know, but it really helps if I think someone is interested.
