Rockbox

Tasklist

FS#9270 - moonrock, calculates the current moonphase.

Attached to Project: Rockbox
Opened by federico pelupessy (fip) - Tuesday, 12 August 2008, 21:09 GMT
Last edited by Bertrik Sikken (bertrik) - Thursday, 28 July 2011, 10:10 GMT
Task Type Patches
Category Plugins
Status New
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

this is a simple plugin called 'moonrock' which shows the phase of the
moon. It is not the most earthshatteringly original thing but nevertheless the effect is pretty nice. Hopefully someone else likes this!

For targets with CONFIG_RTC, it either shows a text description
or, for HAVE_LCD_BITMAP and at least greyscale targets, a (pre-calculated) picture of the moon. But only if the data file (moonrock.dat) is present and found in the apps/ directory. (it should be attached to this post, I hope it shows up here, as the file is 3MB). (time of the player is assumed to be GMT)

you can switch between picture and text with select button, and choose a new date with play (which does not change the internal clock).

The patche changes some small things in the api and in the bitmap reading routines to be able to do things easily.
This task depends upon

Comment by federico pelupessy (fip) - Tuesday, 12 August 2008, 21:16 GMT
oops - the file moonrock.dat does not upload..

I have included it here split in two:

on linux systems:
cat moonrock.dat.aa moonrock.dat.ab > moonrock.dat
fixes the data file...
Comment by Jonas Häggqvist (rasher) - Tuesday, 12 August 2008, 21:43 GMT
I don't understand the #define LINEBUFFER 320?

What's the reasoning behind the value 320?
Comment by federico pelupessy (fip) - Tuesday, 12 August 2008, 22:03 GMT
I noticed that the read in of the bmp was limited to the target size. I increased it from LCD_WIDTH because 320 is the widest of any target (I think), then you can read in this size and scale down bmp with smooth_resize on other targets. (this could be a often occuring use of resize). (the dat file actually is patched together bmp)
Comment by Jonas Häggqvist (rasher) - Tuesday, 12 August 2008, 22:13 GMT
The M:Robe 500 has a 640x480 screen. I really don't think we want to allow this size for all targets.
Comment by federico pelupessy (fip) - Tuesday, 12 August 2008, 22:24 GMT
hmmm, I see.
It is worthwhile, though, to consider increasing the size allowed by the buffer in the read_bmp routine.
(also, the buffer is for one image line: the penalty is not the full image size)
Is there another way to read in bmp with sizes bigger than the screen?
Comment by Jonas Häggqvist (rasher) - Friday, 05 December 2008, 04:11 GMT
Seems simpler to just pre-generate bitmaps, use Rockbox' bitmap build system, and use LCD_WIDTH for LINEBUFFER.
Comment by federico pelupessy (fip) - Sunday, 07 December 2008, 23:47 GMT
use of pregenerated bitmap is limited by the plugin memory, 512 Kb I think..

btw, I guess one could adapt the read_bmp_fd file to read blocks of limited size (=LCD_WIDTH),
but repeatedly, along the lines of the included patch.

Comment by Rosso Maltese (asettico) - Monday, 03 August 2009, 16:27 GMT
I tried to re-sync the patch.
It's possible that all the affected files but moonrock.c are ok.
moonrock.c it seems to be too much far from the actual svn sources, so I'm not able to re-sync it.
Any volunteers? ;-)
Comment by Teruaki Kawashima (teru) - Wednesday, 05 August 2009, 15:07 GMT
I tried to sync moonrock.c. it showed something but i don't know this is valid chage.
Comment by Rosso Maltese (asettico) - Thursday, 06 August 2009, 13:57 GMT
Great! It works nice. Thank you.
Comment by Rosso Maltese (asettico) - Saturday, 17 October 2009, 11:19 GMT
Sync to r23223.
Comment by Marek Niemiec (DB1BMN) - Tuesday, 29 December 2009, 20:23 GMT
Hello,
ok, I was able to apply the patch for the current release and it seems to work so far and nicely.
But you should mention, thet the patch has to be applied from the /rockbox/-Project directory and has to be run with the -p0 parameter.
I had to copy the moonrock.dat manually to the /.rockbox/rocks/apps-directory on my player to see the moon picture. Is that correct?
I am very interested in further development of this rock. I plan to do some extensions of displaying the calculations.
More soon (tonight?)
Comment by federico pelupessy (fip) - Wednesday, 30 December 2009, 11:53 GMT
Hi Marek,

that is correct - the picture data is relatively big so had to come seperately
(lately a png decoder has been added to rockbox, so this may be improved)

note also: since syncing to r23223.(but maybe earlier) it may corrupt
music playback (after pausing music after running the plugin), so some
debugging/improvement is definitely needed....

cheers..
Comment by Marek Niemiec (DB1BMN) - Thursday, 31 December 2009, 00:25 GMT
Hello,

so far it runs. I've started to investigate the source and going to add some more informations since I am very interested in astronomical calculations
Here a very quick and dirty screenshot with dummy placeholders, but you should image what it does mean.
The main problem at the time, that the Rockbox-Time handler does not (?) have got an informations about time shift or time zones, but astronomical algoriths usually need at least UTC for reference.
My proposal as a workaround would be to add a .moonrockrc (run command) file where e.g. the UTC shift and font-size could be stored.
What do you think about? Are you interested in?

Regards, Marek
Comment by federico pelupessy (fip) - Thursday, 31 December 2009, 12:51 GMT
hi,

looks nice!
yes, at the moment the plugin assumes that the time zone is GMT - so time zone info would be necessary - ideally this would be something settable within the plugin..
I wonder if it's a big deal to include this in the firmware time struct....

Comment by Marek Niemiec (DB1BMN) - Thursday, 31 December 2009, 18:23 GMT
Hello,

here some more hacking effort:
* implemented UTC shift by means of julian time conversion
* implemented calculation of easter date
* implemented output of week day names and moth names
The source code needs tidy up and optimization, hat to write some own functions or workaraound, since a lot of simple mathematical functions like modf are not (?) implemented to Rockbox compiler, therefore the orgies with the castings.
Runs on Simulator for Sansa e200V1, can not compile for hardware so far :-(

Ho to apply this patch?
First apply plugins-9270moonrock3.0.patch from above. Run it from the /rockbox project directory with -p0 parameter
Then cd /apps/plugins and apply my patch. It works only on moonrock .c, do not forget to backup it with -b parameter.
run make. run make install to your simulator or copy the firmware to your player. do not forget to copy moonrock.dat to apps/plugins directory.
Ok, for the rest of the evening, let's celebrate year's change!
Regards
Comment by Marek Niemiec (DB1BMN) - Monday, 18 January 2010, 13:56 GMT
Ok, a little more improvement. Use the following patch to patch the previous plugins_9270_moonrock_3.4_20091231.patch.
Should compile on Simulator and Hardware. Added a function to print double numbers in strings, since the platform compiler does not support double output in snprintf.
Still looking forward to implement phasehunt and prediction of next phases.
Comment by federico pelupessy (fip) - Saturday, 21 August 2010, 16:50 GMT
I have created a new, cleaner version using some of the functionality that has been added to rockbox since I last looked at this!

It now uses the view text and jpg functions from the lib.

apply patch from root with patch -p0 < moonrock_21082010.patch
and copy the data file to apps/plugins/

I have put in Marek's ideas, except the easter dates calculation, can be added later...

the patch still changes 1 little api thing: it adds the set_time_screen, function for an easy dialog to obtain new dates.
Comment by federico pelupessy (fip) - Saturday, 21 August 2010, 18:05 GMT
oops - forgot the CATEGORIES file...
Comment by Bertrik Sikken (bertrik) - Tuesday, 24 August 2010, 21:33 GMT
Synced to SVN r27875 (made compatible with kugel's latest plugin changes)
Comment by Rosso Maltese (asettico) - Friday, 22 July 2011, 14:19 GMT
Sync to 30189.
My .dat file seems to be broken when I run the plugin: I need to check.
Comment by federico pelupessy (fip) - Wednesday, 27 July 2011, 21:49 GMT
Rosso:

have you checked the version of the dat file (you should use the approx 250kb one)?

(haven't had a chance to try latest rockbox)
Comment by Rosso Maltese (asettico) - Thursday, 28 July 2011, 08:39 GMT
Ops, I had not notice the new file .dat.
But not it data aborts.
The file is not a "normal" jpeg image, is it?
Comment by Rosso Maltese (asettico) - Thursday, 28 July 2011, 08:39 GMT
Sorry, I want to say: "But now it crash with data abort".
Comment by Bertrik Sikken (bertrik) - Thursday, 28 July 2011, 10:12 GMT
I (as a rockbox developer) am in favour of getting this plugin accepted into rockbox. I haven't looked closely at the coding style, but it looks fine to me (except for some indenting inconsistency).
Comment by federico pelupessy (fip) - Thursday, 28 July 2011, 21:52 GMT
I have checked using the x5l simulator - fresh chechout, applying the latest (22/7) patch, copying the dat file to apps/plugin in the source
then make. It seems to work - does it exit the plugin or does it give an error ("no image data") and go into main menu?
(the dat file is combination of jpg files and data)

I would be happy if it went into the trunk! :-)

Loading...