View Full Version : mouse.c tutorial unencouragingly bugged

07-29-2016, 11:15 AM
this material is here

third example down, mouse.c

and mirrored at several opengl 1.1 sites around the web.

i've already written my own software rendering engine and only want to use opengl 1.1 for acceleration, faster rotations and more triangles. (and of course, compatibility with microsoft!) of course, "being in my own way" already makes it difficult to relearn opengl's way.

the few surviving 1.1 tutorials i can find make me wade through the basics of 3d rendering, which is frustrating because "they do it wrong" (eg. not like me - i don't know how anyone thinks an example with (0,0,0) at the top left of the frustrum is in any way encouraging, it should always be in the center - making the center (.5,.5,0) instead makes a logical student feel let down).

i've been looking for documentation expressing the most pithy information, only the parts someone with my knowledge needs.

mouse.c is "pretty minimal" (thankfully!) and presents enough information for me to put the rendering command where i want in my code.

it displays a pyramid and is moved, rotated by the mouse.

the problem is, when you zoom the pyramid back a bit, it starts drawing the faces wrong. see attached for example.

this is really, really unencouraging. it makes the one "useful" document i found, totally useless.

i know this is over a decade back, and most people will say "get your act together, it's 2016 and no one cares about 1.1" (except microsoft) - i'm trying to adapt "so i can add my own unique voice to the cultural discussion" instead of sticking with my own engine which is limited to about 400 triangles per frame. it's really tough to try and adapt when "the convention" does stupid things like specifying an origin that isn't in the center!

maybe the best way to respond, is to suggest a tutorial or something, for someone who already knows about 3d rendering, and just wants the simplest, most minimal information. please :)

i'm one of those special, brilliant people that, for the most part, thrives when proceeding in my own manner. if i just want to draw triangles quickly, i do not want to learn extra libraries like glut, i only want the minimal install. i wonder how so many programmers want lavish libraries instead of minimal, fast, self sourcing creativity!

07-30-2016, 09:06 AM
i guess some explanation (fix?!) for this issue would help me get a handhold.

the further away the pyramid is, the larger the artifacts/errors are. it's really terrible.

i use painter's algorithm, so one depth value per triangle, in my own rendering engine, and at least it draws sides in the right order!

why can't the most popular demos for the most popular graphics api accomplish this much, for beginners??

07-31-2016, 01:18 AM
i use painter's algorithm, so one depth value per triangle, in my own rendering engine, and at least it draws sides in the right order!

that explains everything
try to draw 3 triangles: https://www.opengl.org/wiki/Transparency_Sorting#Standard_translucent
1st lies on top of 2nd
2nd lies on top of 3rd
3rd lies on top of 1st

using "reasonable" depth buffers (1 values per pixel) the rendered picture would look "authentic"