> Am 18.04.2018 um 14:31 schrieb H. Nikolaus Schaller <h...@goldelico.com>: > > Hi all, > >> Am 18.04.2018 um 08:20 schrieb H. Nikolaus Schaller <h...@goldelico.com>: >> >> Hi Sebastian, >> >>> Am 17.04.2018 um 21:45 schrieb Sebastian Krzyszkowiak <d...@dosowisko.net>: >>> >>> On Tue, Apr 17, 2018 at 9:09 PM, H. Nikolaus Schaller <h...@goldelico.com> >>> wrote: >>>> >>>> Am 17.04.2018 um 21:05 schrieb H. Nikolaus Schaller <h...@goldelico.com>: >>>> >>>> Hi Sven, >>>> >>>> Am 17.04.2018 um 16:31 schrieb Sven Dyroff <s.dyr...@phytec.de>: >>>> >>>> Hello Nikolaus, >>>> >>>>> It looks as if it is much more often reporting accelerometer events (ca. >>>>> 15ms) than the 4.16 kernel (ca. 100-200ms). >>>> >>>>> But neither change has the effect of making the graphics faster and >>>>> smoother. >>>> >>>>> So there is likely a third factor involved when comparing to GTA02. >>>> >>>> no, I think you've found the cause! >>>> >>>> 100-200ms results in a frame rate of 5 to 10 Hz which is awfully slow! >>>> >>>> >>>> Unfortunately no. Would be too simple... >>>> >>>> There is a background thread that reads the accelerometer every now and >>>> then >>>> and >>>> simply returns the last value each time it is called. So these speeds are >>>> completely >>>> decoupled! QtMaze does not see any delay in code when calling getacx(). >>>> This >>>> returns the value of a global variable that is updated by the background >>>> thread. >>>> >>>> The accelerometer delay can only be recognized by a delayed reaction but >>>> has no influence on the frame rate. So graphics should not have small jumps >>>> if >>>> you don't move the device... >>>> >>>> So we still have to dig deeper into it... For example someone could look >>>> into the sources of QtMaze how the display redrawing is done. >>>> >>>> >>>> It is here: >>>> >>>> http://git.goldelico.com/?p=gta04-qtmoko.git;a=tree;f=src/3rdparty/games/qtmaze;h=38f4df583bba2a4712baf40915bc0026fb16dc8d;hb=398d5c957571fed6b63174cfd2e4b6d57aeff9a4 >>> >>> From a quick glance at the code (form.cpp) is looks like the ball is >>> moved only in the MoveBall method, which is called only in the >>> callback from accelerometer thread (and in some other function too, >>> but that function is also called only from that same callback). >>> In the library, accel_work (the accelerometer thread) calls >>> accelerometer_moo in a while loop until it gets a measurement and only >>> then calls the QtMaze's callback, which seems to be the only way to >>> actually update the ball's position. >>> >>> It shouldn't really work that way, and I there's a possibility that >>> I'm mistaken since I just had a few minutes look into a codebase I >>> never seen before, but it does really seem that by lowering the >>> accelerometer read rate you'll get lowered ball movement frame rate in >>> QtMaze :) >> >> Thanks for looking into this! >> >> Well, if your analysis is right, then QtMaze was developed on the >> false assumption that accelerometer callbacks come in fast and well >> clocked steps. >> >> But the kernel and the accelerometers.cpp try their best to filter >> out unneeded callbacks... >> >> Well, I have a simple idea for a fix: remove the dependency of calling the >> callback from really having received new data from the kernel. >> >> I.e.: >> >> while ( !(my_thread_data->finished) ) { >> >> /* Call accelerometer_moo() until we have an >> acceleration measurement. */ >> accelerometer_moo(accel); >> >> /* If the library user specified a callback, call >> it. */ >> if (my_thread_data->callback) >> (*my_thread_data->callback)(my_thread_data->closure, >> acx, acy, acz); >> /* Sleep before taking another measurement. */ >> usleep(my_thread_data->interval_us); >> } >> >> So we do not call accelerometer_moo() until we have a measurement >> but we call it once every interval_us. And do the callback once. >> >> This should then become the timer triggering a redraw and should >> be almost equidistant. >> >> It is then the same as for the GTA02 code which calls the callback once >> per loop... > > Ok, this works. The ball is now moving fast like hell... > IMHO too fast, but it now looks like with the GTA02 video. > > Same on the Pyra, but there, ball movements get completely stuck > after some seconds. evtest /dev/input/accel still reports events > and QtMaze still is responsive to the touchscreen, but no longer to the > accelerometer. So this is some other bug... > > I'll now push the update to the server. Please try an apt-get upgrade in > some hours (should load & install qtmoko-gta04_60.20180418-1_armhf.deb ).
And here is a new video: https://youtu.be/DSbuXz_EZTo _______________________________________________ Gta04-owner mailing list Gta04-owner@goldelico.com http://lists.goldelico.com/mailman/listinfo.cgi/gta04-owner
