Hooray!!! Rockchip SDK!

[knob]

Originally Posted by flasher86

- unicode works
- faster drawing of chars. Surprisingly antialiased font is not slower than the standard one as it suppose to be. I even managed to make it faster than standard platform 1bpp font by loading the binary font into SDRAM and accessing it from there instead of the resource file.

Looks good now. Would it be able to handle a slightly bigger font than the 16 size do you think? say 18 or 20, I think it would look even nicer.

Regards
knob

[flasher86]

Of course, you can load as many fonts as you wish, different sizes, faces, styles. My drawing function just require offset to the resource file where the binary font is stored. I made a special format for this font, to speed up the loading. I will release a tool for converting fonts into my format (is 99% done). Though it's not native. It converts exported font from AngelCode Bitmap Font Generator (a freeware tool which generates bitmap fonts from system TrueType fonts). In my tool you just open exported font, and it creates one bin file which you can add to RKP resources and its done.

I created this thinking of RTF reader where I could convert a bunch of different fonts and sizes so there will be no problem for displaying formatted text - while I change the offset to different font it will draw it as normal, without any special config (all necessary info is stored in binary font ex. widths of chars, line-height and such).

[WIZARD]

Originally Posted by flasher86

New update of my tests:
Attachment 526

- has background, it is more visible how alpha transparency works, as well as antialiased fonts.
- scrolling of the whole list of files using up/down buttons
- here you also can hit menu to load bitmap.bmp (one sample 32bpp included in package)
- unicode works
- faster drawing of chars. Surprisingly antialiased font is not slower than the standard one as it suppose to be. I even managed to make it faster than standard platform 1bpp font by loading the binary font into SDRAM and accessing it from there instead of the resource file.

this scrolling works similarly to the one from firmware, though I think I will make something more smooth, like preloading into SDRAM the whole bitmap in which the file list had been drawn, this will enable to extremely fast and smooth pixel by pixel scrolling of the file list, not file by file like this.

EDIT:
I've noticed something great!! By default rock compiler does not use auto optimization (there are 3 options), but only one option really optimize it, and its nr 2, but I didn't use that because I got message that licence has expired, just out of curiosity I changed the system date to test this optimization, and it really stunned me! Length of the code has been reduced from 0x365a to 0x1cc2. Maximum allowed is 0x5000 so its amazing! I feel like a dumbass worrying about every single byte of code. We can do so much :-D

This application is faster than the embedded image viewer!

Possible improvements: scroll bars, the ability to open folders;
and (maybe) the ability to select the image files and open them -
it'll be the good base for document viewer's dialog.

[flasher86]

Yes, that's what I am working on :-) I want to release really well working package as a good start for developing fully functional applications. I just need a little more time and I will upload it here on this very site. I know my first challenge in this will be RTF reader, I hope that other people will also find it interesting and use it in creating their own apps ;-)

[sig11]

Originally Posted by flasher86

New update of my tests:
Attachment 526

By default rock compiler does not use auto optimization (there are 3 options), but only one option really optimize it, and its nr 2, but I didn't use that because I got message that licence has expired, just out of curiosity I changed the system date to test this optimization, and it really stunned me!

I hope this patch will helps you:
***
C:\Program Files\RockTools\RockCompiler\sdspI\bin>fc /b sdopt.exe.bak sdopt.exe
Comparing files sdopt.exe.bak and SDOPT.EXE
0001FEE0: 55 90
0001FEE1: 8B 90
0001FEE2: EC 90
0001FEE3: 51 90
0001FEE4: 51 90
0001FEE5: 8D 90
0001FEE6: 45 90
0001FEE7: F8 90
0001FEE8: 50 90
0001FEE9: FF 90
0001FEEA: 15 90
0001FEEB: 10 90
0001FEEC: 52 90
0001FEED: 4A 90
0001FEEE: 00 90
0001FEEF: 8B 90
0001FEF0: 45 90
0001FEF1: F8 90
0001FEF2: 8B 90
0001FEF3: 4D 90
0001FEF4: FC 90
0001FEF5: 6A 90
0001FEF6: 00 90
0001FEF7: 05 90
0001FEF8: 00 90
0001FEF9: 80 90
0001FEFA: C1 90
0001FEFB: 2A 90
0001FEFC: 68 90
0001FEFD: 80 90
0001FEFE: 96 90
0001FEFF: 98 90
0001FF00: 00 90
0001FF01: 81 90
0001FF02: D1 90
0001FF03: 21 90
0001FF04: 4E 90
0001FF05: 62 90
0001FF06: FE 90
0001FF07: 51 90
0001FF08: 50 90
0001FF09: E8 90
0001FF0A: B2 90
0001FF0B: 37 90
0001FF0C: 00 90
0001FF0D: 00 90
0001FF0E: 8B 90
0001FF0F: 4D 90
0001FF10: 08 90
0001FF11: 85 90
0001FF12: C9 90
0001FF13: 74 90
0001FF14: 02 90
0001FF15: 89 90
0001FF16: 01 90
***

[sig11]

Originally Posted by flasher86

To run rkp files from sd card in my player, I just need to open some dir in sd card so it gets switched to sd card media (as only one of two can be accessed at a time). And then I exit and click game, and it reads them from sd card now. Do you get the same? Coz its the only way to do the whole thing.

Try to use :

DSTATUS disk_initialize (BYTE disk)
{
write_mem(CLOCK_PWRCON,read_mem(CLOCK_PWRCON) | 0x4);
printf("disk_initialize(%d)\n",disk);
return RES_OK;
}

before work with SD

[flasher86]

I used that mem addres for this:
#define RUN_FROM_SD (read_mem(CLOCK_PWRCON)&0x04)>>2
if run from sd, its value is 1, if from flash its 0.

What does your function do? Because all I need is to check from which drive it has been initialized (and my function above does it). If from flash, it shows my warning message or something like that

btw, what does this patch do? It takes off the license check or something?

[sig11]

Originally Posted by flasher86

As I said, long names can be done, unfortunately support for file system doesnt work from SDK so I implemented this FatFS opensource lib for this.

I have commented this condition and LFN are working in my sample

file ff.c :

#if _USE_LFN
if (fno->lfname) {
TCHAR *tp = fno->lfname;
WCHAR w, *lfn;

i = 0;
if (dj->sect /* && (dj->lfn_idx != 0xFFFF) */ ) {/* Get LFN if available */
lfn = dj->lfn;
while ((w = *lfn++) != 0) { /* Get an LFN char */

[sig11]

Originally Posted by flasher86

btw, what does this patch do? It takes off the license check or something?

It replaces function time() to NOP's

[flasher86]

Originally Posted by sig11

Try to use :

DSTATUS disk_initialize (BYTE disk)
{
write_mem(CLOCK_PWRCON,read_mem(CLOCK_PWRCON) | 0x4);
printf("disk_initialize(%d)\n",disk);
return RES_OK;
}

before work with SD

oh maan. It works now!! It can access SDCard while being executed from flash! If only we had access to flash memory we could even transfer files between these two drives.

Also, it runs so much faster if run from flash! Awesome, you re good. Maybe you have some ideas about flash memory then?