openGL rant

[garote]

OPENGL RANT. BY AREK AND GROTE.

quick quiz:
how do you draw lines, points, and triangles in open gl?

• A: with triangles.

Answer: A.

points and lines are all busted and broken and worthless. quake 3 uses triangles, so they work. you want a point? use two triangles. you want a line? use two triangles.
god damn fucking shit.
so in order to draw the pretty 3 pixels wide line, i made a 5x1 TEXTURE of a line.
was re: god damn fucking shit.
then i stretch the texture over a carefully positioned pair of triangles, and nobody's the wiser.

cost: 6 hours of my life.

on the plus side, it looks slightly better than real antialiased lines, because the hardware antialiasing only uses 3 subpixel bits (at least on my radeon) while the texture filtering uses 8.
jesus tapdancing shits.

That's the 'great' thing about standards. Their growth consists of HACKS ON HACKS. this, after trying many many combinations of antialiased triangles with no texture, which all failed because GL_SRC_ALPHA_SATURATION mode is fucked up on drugs and stuff. fucking 'Generation X' GL_SRC_ALPHA_SATURATION mode.
yes, it's all totally ad hoc and busted and dependent on the lastest "extensions" to the "standard" based on "extensions" ratified by "people" who suck "cock".

i shouldn't be laughing at this point, yet i am

And this 'cock' in question is actually 'cock emulator 0.4 [final]', which was originally an extension of 'Dickgen v3.001', but splintered into it's own app when 'Dickgen' author Hal PickenPacker got killed in the Swiss Alps. It was rewritten in COBALL from the original BallSuck0.009d (which only ran on second edition VIC-20s), then bought out by ASSCO, thrown away, and replaced by a TURTLE LOGO version which only sold 4 copies. later used as the kernel of a major operating system. So the full name is

Cock (emulator 0.4 [final]) Dickgen 3.001 (CO-BALL) - BallSuck0.009d_VIC-20_2 (c) AssCO [Turtle Logo v++4] a.k.a. Dongulator OS v1.0 .

and this is what powers the Xbox! >:)

arek to ATI and nvidia: GET YOUR FUCKING SHIT TOGETHER.

ATI: "Next year. It'll cost you $500 btw"
nVidia: "You mean _your_ shit, codemonkey?"
grrrrrrrrrrr. it all works fiiiiiiiiiiiiiiiiiiiiine as long as you don't want anything complex. like antialiased points. or lines. or something bigger than a pixel.
I mean, jesus cock-stuck-in-a-bear-trap CHRIST this is only twenty years after TRON people. you can't draw a line wider than one pixel?

ATI: "huhuh huhu huh huhuhuhuh d00d i bl3w his h34d off"
nvidia: "no way! no fucking way! i fragged your ass!"

anyway i'm less than pleased about the whole thing. but it's nearly working again. just have to add a 0.5 pixel BUTT CAP onto this triangle pair.
we need new vocabularly to adequately express the frustration involved in creating workable point and line primitives.

• triangle lines = trine.
• triangle point = TRONT.

Example:

10 int BORK at BORK
20 print TRONT 34,56
50 HCOLOR = BORK
60 BORK AT 10 PRINT BORK UNDER 10 BORK IN FOR BORK 10: GOTO 10
62 HELP

mhmmmmm maybe "lingle" and "poingle" are better terms. they certainty invoke images of all the COCK SUCKERY inherent in gl.
yeah, trademarking those words now.
(giant rubber stamp noise)

KA-CHWONK

Comments

[mirabilevisu.livejournal.com]

hi

i'm embarking on all kinds of fucking mac kanowlege. what tool/application would you recommend to someone who wants to build a mac-friendly collapsable menu for a web page?

thanks!
me

[garote]

That's odd. This comment never made it into my email box. Hence the later reply. Mac-friendly collapsable menu ... I assume you're talking DHTML and Javascript controlled... not a Java or Frash app?

If you're talking about developing it on the mac, you can use GoLive or Dreamweaver (or the other Macromedia apps - Fireworks for example) just as you would on a PC, so no problem there.

If you're talking about making it mac-friendly to end users, your two big considerations are the standard issue mac browsers, Internet Explorer Mac and Safari. (Mozilla is also compiled for OS X, but is standards compliant up the ass like it's PC edition, so you can safely ignore that. Same with Netscape.) The latest editions of the two above apps (6.0 and MX, respectively) are written to consider Internet Explorer Mac in their generated code. That leaves Safari. Safari is disastrously new. If a collapsable DHTML menu works in IE and Mozilla/Netscape, but is broken in Safari ... don't worry about it. Apple will roll out an upgrade with 10,000 DHTML and CSS tweaks soon enough.

If you're talking major compliance, like making a website that works on Netscape 4 for OS 7.5 or whatnot, then you might as well forget about collapsible DHTML menus, and stick with a rollover.

P.S.: Fuck OS 7.5 . ;)

I hope this helps.

[mirabilevisu.livejournal.com]

hahahahah!

yeah, it helps. ended up using javascript. really wanted to use an applet, but i don't know dick about them - mac or pc-based. and i finally broke down and started using dreamweaver mx for hax0r1ng instead of notepad.

alas!

either way, i'm working on a pc, not a mac, but never stop dreaming, g.

-m

[garote]

Bwahahahaa!!
A "switcher" must evangelize, I guess :)

If you're trying to decide what to explore next, I say go for Frash, with Macromedia Frash and the Frash Pruggin. My brah Tony is finding it both hilarious and profitable.

slowness of open GL

[ex-samwatkin883.livejournal.com]

I tried to use Open GL a while ago to port a 2D graphics program that draws the globe from X11 to Windows. GL can only draw 3D polygons, not 2D polygons, and so it has to do lots of complex math to triangulate those 3D polygons so it can draw them. The result is that my program ran at about the same speed on my father's ~2GHz Windows box with (presumably hardware accelerated) GL as it did on my ~500MHz Linux box with X11 and no hardware acceleration. Suckage.

You'd think that a graphics library should start from simple things, such as 2D primitives (points, lines, polygons) and build up to complex things, such as 3D.

I don't think I'll be using Open GL again.

Re: slowness of open GL

[(Anonymous)]

Just curious:

You did use an orthographic projection combined with glVertex2d/f/i/whatever, right?

GL did start life as a 2D package that was extended into 3D. However, it is now primarily used for 3D, so most of the stuff you see will use the 3D portion. But don't assume that that is the only way it can be used. Check out Blender, whose entire user interface is entirely drawn (including themes) in OpenGL.

Re: slowness of open GL

[ex-samwatkin883.livejournal.com]

I used gluOrtho2D for the projection, and gluTessBeginPolygon, etc, to fill the polygons. I cannot see any other way to draw complex 2d polygons (coastlines) in GL. But the "Tess" functions are very inefficient for this purpose, as they are designed to break 3d polygons up into triangles.

Maybe I missed something, if so please enlighten me!

I suppose it is slow because the "glu" utility functions are not implemented in hardware.

Re: slowness of open GL

[garote]

Long after this rant, Arek implemented this. It may be of some interest to you.

line width

[(Anonymous)]

I will assume that you have tried glLineWidth (after checking for allowable antialiased line widths by using glGetFloatv() with GL_ALIASED_LINE_WIDTH_RANGE). I do this because I choose to believe that you are having actual problems with OpenGL implementations, rather than failing to RTFM.

If you are having implementation problems, I would also ask if you have run your tests on nVidia. I know you have complained about them, but they are considered a highly compliant implementation, whereas ATI is known (and has always been known) for pretty much crappy, buggy, incomplete implementations of APIs (from VGA through VESA until OpenGL and DirectX). They're fine for gamers, but you see a LOT more "fixed this bug that was affecting ATI cards" than you see of any other graphic card related bug fixes. And most of them aren't truly bugs, but just a failure of ATI that the poor developer has had to work around because ATI won't fix it.

If the problem is truly one of failing to RTFM, I would strongly suggest that you get the Red Book ("OpenGL Programming Guide Fourth Edition -- The Official Guide to Learning OpenGL, Version 1.4"). It does a good job of also covering the 2D aspects of OpenGL. Once you've been through the Programming Guide and gotten your bearings, the "OpenGL Reference Manual Third Edition -- The Official Reference Document to OpenGL, Version 1.2" is also handy (although I'm hoping they update it as well -- it is WAY out of date for the extensions). The OpenGL SuperBible has also recently had a new edition, and has some handy stuff, but it's mostly 3D.

Re: line width

[garote]

Long after this rant, Arek implemented this. It may be of some interest to you.

[garote]

In retrospect, I am amused to note that 4 years after this somewhat snide comment was made, Arek knew more about OpenGL than many of ATI/Nvidia's own programmers, and I was a lead developer on a software system that needed documentation and our department actually borrowed one of the original authors of the Red Book from a neighboring department to write it.