Hello guys and gals here at dreamincode.net.
I've been learning c# and then XNA in my free time during the past few years,
browsing forums like this one and watching tutorials, and reading a bit in a few books here and there.
This is my first post anywhere asking for help, so please excuse (in advance) any noob-nes my post may contain.
I will try my best to adhere to forum guidelines.
Among many other small "learn-c#-projects" I made a fun little (win-forms!) breakout clone a year or so back.
My family enjoyed the little game, and it was rewarding at the time, to complete something that worked (almost!) as intended.
I've restarted the project in XNA, hoping to achieve a smoother, bit more advanced version.
I've got different ways of importing levels from text or pictures (or using a self made editor).
-an improvement to the last games "hard-coded" built in levels.
I've got multichannel sound for lasers and bricks breaking, as opposed to last games 1-sound-at-a-time scheme.
Things are looking good.
But I have an issue that's been bothering me for way too long now, and I seem to be stuck, losing motivation.
Its been a few months without progress...
The issue is hit-detection...
For my non-XNA version, hit detection was the standard "move, check collisions, move, check collisions" method.
As you all know, this results in occasional "overlap", where the ball in fact protrudes through things, before hit detection occurs...
For my XNA version however, I'm trying to implement "hit-prediction" (dont know a better term),
to avoid such overlap / semi-poor hit-detection.
The idea is, that every time a change occurs for the ball (i.e. its launched, or it bounces off something)
It scans ahead, considering direction and velocity, and predicts when collision should occur, instead of checking each frame...
Forgetting about bricks for now, (leaving only borders/walls and the ball), the idea I've been going with was
to define these objects in terms of lists of pixels (vectors for each containing position, and direction.)
And then testing these list items (ball-pixel-list and wall-pixel-list) against each other...
However, because power-ups and/or my preferences can change the size of the ball, The ball must have its "circumferance-pixels" defined by a method each time the game starts, or size is changed... (as only circumferance pixels are relevant to test for collisions).
So the sprite scales fine. However, compiling a list of these "circumference pixels" to be used in hit detection turns out... Hard.
I cant seem to get a complete list of pixels. There are "gaps" in the circle, allowing for "penetration".
The amount of pixels on the list does vary depending on ball diameter, but not in an immediately predictable manner.
A larger ball may claim to have fewer pixels on its circumference. hmmmm.
I've tried to adjust the tolerance levels for when a pixel is considered to be "on the line", but without much effect.
(something like "if a pixel is on the circle plus/minus one or two pixels")
Now, my methods work almost all the time (when ball diameter is 30!) , leading me to believe I'm close, but still some ball direction angle-ranges let the ball protrude through the walls a bit...
So, now that I've explained my situation, let me state the question I think I should be asking,
but please feel free to correct me...
How do I compile a complete list of ball circumference pixels, so that I get an impenetrable circle?
Here is what I started with, for circles in a coordinate-system. Basically testing each pixel in ball against this rule:
(x - x_0)^2 + (y - y_0)^2 = r^2\
I have a lot of code, the project is fairly big (by my standards) so I'm hesitant to start pasting code.
However, if you need it I could paste what I have for my "define_circle" method. -Just not sure what parts are relevant for you at this time.
Hope this makes sense to you, as mentioned, I'm not too used to posting... But I expect to be at this computer for a while, so feel free to ask even tiny follow-up questions, I should be able to respond fairly fast.
I've been learning c# and then XNA in my free time during the past few years,
browsing forums like this one and watching tutorials, and reading a bit in a few books here and there.
This is my first post anywhere asking for help, so please excuse (in advance) any noob-nes my post may contain.
I will try my best to adhere to forum guidelines.
Among many other small "learn-c#-projects" I made a fun little (win-forms!) breakout clone a year or so back.
My family enjoyed the little game, and it was rewarding at the time, to complete something that worked (almost!) as intended.
I've restarted the project in XNA, hoping to achieve a smoother, bit more advanced version.
I've got different ways of importing levels from text or pictures (or using a self made editor).
-an improvement to the last games "hard-coded" built in levels.
I've got multichannel sound for lasers and bricks breaking, as opposed to last games 1-sound-at-a-time scheme.
Things are looking good.
But I have an issue that's been bothering me for way too long now, and I seem to be stuck, losing motivation.
Its been a few months without progress...
The issue is hit-detection...
For my non-XNA version, hit detection was the standard "move, check collisions, move, check collisions" method.
As you all know, this results in occasional "overlap", where the ball in fact protrudes through things, before hit detection occurs...
For my XNA version however, I'm trying to implement "hit-prediction" (dont know a better term),
to avoid such overlap / semi-poor hit-detection.
The idea is, that every time a change occurs for the ball (i.e. its launched, or it bounces off something)
It scans ahead, considering direction and velocity, and predicts when collision should occur, instead of checking each frame...
Forgetting about bricks for now, (leaving only borders/walls and the ball), the idea I've been going with was
to define these objects in terms of lists of pixels (vectors for each containing position, and direction.)
And then testing these list items (ball-pixel-list and wall-pixel-list) against each other...
However, because power-ups and/or my preferences can change the size of the ball, The ball must have its "circumferance-pixels" defined by a method each time the game starts, or size is changed... (as only circumferance pixels are relevant to test for collisions).
So the sprite scales fine. However, compiling a list of these "circumference pixels" to be used in hit detection turns out... Hard.
I cant seem to get a complete list of pixels. There are "gaps" in the circle, allowing for "penetration".
The amount of pixels on the list does vary depending on ball diameter, but not in an immediately predictable manner.
A larger ball may claim to have fewer pixels on its circumference. hmmmm.
I've tried to adjust the tolerance levels for when a pixel is considered to be "on the line", but without much effect.
(something like "if a pixel is on the circle plus/minus one or two pixels")
Now, my methods work almost all the time (when ball diameter is 30!) , leading me to believe I'm close, but still some ball direction angle-ranges let the ball protrude through the walls a bit...
So, now that I've explained my situation, let me state the question I think I should be asking,
but please feel free to correct me...
How do I compile a complete list of ball circumference pixels, so that I get an impenetrable circle?
Here is what I started with, for circles in a coordinate-system. Basically testing each pixel in ball against this rule:
(x - x_0)^2 + (y - y_0)^2 = r^2\
I have a lot of code, the project is fairly big (by my standards) so I'm hesitant to start pasting code.
However, if you need it I could paste what I have for my "define_circle" method. -Just not sure what parts are relevant for you at this time.
Hope this makes sense to you, as mentioned, I'm not too used to posting... But I expect to be at this computer for a while, so feel free to ask even tiny follow-up questions, I should be able to respond fairly fast.