<p>The following is really an assorted set of comments:</p>

<p>Why integer? Floating-point hardware is (in general) far more complex than integer and so on many (old) CPUs it (a) might not have been available (because of silicon budget) and/or (b) took considerably more clock cycles to execute than integer operations.</p>

<p>Re "Bresenham's" algorithm: IIRC there is a branch/decision per pixel. On old CPUs (with relatively little or no pipelining) this would have not been a penalty, but with modern, highly pipelined/superscalar  CPUs, each mispredicted branch will be detrimental. 
Presumably (as I can't see your code) using floating-point removes that decision from the loop but, then again, you could use fixed-point (i.e. integer) to get the same effect.</p>

<p>Having said this, hardware rasterisation is probably using fixed-point (i.e. integer) maths when filling polygons as this (a) makes conforming to the OpenGL fill rules easier and (b) prevents some very nasty problems occuring with long/thin triangles.</p>

CC BY-SA 4.0
2019-12-23T17:02:42.157Z
Ok but regarding the visual result, which of the 2 versions is preferrable? The first version feels laggy but produces perfect circles whereas the second version is much smoother but if we pause the animation, the circles are not very round
Voko
CC BY-SA 4.0
2019-12-23T17:31:21.573Z
You're asking for an 'artistic/ aesthetic’ evaluation?  That's getting into trading-off temporal vs spatial sampling/aiasing/noise.
Simon F
CC BY-SA 4.0
2019-12-23T17:35:14.167Z
Actually, having taken a snapshot of the "floating point" version, it seems to me that the 'line width' is inconsistent.
Simon F
CC BY-SA 4.0
2019-12-23T19:38:47.640Z
@Jojolatino The bresenham version is not "laggy" because of misprediction - it simply allows the circle to move only by a single pixel at a minimum. The floating point version allows subpixel precision in some sense,  which causes not all points of the circles to move by the same amount creating an illusion of smoothness. What you are seeing is a combination of aliasing and temporal discontinuity, the floating point version handles it better because it does not enforce the exact same sampling, which gives more of a leeway for temporal continuity.
lightxbulb
CC BY-SA 4.0
2019-12-23T16:44:51.590Z
2019-12-23T16:50:12.230Z
2019-12-23T16:50:12.230Z
Simon F
<p>I wonder why all the well known algorithms of drawing for example circles (bresenham, mid-point, etc) all use integer arithmetics? For example, here is a simple circle drawn with bresenham algorithm:
<a href="https://i.sstatic.net/N7Spm.gif" rel="nofollow noreferrer"><img src="https://i.sstatic.net/N7Spm.gif" alt="enter image description here"></a></p>

<p>And this is what I get with a circle drawn using naive algorithm (with real numbers):
<a href="https://i.sstatic.net/nHCk1.gif" rel="nofollow noreferrer"><img src="https://i.sstatic.net/nHCk1.gif" alt="enter image description here"></a></p>

<p>The bresenham's version just look terrible and feels laggy while the floating point version is much smoother. So why do we read everywhere that "integer" versions are preferred? The integer version is maybe faster but horrible when it comes to animating a moving shape. So the question is: should I use floating point version or bresenham's version in my little toy rasterizer?</p>

<p>Here's a more real world example:</p>

<p>Bresenham:</p>

<p><a href="https://i.sstatic.net/69abW.gif" rel="nofollow noreferrer"><img src="https://i.sstatic.net/69abW.gif" alt="enter image description here"></a></p>

<p>Floating point:</p>

<p><a href="https://i.sstatic.net/G19fN.gif" rel="nofollow noreferrer"><img src="https://i.sstatic.net/G19fN.gif" alt="enter image description here"></a></p>

<p>So what which version is the correct one? The floating point looks wobbly but smoother than Bresenham. Should I stick with Bresenham integer or use a floating point version smoother (or even a fixed point version)?</p>

CC BY-SA 4.0
2019-12-23T14:26:53.800Z
"*The bresenham's version just look terrible and feels laggy while the floating point version is much smoother.*" What about the massive amount of dot crawl in your "naive" algorithm? I'd call that pretty rough.
Nicol Bolas
CC BY-SA 4.0
2019-12-23T14:26:59.450Z
There is no point on a modern platform, integer algorithms were intended for machines from the 70-80s..
PaulHK
<animation><rasterizer><drawing><midpoint>
What is the point of having integer-based draw routines in software rasterizer?
Voko
# What is the point of having integer-based draw routines in software rasterizer?

(Asked by: username_0 on 2019-12-23)

I wonder why all the well known algorithms of drawing for example circles (bresenham, mid-point, etc) all use integer arithmetics? For example, here is a simple circle drawn with bresenham algorithm:
[![enter image description here](https://i.sstatic.net/N7Spm.gif)](https://i.sstatic.net/N7Spm.gif)

And this is what I get with a circle drawn using naive algorithm (with real numbers):
[![enter image description here](https://i.sstatic.net/nHCk1.gif)](https://i.sstatic.net/nHCk1.gif)

The bresenham's version just look terrible and feels laggy while the floating point version is much smoother. So why do we read everywhere that "integer" versions are preferred? The integer version is maybe faster but horrible when it comes to animating a moving shape. So the question is: should I use floating point version or bresenham's version in my little toy rasterizer?

Here's a more real world example:

Bresenham:

[![enter image description here](https://i.sstatic.net/69abW.gif)](https://i.sstatic.net/69abW.gif)

Floating point:

[![enter image description here](https://i.sstatic.net/G19fN.gif)](https://i.sstatic.net/G19fN.gif)

So what which version is the correct one? The floating point looks wobbly but smoother than Bresenham. Should I stick with Bresenham integer or use a floating point version smoother (or even a fixed point version)?

**Tags:** animation, rasterizer, drawing, midpoint

> **Comments:**
> **username_1**: "*The bresenham's version just look terrible and feels laggy while the floating point version is much smoother.*" What about the massive amount of dot crawl in your "naive" algorithm? I'd call that pretty rough.  
> **username_2**: There is no point on a modern platform, integer algorithms were intended for machines from the 70-80s..  

---

## 1 answers

### Answer by username_3 on 2019-12-23. Score: 2

The following is really an assorted set of comments:

Why integer? Floating-point hardware is (in general) far more complex than integer and so on many (old) CPUs it (a) might not have been available (because of silicon budget) and/or (b) took considerably more clock cycles to execute than integer operations.

Re "Bresenham's" algorithm: IIRC there is a branch/decision per pixel. On old CPUs (with relatively little or no pipelining) this would have not been a penalty, but with modern, highly pipelined/superscalar CPUs, each mispredicted branch will be detrimental.
Presumably (as I can't see your code) using floating-point removes that decision from the loop but, then again, you could use fixed-point (i.e. integer) to get the same effect.

Having said this, hardware rasterisation is probably using fixed-point (i.e. integer) maths when filling polygons as this (a) makes conforming to the OpenGL fill rules easier and (b) prevents some very nasty problems occuring with long/thin triangles.

> **Comments:**
> **username_0**: Ok but regarding the visual result, which of the 2 versions is preferrable? The first version feels laggy but produces perfect circles whereas the second version is much smoother but if we pause the animation, the circles are not very round  
> **username_3**: You're asking for an 'artistic/ aesthetic’ evaluation?  That's getting into trading-off temporal vs spatial sampling/aiasing/noise.  
> **username_3**: Actually, having taken a snapshot of the "floating point" version, it seems to me that the 'line width' is inconsistent.  
> **username_4**: @Jojolatino The bresenham version is not "laggy" because of misprediction - it simply allows the circle to move only by a single pixel at a minimum. The floating point version allows subpixel precision in some sense,  which causes not all points of the circles to move by the same amount creating an illusion of smoothness. What you are seeing is a combination of aliasing and temporal discontinuity, the floating point version handles it better because it does not enforce the exact same sampling, which gives more of a leeway for temporal continuity.  

---

