Bug Hunters Apply Here

The Partridge Family were neither partridges nor a family. Discuss.
User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Bug Hunters Apply Here

Post by chili » April 24th, 2012, 8:16 am

So there's a bug in our old friend DrawLine(). My challenge to you is to find this bug and figure out a way to squish it. First one to post a solution here gets... well nothing really. :lol: But I thought it would be good practice for you guys, so take a crack at it if you're feeling awesome. 8-)

Hint: the bug becomes apparent in the Sketchy solution, which is included in the Mouse demos.
Chili

User avatar
LuX
Posts: 1492
Joined: April 22nd, 2012, 12:33 pm
Location: Finland

Re: Bug Hunters Apply Here

Post by LuX » April 24th, 2012, 2:41 pm

Well... I don't have the project with me anymore, but my guess is you mean the mouse goes off in full screen, if that was described correctly. The reason to this is because the cursor position is taken from the whole screen, but in the solution the positions are taken depending on the location of it.

Not sure if that's what you were looking for...

Back in visual basic I simply put a button to calibrate the cursor position to the form position so that it calculates its difference and works like a charm.

----

Correct me if this isn't what you were looking for, it was a wild guess :)

-LuX
ʕ •ᴥ•ʔ

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Bug Hunters Apply Here

Post by chili » April 24th, 2012, 3:25 pm

Nope, that's not the what I had in mind. I only wrote the mouse routines to work with the native resolution of the program (800 x 600), so I don't consider that a bug per se. Plus, I said that the bug was in DrawLine(). :|

Nice try though Bro. :)
Chili

x_eqis
Posts: 18
Joined: April 10th, 2012, 5:37 pm

Re: Bug Hunters Apply Here

Post by x_eqis » April 24th, 2012, 6:30 pm

I actually wondered about a bug before in my programs I've posted here... (although I didn't realize the "drawline" was responsable for it)...do you happen to mean the single pixels that appear right on top (y=0 or 1 or so) when you draw a line?
this having said, I have no clue so far why this happens, but I'll have a look at the drawline later. this is probably one of those times when the debugger could come in handy? I've not become friend with this guy so far :| but this could be the time for a new try :)

User avatar
LuX
Posts: 1492
Joined: April 22nd, 2012, 12:33 pm
Location: Finland

Re: Bug Hunters Apply Here

Post by LuX » April 24th, 2012, 6:47 pm

Oh yeah, x_eqis

And I just so happen to find the solution:

replace //Clear canvas with this:

Code: Select all

	// clear canvas
	for( int y = 1; y < 600; y++ )
	{
		for( int x = 1; x < 800; x++ )
		{
			if (y > 0)
			{PutPixelCanvas( x,y,0,0,0 );}
		}
	}
Edit: Wait there was no cash prize included? :roll:
ʕ •ᴥ•ʔ

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Bug Hunters Apply Here

Post by chili » April 24th, 2012, 7:31 pm

X_Eqis: Yup, that is exactly the problem that I was talking about. Very observant! Now can you find the solution? 8-)

LuX: Yeah... that would totally work... NOT! :x Admit it, you're just grasping at straws now LuX. :lol:
Chili

User avatar
LuX
Posts: 1492
Joined: April 22nd, 2012, 12:33 pm
Location: Finland

Re: Bug Hunters Apply Here

Post by LuX » April 24th, 2012, 7:46 pm

>.< But... but... It works perfectly for me!

I'll take a better look tomorrow, I'll probably lose some good night sleep for this one : (

Edit: yeah I see now what you mean, it just removes the lines from top and left... sigh
ʕ •ᴥ•ʔ

x_eqis
Posts: 18
Joined: April 10th, 2012, 5:37 pm

Re: Bug Hunters Apply Here

Post by x_eqis » April 24th, 2012, 9:09 pm

well....
the problem only occurs when a line is drawn from one pixel to the exact same pixel, so e.g.
DrawLineCanvas (60,60,60,60,255,255,255)

you can see that in the sketch program: if you move the mouse fast while drawing lines, no pixel is drawn on the top. if you are slow enough to draw lines like the above example, for some reason y returns 0 in the
int y = (int)(m*x + b + 0.5f);

I still don't get the math - shouldn't
float m = (float)dy / (float)dx;
let the program crash (division by 0 ) anyway? Or do float variables work differently?

Anyway, there is a way to avoid the problem without mastering the math:
I just put an if statement aroung the whole body of the drawlinecanvas function,
so

void Game::DrawLineCanvas( int x1,int y1,int x2,int y2,int r,int g,int blu )
{
if (x1 == x2 && y1 == y2) //if start & end of the line match....
{
PutPixelCanvas( x1,y1,r,g,blu ); //no further calculations!
}
else // if there is actually a line to draw....
{
....function....
}



If would still be interested in what exactly happens with that dy/dx...maybe I didn't pay attention to that drawline lesson?
Attachments
Game.cpp
updated game.cpp
(4.46 KiB) Downloaded 666 times

User avatar
chili
Site Admin
Posts: 3948
Joined: December 31st, 2011, 4:53 pm
Location: Japan
Contact:

Re: Bug Hunters Apply Here

Post by chili » April 25th, 2012, 4:55 am

X_Eqis: You got it bro, bravo! It was a tricky little bug but you found it, and your fix seems like it would work fine. It's a little different that what I did but the basic idea is the same: we want to avoid zero being divided by zero.

In the lesson, I didn't talk about the corner case where the start point and the end point are the same because I didn't occur to me at the time. So no, it wasn't because you weren't paying attention Eqis. ;)

When you divide by zero with integer data types, it generally causes the program to puke, but not so for floating point data types. Besides the normal real number values, floats can also take on the values of -inf., +inf., and NaN (Not a Number). Dividing any non-zero value by zero will give you +/-inf., and dividing zero by zero will give you NaN. When you convert NaN to an integer type, it is converted to zero, and that is why the expression evaluates to y = 0 when dx and dy are equal to 0.

P.S. This is unrelated but, after become proficient at programming, what kind of game are you planning to make? Do you have a specific idea or project in mind? Just curious. :)

LuX: Good try bro. As long as you thought about the problem yourself, and now you understand the problem and solution, then this should have been a good learning experience for you. :)
Chili

User avatar
LuX
Posts: 1492
Joined: April 22nd, 2012, 12:33 pm
Location: Finland

Re: Bug Hunters Apply Here

Post by LuX » April 25th, 2012, 5:03 am

Hmm... to be honest I was looking for zero divisions and anything that would've made the program to poop out zeros, but looking at your code I thought you went around that problem.

I also forgot dividing by floating zeros would make an infinite, figured they would become zeros.

WD x_eqis :-D
ʕ •ᴥ•ʔ

Post Reply