Map Save Tech Demo

Showcase your libraries, tools and other projects that help your fellow love users.
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Map Save Tech Demo

Post by rude »

whitebear wrote:For some reason polygons in love physics need to be placed in clockwise order for them to work.
Not directly OpenGL-related. From Box2D manual: "When you build a polygon definition you must specify the number of vertices you will use. The vertices must be specified in counter-clockwise (CCW) order about the z-axis of a right-handed coordinate system."

I wonder if I reversed CW-CCW on purpose. I may have. I also faintly remember adding some convex-hull algorithm so you wouldn't have to worry about that ... which I guess didn't work too well.
User avatar
hdon
Prole
Posts: 36
Joined: Tue Mar 17, 2009 10:54 pm
Location: Pittsburgh, PA, USA
Contact:

Re: Map Save Tech Demo

Post by hdon »

whitebear wrote:For some reason polygons in love physics need to be placed in clockwise order for them to work.
Haha, somehow I completely skipped over the word "physics." :brows:

It is true, however, that OpenGL face culling is enabled, which is useless for a game engine which only has 2D graphics. Some games have combined 2D game mechanics with 3D graphics, but a lot of LÖVE people seem offended by this sort of thing.
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Map Save Tech Demo

Post by rude »

hdon wrote:It is true, however, that OpenGL face culling is enabled, which is useless for a game engine which only has 2D graphics.
My understanding is that it speeds up the program significantly, as the backface of a given quad does not have to be rendered. It doesn't matter that we just use one plane in the 3D space (z=0). The quads still have a backface.
User avatar
hdon
Prole
Posts: 36
Joined: Tue Mar 17, 2009 10:54 pm
Location: Pittsburgh, PA, USA
Contact:

Re: Map Save Tech Demo

Post by hdon »

rude wrote:
hdon wrote:It is true, however, that OpenGL face culling is enabled, which is useless for a game engine which only has 2D graphics.
My understanding is that it speeds up the program significantly, as the backface of a given quad does not have to be rendered. It doesn't matter that we just use one plane in the 3D space (z=0). The quads still have a backface.
That's not quite how it works. Quads do not have a "back face." Back-face culling is an optimization only for rendering convex three dimensional geometries.

OpenGL's rendering model is called "rasterization." Typical of this type of rendering model is wasted rendering: lots of drawing overlaps previous drawings during the same frame. For instance you might draw the walls and floor of a room, and then draw the people inside over top of those walls and floor. If you could efficiently know ahead of time what parts of the walls and floor will be covered up by the people, you would not draw them!

Many sophisticated rendering engines built on top of OpenGL, Direct3D, or other 3D rasterization APIs do have some power to make this sort of optimization, but the situations under which they can do this are quite specific, and the people in a room example I just gave isn't one of them. The inverse scenario, however, of determining which people are just around the corner so that a wall is drawn over top of them -- is quite a common optimization, because it's less expensive.

Imagine you are drawing a card or a coin. If its two sides are perfect mirror images of each other (and if it is perfectly flat,) then all of the coordinates for one side of your coin/card are identical to the coordinates for its other side, and you don't need to send both sides to the rendering pipeline, because both sides are each other. It's like you can sorta see through it such that you see a mirror image from its back side. Most models are not like this, though. Most models represent solid 3D geometries. They are not actually solid, they are just polygons approximating the visible parts of a solid shape. For instance a cube can be approximated by six squares sharing all their edges with each other.

If you do not have back-face culling, and you draw those six squares, three of them will always be completely overlapped! What a waste of rendering power! You can imagine, then, that if we could tell our rendering engine which direction our six squares were facing, it could decide which ones to render and which ones to skip! Luckily there is such a technique, and it comes from a polygon description convention. If the clockwise/counter-clockwise order of your polygons are consistent throughout your entire model, then the vertices of your polygons provide all the information the rasterizer needs to know the exact direction your polygon is facing. Without the explicit cw/ccw distinction, the best you could do is narrow down which direction the polygon is facing to two possibilities, both facing the exact opposite direction, which is demonstrated below by deliberately using the wrong cw/ccw choice for most of the renderings.

Image

Back-face culling is only useful because in a cube you know only three faces are visible at a time, and the other three are hidden. It has nothing to do with 2D graphics at all. (Maybe you could use it for "2.1D" models which would be like Paper Mario models with asymmetrical characteristics which would violate perfect mirror symmetry.)

(Yes, I did oversimplify cube rendering by assuming no perspective projection!)
User avatar
rude
Administrator
Posts: 1052
Joined: Mon Feb 04, 2008 3:58 pm
Location: Oslo, Norway

Re: Map Save Tech Demo

Post by rude »

hdon wrote:tl;dq
It will only skip rasterization if the backface is facing "us", which it never does in 2D. Thanks hdon, now you made me feel retarded. :rofl:
User avatar
whitebear
Citizen
Posts: 86
Joined: Sun Mar 15, 2009 1:50 am

Re: Map Save Tech Demo

Post by whitebear »

New version.
Quote from first post about my little help request:
whitebear wrote:Now Here is the problem I am having. As you notice the two worlds and swapping ball's home between them enables unique puzzels to be made. But after you are donem, you sadly also notice that when you save it and then load it again, All the things in you save go to green world.
Don't worry, It was not saved wrongly (yes it saves the data about the world). It loads it wrongly. I just can't seem to find reason. It's probly something I should have noticed but I don't. If you can find what is causing this. Please inform me.
Post Reply

Who is online

Users browsing this forum: Google [Bot] and 4 guests