Hello PGF,
.1 it is.
Seems I have .01 imbedded on the brain.
As stated previously: Can divide 3600 images by 2/3/4/5/6/8/9/10/etc to get the screen res I want. I don't 'need' 3600. With 3600 I can 'start' at any given 1/3600th of a circle and increment my way around by extracting an offset from the selected '0' point. Only have to write the file once.
A close look at an ani-file will show there is more going on that one would think. Send you one if you would like. Think the average screen has 96DPI so a 5" gauge would have ~480 pixels top to bottom. 3600/8 = 450 is as close as I can get with one pixel res. Aliasing comes into play also (hence the differences in the ani-file). A 6" tach with 360 degrees res is a bit jumpy. On a 2.5" faced gauge it is fine (and a bit of overkill). Hence the multi-res. Change screen DPI and ...
Going through what every 'newbie' does I guess. And yes .. I explore to find a products methods limitations/ features/etc. Doing so I determine/derive/guess 'why' something doesn't work. In this case .. too much info to write in X time. But I know what to do if I don't need the speed :)
The 'math' approach is in queue and have the algo in hand.
Next in line is comparing needle image at X degrees with one at X+1 and comparing the differences. Store the 'difference in pixels' starting from 0 to max-X. Array storage should be small and hopefully fast as a result. Several drawbacks to the approach (can't jump from X to X+2). Dunno if that is an issue till I try. On to the math after that.
A digital readout will be implemented also. As will a shift light for the drag racers. You (well .. me anyway) can't shift with twirling numbers well. Needle on number works.
Eikon .. thanks again. Glad to .. mmmm 'help' with work :) Your code was more compact than mine and probably work with the smaller/slower gauges just fine. Implemented the delay same as you in both cases. Same results .. which helped a lot !!
Take care all,
Jim
.1 it is.
Seems I have .01 imbedded on the brain.
As stated previously: Can divide 3600 images by 2/3/4/5/6/8/9/10/etc to get the screen res I want. I don't 'need' 3600. With 3600 I can 'start' at any given 1/3600th of a circle and increment my way around by extracting an offset from the selected '0' point. Only have to write the file once.
A close look at an ani-file will show there is more going on that one would think. Send you one if you would like. Think the average screen has 96DPI so a 5" gauge would have ~480 pixels top to bottom. 3600/8 = 450 is as close as I can get with one pixel res. Aliasing comes into play also (hence the differences in the ani-file). A 6" tach with 360 degrees res is a bit jumpy. On a 2.5" faced gauge it is fine (and a bit of overkill). Hence the multi-res. Change screen DPI and ...
Going through what every 'newbie' does I guess. And yes .. I explore to find a products methods limitations/ features/etc. Doing so I determine/derive/guess 'why' something doesn't work. In this case .. too much info to write in X time. But I know what to do if I don't need the speed :)
The 'math' approach is in queue and have the algo in hand.
Next in line is comparing needle image at X degrees with one at X+1 and comparing the differences. Store the 'difference in pixels' starting from 0 to max-X. Array storage should be small and hopefully fast as a result. Several drawbacks to the approach (can't jump from X to X+2). Dunno if that is an issue till I try. On to the math after that.
A digital readout will be implemented also. As will a shift light for the drag racers. You (well .. me anyway) can't shift with twirling numbers well. Needle on number works.
Eikon .. thanks again. Glad to .. mmmm 'help' with work :) Your code was more compact than mine and probably work with the smaller/slower gauges just fine. Implemented the delay same as you in both cases. Same results .. which helped a lot !!
Take care all,
Jim