So, in opengl 4.x, there are no primitives for circle, and the only ways to draw an almost perfect circle are following

Draw a triangle fan and fk up your memory for a circle
Draw a rectangle and use the fragment shader and distance equation to discard the bit that is not used
But you will need to add an if statement and potentially increase the frame time (from what i have heard)
And it will be more complicated than just using a triangle fan

i mean... kinda... of course? you're working with the graphics card, which is working with triangles and polygons, so... of course? afaik, these are only two viable methods in any and all libs interfacing with hardware accelerated graphics. if any lib pretends to have "native" way to draw circles, all it does is it hides from you that it's doing it in one of these two ways...?

I understand that, but at this point, graphics hardware should have had atleast some basic curves

@eternalrm and how do you propose they be implemented on the hardware level?

@Midnight-shcode Using the well known algorithms for
1. Distance from a polynomial
3. Intersection of a line and a polynomial
4. Derivative of a polynomial at a given point
5. Linear transformation of a polynomial
If you constrain the hardware to 3rd degree polynomials or 4 point Bezier curves all of these are fairly straightforward and lend themselves to circuit design. The circuits could do the exact same thing the programs would and still be incomparably faster for the simple reason that it's a circuit and not a program running on a circuit. They wouldn't fuck up branch prediction, for example.

Circles would still be a lie because they aren't finite Bezier curves, but the lie would be believable without wasting resources.

Or, you could just introduce a circle primitive using the (much simpler) equations for circles because it's far more common than other curves.

@Midnight-shcode you could use the derivative of the circle/distance equation to eliminate the square root and use it to get the outline of the circle,
you could also utilise the fact that circles are symmetrical,
then you would only need to find 1/8 th of the total coords,
I have implemented the symmetry part at
github.com/eternalfrustation/rats
And plan on implementing the derivative part soon
*while murmuring* the repo linked above has some of the worst code you will ever probably see

There are no circles, just regular polygons with many sides

If you want to be mathematical about it, a circle is a set of all points with a fixed distance from some point

@eternalrm And there are infinite points like that, and there is no infinity, it's better to use polygons than circles, easy to render.

@theabbie that is why i said mathematically

@theabbie But there aren't polygons either, there's a limited number of pixels in a square grid. How you decide the colour of each is up to you. There's nothing preventing you from using the circle equation, or the algorithm for any shape that has one. It doesn't even have to have a proper edge.

Graphics cards or computers in general don't have the kind of restrictions you guys are thinking in. They don't give a fuck whether the thing you're processing is straight, curved, open, closed, dense, sparse. The only thing they care about is that certain properties have to be computable on a Turing machine. In the case of drawing to a buffer, you only need to be able to tell whether a given point is inside or outside the shape.

Also, any series of GLSL instructions can, by nature, be converted into a single instruction. The price is added complexity in the GPU and the benefit varies so it's not often done, but it's never infeasible. Actually, I'm very surprised if there isn't a widely supported extension for ellipses.

@homo-lorens thank you for the explanation. you probably didn't expect that, but i was actually asking in the hopes of getting one, since i'm not a HW person :)

i think i understand a bit better now.