[program-l] Re: Again - determining/calculating coordinates/routes/pathways, accurately/consistently..?
- From: Soronel Haetir <soronel.haetir@xxxxxxxxx>
- To: program-l@xxxxxxxxxxxxx
- Date: Thu, 30 May 2013 08:40:01 -0800
Pixel size is not particularly related to the screen resolution. The
resolution gives the total number of pixels, but the pixel size is a
matter of individual pixels. On most displays I am familiar with
pixels are taller than they are wide, and thus to draw what appears to
be a circle (or square for that matter) it has to be scaled. And the
same with following a 45 degree line of pixels.
If you were to simply draw a line with a 45 degree slope -- say from
(0, 0) to (x, x), it would be effected by that pixel size ratio and
thus appear at a steeper angle.
On 5/30/13, Jacob Kruger <jacob@xxxxxxxxxxxxx> wrote:
> It's more to do with that whereas I would expect something like a 45 degree
>
> travel angle to travel exactly 1*1 on a sort of axis affecting scale, it
> seems to get slightly off-track when not using clean angles as such, and,
> seems to come down to that should store underlying coordinates at a
> higher/more precise level, and just drop them down to simpler/lower levels
> before then rendering the display coordinates as such.
>
> And, yes, a sighted person already told me the ball does seem to sometimes
> be moving in small steps, but, for that one I could drop the movement
> increments/units down to single pixels, and speed up the display
> manipulation loop time, instead of the 2 pixels I am currently playing
> around with, etc.
>
> Lastly, on average your screen would be displaying roundabout an additional
>
> quarter dimension of pixels in a horizontal plane as vertically - 1024 *
> 768, but, I think your average physical display screen uses a slightly
> different aspect ratio, which could affect this, but, my issue is more
> related to calculations seem to be drifting off their levels of accuracy -
> most likely due to me rounding results down to simpler integers to be used
> for both output/display, as well as then to be made use of for next bit of
> calculation, etc.
>
> Stay well
>
> Jacob Kruger
> Blind Biker
> Skype: BlindZA
> '...fate had broken his body, but not his spirit...'
>
> ----- Original Message -----
> From: "Soronel Haetir" <soronel.haetir@xxxxxxxxx>
> To: <program-l@xxxxxxxxxxxxx>
> Sent: Thursday, May 30, 2013 5:39 PM
> Subject: [program-l] Re: Again - determining/calculating
> coordinates/routes/pathways, accurately/consistently..?
>
>
>> Is the 'drift' in question visual (meaning that if you get a sighted
>> user to look at it it appears to drift off course) or is it instead
>> part of your calculations?
>>
>> If it is visual then I would think you are not accounting for the fact
>> that pixels are not square. They are almost twice as high on most
>> displays as they are wide. Certainly when I've drawn circles in the
>> past I had to squash them vertically in order to make them actually
>> appear circular.
>>
>> On 5/30/13, Jacob Kruger <jacob@xxxxxxxxxxxxx> wrote:
>>> Bit hard/difficult to necessarily explain, but, what with using relative
>>> pixel coordinates to then try calculate/generate relative routes, based
>>> on
>>> angles, sine and cosine functions/calculations on radians, etc., the
>>> issue
>>> am now coming across seems to be related to the fact that pixel-by-pixel
>>> movement is ssort of step-structured, so it comes down to whether should
>>>
>>> try
>>> determine all steps along the pathway, to start off with, or handle the
>>> jump
>>> calculations one little piece at a time, still basing it on the chosen
>>> navigation/traversal angle?
>>>
>>> Problem with that one is, I think the angle can sort of change as you
>>> are
>>> moving along the pathway, since you are navigating, in 2D on X and Y
>>> axes?
>>>
>>> What this seems to be doing, when I say I want to traverse something like
>>>
>>> a
>>> hypoteneuse distance of 50 pixels, at an angle of, say, 45 degrees, or,
>>> to
>>> sort of reverse it, at an angle of 317 degrees, the route seems to be
>>> drifting, to use a more common bit of terminology..?
>>>
>>> The issue with instead, trying to do something like work out a form of
>>> end-point, and then trying to split that up into chunks is that it would
>>> then require a bit more recalculation to handle possible collisions,
>>> bounces, etc., whereas if I calculate new positioning step-by-step, then
>>> it's simple enough to handle collision detection step-by-step, and then
>>> trying to handle angle changes/bounces, etc., but, like said, this
>>> step-by-step handling of route calculation seems to be causing a form of
>>> off-line drifting, or something.
>>>
>>> Hope this is making sense, and, thoughts?
>>>
>>> Here's the webpage making use of this:
>>> http://www.blindza.co.za/bzPool/index.php
>>>
>>> Lastly, what it will do is after you make a hit on the ball, it should
>>> then
>>> render a multiline textarea with sort of coordinate tracking in it, and
>>> same
>>> if you click on the angle query to query relative angle to a specific
>>> coordinate location, and, if you tell screen reader to ignore next
>>> keystroke
>>> - jaws key + number row 3 with jaws, and then hit H key, it will pop up
>>> an
>>> alert telling you coordinates of all holes on pool table, but, for
>>> example,
>>> top left is 17x17, and top right is 283x17, but, FWIW, left bounce edge
>>> is
>>> at 20 pixels, right bounce edge is at 280 pixels, top bounce edge is 20
>>> pixels, whereas bottom bounce edge is situated at 560 pixels.
>>>
>>> If you hit/bounce off an edge, it should also pop up an alert notifying
>>> you
>>> which edge, and the then resulting/new angle, etc., but, while all of
>>> this
>>> seems to work some of the time, I seem to come across the
>>> above-mentioned
>>> drifting, somewhat inconsistently, so thought could/would ask if anyone
>>> had
>>> ideas about best way to choose/decide on route calculation?
>>>
>>> And, it also comes down to that while if there was only going/meant to
>>> be
>>> like one ball on the table, then determining all the pixel/coordinate
>>> changes before any traversal would be simpler, but, what with the idea
>>> of
>>> balls bouncing into/impacting each other then passing on some of the
>>> force,
>>> at calculated angles, that's why it comes down to a sort/form of
>>> step-by-step calculation would be nicer/work more easily in that sense.
>>>
>>> Lastly, if you want to see the source, just view the source/markup of
>>> the
>>> page, since it's not really hiding anything thus far, aside from using a
>>> small bit of PHP/server-side scripting to generate some of the output,
>>> and
>>> have been trying to package/wrap at least parts of the
>>> geometric/navigatory
>>> calculations/logic into functions, etc., but, main thing is am just
>>> wondering what the best form of logical approach would be?
>>>
>>> And, also know that things like total force values, etc. aren't too close
>>>
>>> to
>>> realistic, etc. as of yet, but, am still trying to test/figure out all
>>> details, and that's also why am rendering sort of tracking/debugging
>>> text
>>> areas, etc., and will also later on try decide on/figure out a nicer bit
>>>
>>> of
>>> the interface to let people choose angles, etc. as well - something like
>>> rendering a popup rendition of complete table layout, where they can
>>> then
>>> select something like a target point on a layout matrix, after scanning
>>> surrounding details, or something, instead of using an angle selection
>>> drop-down, etc.
>>>
>>> TIA
>>>
>>> Jacob Kruger
>>> Blind Biker
>>> Skype: BlindZA
>>> '...fate had broken his body, but not his spirit...'
>>>
>>>
>>
>>
>> --
>> Soronel Haetir
>> soronel.haetir@xxxxxxxxx
>> ** To leave the list, click on the immediately-following link:-
>> ** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
>> ** If this link doesn't work then send a message to:
>> ** program-l-request@xxxxxxxxxxxxx
>> ** and in the Subject line type
>> ** unsubscribe
>> ** For other list commands such as vacation mode, click on the
>> ** immediately-following link:-
>> ** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
>> ** or send a message, to
>> ** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
>>
>
> ** To leave the list, click on the immediately-following link:-
> ** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
> ** If this link doesn't work then send a message to:
> ** program-l-request@xxxxxxxxxxxxx
> ** and in the Subject line type
> ** unsubscribe
> ** For other list commands such as vacation mode, click on the
> ** immediately-following link:-
> ** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
> ** or send a message, to
> ** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
>
--
Soronel Haetir
soronel.haetir@xxxxxxxxx
** To leave the list, click on the immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=unsubscribe]
** If this link doesn't work then send a message to:
** program-l-request@xxxxxxxxxxxxx
** and in the Subject line type
** unsubscribe
** For other list commands such as vacation mode, click on the
** immediately-following link:-
** [mailto:program-l-request@xxxxxxxxxxxxx?subject=faq]
** or send a message, to
** program-l-request@xxxxxxxxxxxxx with the Subject:- faq
Other related posts:
