MIPS: Midpoint Circle Algorithm
I'm trying to draw a circle in the bitmap using MARS. I've converted the c formula from Wikipedia, however the result I'm getting is wrong. I'm thinking there's an error with my conversion but I can't for the life of me figure out what it is.
#Procedure: drawCircle:
#Draw a circle in the center of the input pixel (This will be implemented using the
#midpoint circle algorithm from https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
#a0 = x0
#a1 = y0
#a2 = color
#a3 = radius
drawCircle:
#MAKE ROOM ON STACK
addi $sp, $sp, -20 #Make room on stack for 1 words
sw $ra, 0($sp) #Store $ra on element 0 of stack
sw $a0, 4($sp) #Store $a0 on element 1 of stack
sw $a1, 8($sp) #Store $a1 on element 2 of stack
sw $a2, 12($sp) #Store $a1 on element 3 of stack
sw $a3, 16($sp) #Store $a1 on element 4 of stack
#VARIABLES
move $t0, $a0 #x0
move $t1, $a1 #y0
move $t2, $a3 #radius
addi $t3, $t2, -1 #x
li $t4, 0 #y
li $t5, 1 #dx
li $t6, 1 #dy
li $t7, 0 #Err
#CALCULATE ERR (dx - (radius << 1))
sll $t8, $t2, 1 #Bitshift radius left 1
subu $t7, $t5, $t8 #Subtract dx - shifted radius
#While(x >= y)
circleLoop:
blt $t3, $t4, skipCircleLoop #If x < y, skip circleLoop
#Draw Dot (x0 + x, y0 + y)
addu $a0, $t0, $t3
addu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + y, y0 + x)
addu $a0, $t0, $t4
addu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - y, y0 + x)
subu $a0, $t0, $t4
addu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - x, y0 + y)
subu $a0, $t0, $t3
addu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - x, y0 - y)
subu $a0, $t0, $t3
subu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - y, y0 - x)
subu $a0, $t0, $t4
subu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + y, y0 - x)
addu $a0, $t0, $t4
subu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + x, y0 - y)
addu $a0, $t0, $t3
subu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#If (err <= 0)
bgtz $t7, doElse
addi $t4, $t4, 1 #y++
addu $t7, $t7, $t6 #err += dy
addi $t6, $t6, 2 #dy += 2
j circleContinue #Skip else stmt
#Else If (err > 0)
doElse:
addi $t3, $t3, -1 #x--
addi $t5, $t5, 2 #dx += 2
sll $t8, $t2, 1 #Bitshift radius left 1
subu $t9, $t5, $t8 #Subtract dx - shifted radius
addu $t7, $t7, $t9 #err += $t9
circleContinue:
#LOOP
j circleLoop
#CONTINUE
skipCircleLoop:
#RESTORE $RA
lw $ra, 0($sp) #Restore $ra from stack
addi $sp, $sp, 20 #Readjust stack
None of the procedures I call change any t-registers. The result I get with the following values: x = 10 y = 10 color = 5 radius = 10

assembly bitmap mips32 mars-simulator
add a comment |
I'm trying to draw a circle in the bitmap using MARS. I've converted the c formula from Wikipedia, however the result I'm getting is wrong. I'm thinking there's an error with my conversion but I can't for the life of me figure out what it is.
#Procedure: drawCircle:
#Draw a circle in the center of the input pixel (This will be implemented using the
#midpoint circle algorithm from https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
#a0 = x0
#a1 = y0
#a2 = color
#a3 = radius
drawCircle:
#MAKE ROOM ON STACK
addi $sp, $sp, -20 #Make room on stack for 1 words
sw $ra, 0($sp) #Store $ra on element 0 of stack
sw $a0, 4($sp) #Store $a0 on element 1 of stack
sw $a1, 8($sp) #Store $a1 on element 2 of stack
sw $a2, 12($sp) #Store $a1 on element 3 of stack
sw $a3, 16($sp) #Store $a1 on element 4 of stack
#VARIABLES
move $t0, $a0 #x0
move $t1, $a1 #y0
move $t2, $a3 #radius
addi $t3, $t2, -1 #x
li $t4, 0 #y
li $t5, 1 #dx
li $t6, 1 #dy
li $t7, 0 #Err
#CALCULATE ERR (dx - (radius << 1))
sll $t8, $t2, 1 #Bitshift radius left 1
subu $t7, $t5, $t8 #Subtract dx - shifted radius
#While(x >= y)
circleLoop:
blt $t3, $t4, skipCircleLoop #If x < y, skip circleLoop
#Draw Dot (x0 + x, y0 + y)
addu $a0, $t0, $t3
addu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + y, y0 + x)
addu $a0, $t0, $t4
addu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - y, y0 + x)
subu $a0, $t0, $t4
addu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - x, y0 + y)
subu $a0, $t0, $t3
addu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - x, y0 - y)
subu $a0, $t0, $t3
subu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - y, y0 - x)
subu $a0, $t0, $t4
subu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + y, y0 - x)
addu $a0, $t0, $t4
subu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + x, y0 - y)
addu $a0, $t0, $t3
subu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#If (err <= 0)
bgtz $t7, doElse
addi $t4, $t4, 1 #y++
addu $t7, $t7, $t6 #err += dy
addi $t6, $t6, 2 #dy += 2
j circleContinue #Skip else stmt
#Else If (err > 0)
doElse:
addi $t3, $t3, -1 #x--
addi $t5, $t5, 2 #dx += 2
sll $t8, $t2, 1 #Bitshift radius left 1
subu $t9, $t5, $t8 #Subtract dx - shifted radius
addu $t7, $t7, $t9 #err += $t9
circleContinue:
#LOOP
j circleLoop
#CONTINUE
skipCircleLoop:
#RESTORE $RA
lw $ra, 0($sp) #Restore $ra from stack
addi $sp, $sp, 20 #Readjust stack
None of the procedures I call change any t-registers. The result I get with the following values: x = 10 y = 10 color = 5 radius = 10

assembly bitmap mips32 mars-simulator
Have you single-stepped through your code in the debugger to look for where register values aren't what you expect?
– Peter Cordes
Nov 11 at 10:00
@PeterCordes Yes, I'm still in the process of doing it now because there are a lot of values. So far nothing has caught my eye. I just want to make sure I've made no obvious mistakes with the conversion. One thing that I've noticed is that the first and second drawDots are far apart which doesn't seem correct.
– DazedFury
Nov 11 at 10:03
Here's something strange, when the coordinates for the first and second dots are drawn, they are 10, 19 and 19, 10 respectively. When they are drawn, one is drawn on the left half of the bitmap while the other is drawn on the right half.
– DazedFury
Nov 11 at 10:08
where isdrawDotcode? ... ah, you figured it out meanwhile... yes, the size of the bitmap did look like good candidate, because calculating target address with wrong width size will make y coordinate to "wrap" around to all places in predictable way (like drawing into 512x512 when you expect 256x256 will make every other line positioned in the right half of picture, while odd lines are on left and the total picture is half of desired size, using 512x128 area only)
– Ped7g
Nov 11 at 10:31
add a comment |
I'm trying to draw a circle in the bitmap using MARS. I've converted the c formula from Wikipedia, however the result I'm getting is wrong. I'm thinking there's an error with my conversion but I can't for the life of me figure out what it is.
#Procedure: drawCircle:
#Draw a circle in the center of the input pixel (This will be implemented using the
#midpoint circle algorithm from https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
#a0 = x0
#a1 = y0
#a2 = color
#a3 = radius
drawCircle:
#MAKE ROOM ON STACK
addi $sp, $sp, -20 #Make room on stack for 1 words
sw $ra, 0($sp) #Store $ra on element 0 of stack
sw $a0, 4($sp) #Store $a0 on element 1 of stack
sw $a1, 8($sp) #Store $a1 on element 2 of stack
sw $a2, 12($sp) #Store $a1 on element 3 of stack
sw $a3, 16($sp) #Store $a1 on element 4 of stack
#VARIABLES
move $t0, $a0 #x0
move $t1, $a1 #y0
move $t2, $a3 #radius
addi $t3, $t2, -1 #x
li $t4, 0 #y
li $t5, 1 #dx
li $t6, 1 #dy
li $t7, 0 #Err
#CALCULATE ERR (dx - (radius << 1))
sll $t8, $t2, 1 #Bitshift radius left 1
subu $t7, $t5, $t8 #Subtract dx - shifted radius
#While(x >= y)
circleLoop:
blt $t3, $t4, skipCircleLoop #If x < y, skip circleLoop
#Draw Dot (x0 + x, y0 + y)
addu $a0, $t0, $t3
addu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + y, y0 + x)
addu $a0, $t0, $t4
addu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - y, y0 + x)
subu $a0, $t0, $t4
addu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - x, y0 + y)
subu $a0, $t0, $t3
addu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - x, y0 - y)
subu $a0, $t0, $t3
subu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - y, y0 - x)
subu $a0, $t0, $t4
subu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + y, y0 - x)
addu $a0, $t0, $t4
subu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + x, y0 - y)
addu $a0, $t0, $t3
subu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#If (err <= 0)
bgtz $t7, doElse
addi $t4, $t4, 1 #y++
addu $t7, $t7, $t6 #err += dy
addi $t6, $t6, 2 #dy += 2
j circleContinue #Skip else stmt
#Else If (err > 0)
doElse:
addi $t3, $t3, -1 #x--
addi $t5, $t5, 2 #dx += 2
sll $t8, $t2, 1 #Bitshift radius left 1
subu $t9, $t5, $t8 #Subtract dx - shifted radius
addu $t7, $t7, $t9 #err += $t9
circleContinue:
#LOOP
j circleLoop
#CONTINUE
skipCircleLoop:
#RESTORE $RA
lw $ra, 0($sp) #Restore $ra from stack
addi $sp, $sp, 20 #Readjust stack
None of the procedures I call change any t-registers. The result I get with the following values: x = 10 y = 10 color = 5 radius = 10

assembly bitmap mips32 mars-simulator
I'm trying to draw a circle in the bitmap using MARS. I've converted the c formula from Wikipedia, however the result I'm getting is wrong. I'm thinking there's an error with my conversion but I can't for the life of me figure out what it is.
#Procedure: drawCircle:
#Draw a circle in the center of the input pixel (This will be implemented using the
#midpoint circle algorithm from https://en.wikipedia.org/wiki/Midpoint_circle_algorithm
#a0 = x0
#a1 = y0
#a2 = color
#a3 = radius
drawCircle:
#MAKE ROOM ON STACK
addi $sp, $sp, -20 #Make room on stack for 1 words
sw $ra, 0($sp) #Store $ra on element 0 of stack
sw $a0, 4($sp) #Store $a0 on element 1 of stack
sw $a1, 8($sp) #Store $a1 on element 2 of stack
sw $a2, 12($sp) #Store $a1 on element 3 of stack
sw $a3, 16($sp) #Store $a1 on element 4 of stack
#VARIABLES
move $t0, $a0 #x0
move $t1, $a1 #y0
move $t2, $a3 #radius
addi $t3, $t2, -1 #x
li $t4, 0 #y
li $t5, 1 #dx
li $t6, 1 #dy
li $t7, 0 #Err
#CALCULATE ERR (dx - (radius << 1))
sll $t8, $t2, 1 #Bitshift radius left 1
subu $t7, $t5, $t8 #Subtract dx - shifted radius
#While(x >= y)
circleLoop:
blt $t3, $t4, skipCircleLoop #If x < y, skip circleLoop
#Draw Dot (x0 + x, y0 + y)
addu $a0, $t0, $t3
addu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + y, y0 + x)
addu $a0, $t0, $t4
addu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - y, y0 + x)
subu $a0, $t0, $t4
addu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - x, y0 + y)
subu $a0, $t0, $t3
addu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - x, y0 - y)
subu $a0, $t0, $t3
subu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 - y, y0 - x)
subu $a0, $t0, $t4
subu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + y, y0 - x)
addu $a0, $t0, $t4
subu $a1, $t1, $t3
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#Draw Dot (x0 + x, y0 - y)
addu $a0, $t0, $t3
subu $a1, $t1, $t4
lw $a2, 12($sp)
jal drawDot #Jump to drawDot
#If (err <= 0)
bgtz $t7, doElse
addi $t4, $t4, 1 #y++
addu $t7, $t7, $t6 #err += dy
addi $t6, $t6, 2 #dy += 2
j circleContinue #Skip else stmt
#Else If (err > 0)
doElse:
addi $t3, $t3, -1 #x--
addi $t5, $t5, 2 #dx += 2
sll $t8, $t2, 1 #Bitshift radius left 1
subu $t9, $t5, $t8 #Subtract dx - shifted radius
addu $t7, $t7, $t9 #err += $t9
circleContinue:
#LOOP
j circleLoop
#CONTINUE
skipCircleLoop:
#RESTORE $RA
lw $ra, 0($sp) #Restore $ra from stack
addi $sp, $sp, 20 #Readjust stack
None of the procedures I call change any t-registers. The result I get with the following values: x = 10 y = 10 color = 5 radius = 10

assembly bitmap mips32 mars-simulator
assembly bitmap mips32 mars-simulator
asked Nov 11 at 9:40
DazedFury
296
296
Have you single-stepped through your code in the debugger to look for where register values aren't what you expect?
– Peter Cordes
Nov 11 at 10:00
@PeterCordes Yes, I'm still in the process of doing it now because there are a lot of values. So far nothing has caught my eye. I just want to make sure I've made no obvious mistakes with the conversion. One thing that I've noticed is that the first and second drawDots are far apart which doesn't seem correct.
– DazedFury
Nov 11 at 10:03
Here's something strange, when the coordinates for the first and second dots are drawn, they are 10, 19 and 19, 10 respectively. When they are drawn, one is drawn on the left half of the bitmap while the other is drawn on the right half.
– DazedFury
Nov 11 at 10:08
where isdrawDotcode? ... ah, you figured it out meanwhile... yes, the size of the bitmap did look like good candidate, because calculating target address with wrong width size will make y coordinate to "wrap" around to all places in predictable way (like drawing into 512x512 when you expect 256x256 will make every other line positioned in the right half of picture, while odd lines are on left and the total picture is half of desired size, using 512x128 area only)
– Ped7g
Nov 11 at 10:31
add a comment |
Have you single-stepped through your code in the debugger to look for where register values aren't what you expect?
– Peter Cordes
Nov 11 at 10:00
@PeterCordes Yes, I'm still in the process of doing it now because there are a lot of values. So far nothing has caught my eye. I just want to make sure I've made no obvious mistakes with the conversion. One thing that I've noticed is that the first and second drawDots are far apart which doesn't seem correct.
– DazedFury
Nov 11 at 10:03
Here's something strange, when the coordinates for the first and second dots are drawn, they are 10, 19 and 19, 10 respectively. When they are drawn, one is drawn on the left half of the bitmap while the other is drawn on the right half.
– DazedFury
Nov 11 at 10:08
where isdrawDotcode? ... ah, you figured it out meanwhile... yes, the size of the bitmap did look like good candidate, because calculating target address with wrong width size will make y coordinate to "wrap" around to all places in predictable way (like drawing into 512x512 when you expect 256x256 will make every other line positioned in the right half of picture, while odd lines are on left and the total picture is half of desired size, using 512x128 area only)
– Ped7g
Nov 11 at 10:31
Have you single-stepped through your code in the debugger to look for where register values aren't what you expect?
– Peter Cordes
Nov 11 at 10:00
Have you single-stepped through your code in the debugger to look for where register values aren't what you expect?
– Peter Cordes
Nov 11 at 10:00
@PeterCordes Yes, I'm still in the process of doing it now because there are a lot of values. So far nothing has caught my eye. I just want to make sure I've made no obvious mistakes with the conversion. One thing that I've noticed is that the first and second drawDots are far apart which doesn't seem correct.
– DazedFury
Nov 11 at 10:03
@PeterCordes Yes, I'm still in the process of doing it now because there are a lot of values. So far nothing has caught my eye. I just want to make sure I've made no obvious mistakes with the conversion. One thing that I've noticed is that the first and second drawDots are far apart which doesn't seem correct.
– DazedFury
Nov 11 at 10:03
Here's something strange, when the coordinates for the first and second dots are drawn, they are 10, 19 and 19, 10 respectively. When they are drawn, one is drawn on the left half of the bitmap while the other is drawn on the right half.
– DazedFury
Nov 11 at 10:08
Here's something strange, when the coordinates for the first and second dots are drawn, they are 10, 19 and 19, 10 respectively. When they are drawn, one is drawn on the left half of the bitmap while the other is drawn on the right half.
– DazedFury
Nov 11 at 10:08
where is
drawDot code? ... ah, you figured it out meanwhile... yes, the size of the bitmap did look like good candidate, because calculating target address with wrong width size will make y coordinate to "wrap" around to all places in predictable way (like drawing into 512x512 when you expect 256x256 will make every other line positioned in the right half of picture, while odd lines are on left and the total picture is half of desired size, using 512x128 area only)– Ped7g
Nov 11 at 10:31
where is
drawDot code? ... ah, you figured it out meanwhile... yes, the size of the bitmap did look like good candidate, because calculating target address with wrong width size will make y coordinate to "wrap" around to all places in predictable way (like drawing into 512x512 when you expect 256x256 will make every other line positioned in the right half of picture, while odd lines are on left and the total picture is half of desired size, using 512x128 area only)– Ped7g
Nov 11 at 10:31
add a comment |
1 Answer
1
active
oldest
votes
I think I've figured it out. The problem wasn't the conversion but the size of the bitmap. It seems that when the bitmap is to small, the circle ends up wrapping around.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53247462%2fmips-midpoint-circle-algorithm%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think I've figured it out. The problem wasn't the conversion but the size of the bitmap. It seems that when the bitmap is to small, the circle ends up wrapping around.
add a comment |
I think I've figured it out. The problem wasn't the conversion but the size of the bitmap. It seems that when the bitmap is to small, the circle ends up wrapping around.
add a comment |
I think I've figured it out. The problem wasn't the conversion but the size of the bitmap. It seems that when the bitmap is to small, the circle ends up wrapping around.
I think I've figured it out. The problem wasn't the conversion but the size of the bitmap. It seems that when the bitmap is to small, the circle ends up wrapping around.
answered Nov 11 at 10:10
DazedFury
296
296
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53247462%2fmips-midpoint-circle-algorithm%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Have you single-stepped through your code in the debugger to look for where register values aren't what you expect?
– Peter Cordes
Nov 11 at 10:00
@PeterCordes Yes, I'm still in the process of doing it now because there are a lot of values. So far nothing has caught my eye. I just want to make sure I've made no obvious mistakes with the conversion. One thing that I've noticed is that the first and second drawDots are far apart which doesn't seem correct.
– DazedFury
Nov 11 at 10:03
Here's something strange, when the coordinates for the first and second dots are drawn, they are 10, 19 and 19, 10 respectively. When they are drawn, one is drawn on the left half of the bitmap while the other is drawn on the right half.
– DazedFury
Nov 11 at 10:08
where is
drawDotcode? ... ah, you figured it out meanwhile... yes, the size of the bitmap did look like good candidate, because calculating target address with wrong width size will make y coordinate to "wrap" around to all places in predictable way (like drawing into 512x512 when you expect 256x256 will make every other line positioned in the right half of picture, while odd lines are on left and the total picture is half of desired size, using 512x128 area only)– Ped7g
Nov 11 at 10:31