first, let me apologize in advance for the length of this post, and thank anyone willing to read and reply to it.
For quite some time now I've been wanting to make a program that simulates the movement of various celestial objects, mostly stars, as a result of gravity. I made such a program quite some time ago, using plain C and Allegro; stars had mass, density, radius, position and velocity, and were represented as little circles on the screen. When they got too close together, I would "turn off" gravity. Simple-as-a-pimple.
One day I though I would make a more advanced version, so I started to read up on star collisions. I quickly learned that simulating a collision between two stars is something one can not do on an average home computer with an average knowledge of C++. So I came up with a workaround; the star would be made of particles. That meant that the computer would think of a star as a star when nothing was in close proximity, but when two stars got close enough to each other, the stars would be treated as lots of particles. I think a crude illustration is in order:
or something like that anyway. If this ever works out, I would like to introduce pressure into the whole program, specifically to treat the stars as a bunch of particles only if the gravitational stress would be enough to "rip the star apart".
Anyway, I decided that a stars mass would be generated, followed by it's density. From that, the radius would arise. And the number of particles the star was made up would be determined by the number of pixels it would occupy when drawn to the screen. In other words, one pixel=one particle. Here I encountered the first big problem. When a circle is drawn to the screen, it's made up of a bunch of squares. It's not a perfect circle. What I needed to find out was how to calculate the number of pixels set when drawing a circle with a radius of n pixels to the screen. And I had no idea how to do that. So I came here, asked my question, and was answered with the Midpoint Circle Algorithm. Unfortunately, I couldn't really figure out the math behind it, but I though I had grasped the theory, so I started working on my own, drawing up circles on squared paper, and eventually came up with the formula 2*r^2 + 6*r - 19, where r is the radius. It seemed to work with all the circles I had drawn up that had a radius bigger than three. So, yay, I had overcome the big obstacle. I chose SDL as the library I would use, and started learning to use it. Now, here comes the reason why I'm writing this article anyway. This whole thing depends on the fact that when the stars are far away from each other, I tell SDL to render a circle, and when the stars are close together, I tell SDL to render lots of pixels. But a few days ago I learned that, as opposed to Allegro, SDL does not have functions that handle drawing primitive shapes to the screen. Which means I was sc***ed. So I had a look at Google, and came up with something called SDL_Draw, which is an "add on" to SDL containing functions to draw primitive shapes to the screen. Problem was, I couldn't get it to work (I'm using Code::Blocks, and I'm terrible at making libraries run). As if it wasn't enough, I opened Microsoft Paint, made a couple of circles, counted the squares in them and compared them to what my formula gave me, just out of curiosity. And guess what; my formula was off. Which means that either Microsoft Paint uses some other algorithm that I'm not aware of, or I understood the algorithm wrong and drew up my circles wrong. So, here come the questions:
Should I stick with SDL, or use another library? If so, which one? If not, can someone help me get that SDL_Draw think working?
Does anyone know how to calculate the number of pixels that will be set when a circle of a radius r is drawn to the screen using SDL?
There are lots of other question I'd like to ask, but I'll post those in another topic, since they are irrelevant if I can't get this to work.