Also the debug stuff is annoying. Take that out of releases maybe? or at least explain what it does.
What it does is to display one of the FBOs as a it updates- it's a very practical demonstration of what's happening in the application.
I can't emphasize this enough:
I sorta expect you programmers to sit down with the code and start building particle effects on your own with this, once I get the basics of management done, which is the last major goal.
The final code in P.U.R.E. will probably be much more specialized and therefore a lot harder to understand the derivations (a lot of the specific optimizations involve GLSL changes to remove math steps and other things to improve efficiency) so, instead of building, say, a fire sim, and then seeing several fire sim knockoffs later, because most people don't know how the general model was built, I wanted to give people the general case now, so that you can solve for anything you can imagine (and figure out an algorithmic approach to).
This is why it's so important to get the general case debugged for all hardware now, so that it's nice and clean and people who find GLSL and the heavy-duty OpenGL stuff really scary never have to mess with that, just the basic logic that drives particle creation, which is Lua (and very easy to work with, it's basically just parameters, if that's all you work with).
Basically, this program works in the following fashion:
1. You give it parameters for creating a new agent. That part will be a lot more clear and commented fully in the next release, when I (finally) hook up synced with unsynced, after doing some testing to determine what the fastest way to go about certain things will be. But basically, the objective for the synced code is to create something that, if not totally foolproof, is at least something that can feed a "black box" of OpenGL and logical operations, for people who don't ever want to look at the guts and make it do really specific stuff (or optimize it).
2. The agent's 32-bit and 8-bit pixel values are stored in textures that are created at runtime, using Frame Buffer Objects (FBOs) to pass a result from GLSL shaders. For those of you for whom 'FBO' is just an acronym, FBO just stores the current frame buffer result- OpenGL uses many frame buffer results from each operation, layer by layer, to give you a final result that looks like a picture. We're just catching an immediate part of this giant process to use in a special way. FBO is really easy to use, and goes hand-in-hand with shaders.
3. Further FBOs then read the pixel values stored, and modify them over time, again using GLSL to perform most of the math on the GPU.
4. The final shader pass then takes the modified textures and positions the point objects in world space. Because the updates in step 3 happen very rapidly, this creates the illusion of motion, like pretty much anything in 3D graphics.
Looking at the specific shaders, what happens to those pixel values, and therefore to our particles, is determined by the GLSL's logic- it does practically all of the heavy lifting:
1. The quad shader is provided the initial values of the motion simulation and writes them to the correct pixel, for physics later.
2. The color quad shader writes color values that are stored in 8-bit textures for retrieval in the final steps. We use 8-bit because their smaller size and already-clamped values are ideal for simple color values (or texture values, or etc.).
3. The physics shader alters 2 textures, based on the values of the 4 used to store all of the data necessary to create a simple simulation of motion, using very simple equations. Obviously, this is one area where optimization / deviation from the general model is possible- remove un-necessary physics steps, add special steps to do something new, etc.
4. The LOS shader alters one texture's pixel values, black or white, depending on Lua-supplied game logic. It updates infrequently, because CPU use is a consideration (basically, the bigger the map, the longer it takes to return- a performance tweak to allow faster updates on smaller maps might be a good idea, maybe I'll get to that).
5. The final shader positions the vertexes in world space, gets certain data to allow for LOS retrieval by determining where the particle is, and then passes to the fragment shader, which is, in the general model, set up to do colormap emulation, where it cycles through color values delivered via texturemaps, and then blends that with a main texturemap to arrive at final RGBA values and write the texels to the frame buffer, where it then is interpreted according to blending instructions in the OpenGL portion of the loop- a very important part of its final look and feel.
Anyhow, I'll try and find the time to clean it all up a bit and comment it better, once I know that it all compiles on ATi. It is really a very simple program that uses a lot of GLSL as "subroutines" of a sort, though.
@AF: I'll look at a cute box about LuaShaders, but tbh it seems pointless. They're on by default in Spring installs (and certainly are configured that way in P.U.R.E. installs), and if an end-user has turned them off, they've done so manually, and I assume they have a good reason- they have an Intel 945, for example. The best thing to do there is to fail gracefully and depart with as little fuss as possible, and write a FAQ entry that says,
Q. Where are those nifty effects I see in screenshots?
A. If you have an Intel graphics chipset (i.e., you're trying to play this on a typical netbook), ATi card older than a Radeon 9800 or GeForce older than 6800, Wolfe Games regrets to inform you that your hardware can't run the effects, so we've shut them off to prevent the game from crashing. If you have a new graphics card from ATi or nVidia, please contact Wolfe Games and they will help troubleshoot the problem.
Kloot actually addressed the crashing part recently, but it never hurts to explain to end-users why something is missing, imo- frequently, people don't read specs for games. I don't have time to write an OpenGL 1.x spec fallback for that segment of the market atm, and they would be very unhappy with the performance anyhow, so it's better that it's not there than makes for a miserable experience.
