OpenGL can render 8 lights in hardware per pass. More render passes mean more lights on an object, but at a performance cost. Without shaders the code can handle up to 5 render passes pretty well. With shaders it can do just one relatively well.
FSO itself still processes something like 256 lights per pass though. That is done per the older software rendering, and the HTL graphics code doesn't use all of that lighting info. It is possible to change the code to use it however, rendering 8 (or less) lights in hardware and using vertex coloring for the remaining lights all in a single pass. The lights over the first 8 wouldn't look as good of course, but they would work and would allow for all 256 in a scene that the game processes to be used. The performance hit should be minimal using this method but I haven't tested it myself so I can't say that for sure.
Of course the biggest performance hit with the current shaders is the lighting. By having 8 lights in there all of the time the instruction count on the vertex shaders is very high and that makes them very slow. For instance, in the ships lab, if you trim the shaders to only do one light (since the lab only has one light anyway) you can get a 5-10x FPS boost. The shader code as originally coded was intended to have three sets of each shader, each supporting a different number of lights: 1, 2 & 4. Using that combination it would then be possible to render using a maximum of 2 passes and still get all of the lights. The shader complexity would be a lot less which also would provide a noticeable performance boost, particularly if you only needed a single pass. Unfortunately the renderer is too old and slow to handle multiple passes with shaders without a very large performance hit. The code was subsequently trimmed down to what eventually got put in SVN.
I did work on that performance hit a little earlier this year, to take one last crack at it. Although the reworked code did help a bit (7-180+% performance boost depending on the model) it still had some issues with multi pass. Also, the reworked shaders were still a little too instruction heavy for good SM2.0 level hardware support, with them being about a dozen instructions too big with the 4 light shader. Cutting it to 3 lights max, with up to 3 passes for all of the lights, does work with SM2.0 level hardware but has a performance hit that makes it a bit slower than the current code/shaders. The reworked code could do 2 passes at relatively the same performance of the current code, but no more.
So the point I guess is that: the game processes 256 lights at a time, it will only render 8 of them per object each pass, it would be possible to use all 256 lights with shaders but with a slight hit to visual quality, the reason for the 8 light limit is a hardware performance thing, the engine was designed for software rendering of low-poly models and is set up in a way that is rather inefficient for shader use, the way that our shaders handle lighting is stupid.
It is possible to address these issues, to remove some of the brute force from the renderer so that it is better set up for using shaders, but no one has done it.
