My feeling isn't that I can play with a "good enough" fps, but that I play with acceptable FPS and that it lags with too much going on, and that bothers me. I don't have the technical knowledge to say for certain that OpenCL would make many improvements, but multithreading at least stands a fair chance to give a good boost for most, myself included.
It's a shame that it's so hard to add, though. Which is why I've heartily recommended a re-write. At this stage in developement, the developers know all the elements they need to have and what they need to do, right? So, hopefully, a re-write would actually be easier then added in multithreading with the as-is code.
OpenCL code can also run on cpu's.
But dont tink that opencl is just speed ups. Lets say that you write a kernel for heat simulation.
Even if you keep some data on the gpu, you have to update particle positions and types.
You still have to get some data for showing the temperature value of a certain particle and see if its state changed based on the new temprature. Also PCIe bandwitd is limited, you risk running into a bottleneck.
Also you have to sincronize the kernel execution with the game, which will slow down your program.
OpenCL works directly with hardware where as SDL is a middle man to the hardware, there would be an increase in performance switching to it, the more powerful cards would see a huge reduction in draw time.
Logic time is however the issue with this program, multithreading is the answer. Using the same principles as double buffering for the logic allows for easy synchronision between the threads.
Yes you can use OpenCL to draw directly data in the buffers of the gpu to the screen.
But for that to work you have to have all the relevant information on the device memory (GPU), mainly particle position and color. If you have to transfer the data from the host memory to the GPU memory every frame you are better off using just openGL.