<\/td><\/tr><\/table><\/p>\nSo at one point I had a bug in my shader where it was passing along the red, green, and blue values of the polygon, but NOT passing along the alpha value. The outcomes:<\/p>\n
- \n
- My machine: Shader just silently forced all alpha values to 1, thus rendering everything. The only hint that anything was amiss was that smoke particles weren’t fading out the way I expected.\n
- User #1: Shader silently forced all alpha values to zero, thus not rendering anything.\n
- User #2: Alpha had a random value, resulting in sprites flickering on and off randomly like strobe lights.\n
- User #3: Shader apparently used one of the given color values for the alpha channel, so the the brighter the color, the more opaque the polygon.\n<\/ol>\n
One bug, four divergent outcomes. I managed to track that one down, but I’m still getting random behavior. <\/p>\n
Part of the problem is that there are a half dozen ways to do everything, and it’s never clear which is the “right” way. We’ve got different graphics cards, different drivers, and different versions of the OpenGL shader language. New cards add new ways of doing things, which results in new stuff being added to the language, which results in situations where sometimes things are REMOVED from the language, which results in Sparta<\/acronym>. <\/p>\n
I’ve been trying to read up on the subject, but it’s hard to make any headway. The shading language has gone through a few revisions, so old example code might not compile, or it might compile with warnings, or it might compile but malfunction. Tutorials seem to begin mid-stream instead of introducing first concepts and building up. <\/p>\n
Actually, this is my biggest complaint. I really feel like the “Hello World” of vertex shaders should be a short example that simply reproduced the fixed-function pipeline (what you get when not using shaders) and is compatible with all versions of the shader language. I’ve googled around, and all I can find are non-working \/ incomplete examples, dead links, and jackasses<\/a> asking “Why would you want to do that?”<\/p>\n
Yes, there are books on the topic, but my shader program is so simple I really hate to purchase and read a friggin’ textbook just to shove some 2D quads around the screen. That’s like getting a medical degree so you can take aspirin. <\/p>\n
Basically, I’m rendering thousands of squares. For convenience, each robot has a position, a rotation, and a size. Now, I can do math to turn these values into the corners of a square, but that’s a lot of trig to give to your CPU. When we have thousands of particles and each particle has 4 corners, we end up doing a lot of sine and cosine operations to figure out where all the squares belong. <\/p>\n
This is what sprites look like if I draw boxes around them:<\/p>\n
<\/td><\/tr><\/table><\/p>\nIn my profiling, it looks like the vast majority of my time is spent generating these squares and shoveling them at the graphics hardware. It’s the only part of my program where I’ve made any effort to speed things up, and it’s still the slowest part of the game. AI and collision detection are a distant second and third. They’re so distant that it’s actually tough to tell which one is second and which one is third. The CPU usage of building sprites is so big and noisy that measuring the other two is like trying to figure out if your cell phone light is brighter than a candle when you’re standing in direct sunlight. (To be fair, my performance profiling tools are really rudimentary. I mean, my clock only has millisecond resolution, so I need to take a lot of measurements over many frames. Also, a LOT of CPU time goes unmeasured if it’s happening in things like audio-processing threads.)<\/p>\n
With a shader, we can simply hand all of that annoying and CPU-sucking math off to the graphics card. The graphics card is barely working, and the CPU has lots of stuff to worry about already. Let’s just send it a simple 1×1 rectangle along with the position, scale, and rotation values and let the hardware to the math.<\/p>\n
Imagine our CPU and graphics card are roommates. Our CPU is Alice. Alice is a healthy but underweight lady who has many jobs working as a sound engineer, musician, animator, file clerk, garbage collector, and analyst. Her roommate is AN ENTIRE FOOTBALL TEAM, who is currently unemployed except for some occasional one-man jobs that show up on the weekend. <\/p>\n
Then a new job opening appears: Moving heavy appliances. Who should take the job? Alice, or FOOTBALL TEAM? <\/p>\n
This shader is my attempt to pass the work off to FOOTBALL TEAM instead of just dumping more work on Alice, but it’s turning into a time-sucking circus of bugs and frustration. This one feature accounts for over half my bug reports for the last few builds I’ve done <\/p>\n
For the curious out there, this is the shader I’m working with:<\/p>\n
\r\n#version 120 \r\n#define TEX0\t\t\tgl_TexCoord[0]\r\n\r\nin float \t\tattrib_angle;\r\nin float \t\tattrib_scale;\r\nin vec3\t\t\tattrib_position;\r\nin vec3\t\t\tattrib_atlas;\r\n\r\nvoid main()\r\n{\r\n vec4 vert;\r\n float texture_unit;\r\n float rad;\r\n vec2 rotate;\r\n \r\n \/\/Color is pass-through.\r\n gl_FrontColor.rgba = gl_Color.rgba;\r\n \/\/Atlas pos contains the column, row, and scale of our sprite TEXTURE.\r\n texture_unit = (1.0 \/ 32.0) * attrib_atlas.z; \/\/Default grid is 32x32.\r\n TEX0.xy = (attrib_atlas.xy + gl_MultiTexCoord0.xy) * texture_unit;\r\n TEX0.y = 1-TEX0.y; \/\/Because OpenGL thinks upside-down.\r\n \/\/Finally, prepare the vertex for the frag shader\r\n vert = gl_Vertex;\r\n rad = radians (attrib_angle);\r\n rotate.x = sin (rad);\r\n rotate.y = cos (rad);\r\n vert.x = gl_Vertex.x * rotate.y - gl_Vertex.y * rotate.x;\r\n vert.y = gl_Vertex.x * rotate.x + gl_Vertex.y * rotate.y;\r\n vert.xy *= attrib_scale;\r\n vert.xyz += attrib_position;\r\n gl_Position = gl_ModelViewProjectionMatrix * vert;\r\n}\r\n<\/pre>\nSigh. 32 lines of non-branching code. It’s just some simple math. It should not be this mysterious and difficult thing. <\/p>\n
(For the curious, the bug I mentioned earlier was line 17, where it originally said:<\/p>\n
\r\n gl_FrontColor.rgb = gl_Color.rgb;\r\n<\/pre>\n
That’s pretty subtle, and I could have any number of bugs like that in my code, where undefined behavior will work fine on one machine and cause chaos on another.)<\/p>\n
On one hand, using a shader is the right thing to do, performance-wise. On the other hand, this is a massive time-sink and the project would be much further along if I wasn’t wasting so much time on it. I have no way of knowing if the next round of changes will clear things up until I send it out to my testers, and when they report visual glitches I don’t know what to make of them because it’s all random. <\/p>\n
I have features I could be writing and the playtester feedback would be much more useful if they could actually play the game. <\/p>\n
So this is a frustrating spot to be in. Do I waste more time doing it right, or cut corners and have an inefficient game that requires a lot more horsepower than it should? I’ve taken such pains to make a lightweight, trim, and efficient little program. It would kill me to ruin all of that now. It would also kill me to spend more days on this crap. <\/p>\n
I’ve actually re-written the shader this week. If it’s still wonky I’ll just disable it and re-visit this topic later in the project. <\/p>\n
EDIT: My new shader failed on the first machine. <\/p>\n
0:6(22): error: 'in' qualifier in declaration of 'attrib_angle' only valid for function parameters in GLSL 1.20<\/code><\/p>\nSo it works fine on my machine and compiles with no warnings, but is an INVALID program on another. This error is worded in such a way that indicates it shouldn’t compile OR work ANYWHERE. <\/p>\n
So that’s horrible. <\/p>\n","protected":false},"excerpt":{"rendered":"
It turns out that the most capricious, buggy, unpredictable, and mysterious part of my program is the vertex shader. This is frustrating because it’s the thing I know the least about, the thing with the least documentation, and the thing that’s hardest to debug. Of course, these are also the reasons the problem exists in […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[498],"tags":[],"class_list":["post-21424","post","type-post","status-publish","format-standard","hentry","category-good-robot"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/21424","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=21424"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/21424\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=21424"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=21424"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=21424"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}