Homebrew [Release] Homebrew Launcher with grid layout

  • Thread starter Thread starter mashers
  • Start date Start date
  • Views Views 672,143
  • Replies Replies 4,218
  • Likes Likes 139
UPDATE:
Right, the following PHP script results in the UTF-8 code 233 being echoed to the browser:

PHP:
function ordutf8($string, &$offset) {
    $code = ord(substr($string, $offset,1));
    if ($code >= 128) {        //otherwise 0xxxxxxx
        if ($code < 224) $bytesnumber = 2;                //110xxxxx
        else if ($code < 240) $bytesnumber = 3;        //1110xxxx
        else if ($code < 248) $bytesnumber = 4;    //11110xxx
        $codetemp = $code - 192 - ($bytesnumber > 2 ? 32 : 0) - ($bytesnumber > 3 ? 16 : 0);
        for ($i = 2; $i <= $bytesnumber; $i++) {
            $offset ++;
            $code2 = ord(substr($string, $offset, 1)) - 128;        //10xxxxxx
            $codetemp = $codetemp*64 + $code2;
        }
        $code = $codetemp;
    }
    $offset += 1;
    if ($offset >= strlen($string)) $offset = -1;
    return $code;
}

$text = "é";
$offset = 0;
while ($offset >= 0) {
    echo ordutf8($text, $offset);
}

According to the following table, 233 is the HTML encoding of the unicode character 'é':
http://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=dec&unicodeinhtml=dec

So I guess I could use this method if I can also do the same conversion in C (i.e. from the character in the string to the UTF-8 HTML code equivalent). That way the two values should match. If anyone knows of a method for doing that then I'd be grateful!
 
  • Like
Reactions: AtlasFontaine
Oh bad news for you, we're using ansii c, only knows a character set of 127 characters, you'll need to write your own conversion function manually
 
Actually I forgot to say that logging the integer value of 'é' in C results in a different value entirely so it's not compatible.

However, while driving to a client's house I realised something. The UTF-8 character is two bytes instead of one byte for an ASCII character. C is interpreting this as two separate characters, hence the reason why attempting to draw é results in two ? symbols.

The PHP function above to get the code for a UTF-8 character seems to work by checking if the value returned by ord() is within the range of a UTF-8 character. If it is then it takes the ord() value of the next byte and uses them both to calculate the correct value.

If casting the char 'é' to an int returns the same value as PHP's ord() then I should easily be able to port the PHP function to C to get the value matching to work.
 
Yup. I'm seeing the problem with the time too. Also, the custom font is way too big on the top screen, specifically on the title.
"3ds_homemenu_extdatat"
"blargSnes -- SNES emulat"
"Mednafen/Beetle PCE FA"

Re. the font, I know the layout and sizes aren't ideal. I'm still working on it. Thanks for the feedback.

@mashers: I have a suggestion for that issue. What about if you implement some title scrolling way and then hold the same font size?
 
Just thought I'd tease you guys with the most recent 'roboto update', come custommade simplistic icons for added groove!
Keep it up, mashers, what you are doing is powerful. :)

MrLTw1h.jpg
That portal icon! *fapping emotion icon* share you icon pack!
 
So, would that mean logging the values (from C) of all the characters I want to include and then adding them manually to the PHP conversion script so they match? Or is there another way of converting the keymap?
 
I don't think there is a simpler way for you, however, you could also user rxtools font system, i think they support é
 
Ok this is strange. PHP says that the two bytes of é are 195 and 169:
...
but C says that they are -61 and -87

Not so strange if one is using a signed byte and the other an unsigned. Try yourself to convert the two values in a base 2 (i.e. bits) number.

The char type can be signed or unsigned depending of the compiler/enviroment.

Try an explicit cast.
 
Not so strange if one is using a signed byte and the other an unsigned. Try yourself to convert the two values in a base 2 (i.e. bits) number.

The char type can be signed or unsigned depending of the compiler/enviroment.

Try an explicit cast.
Could you give an example? I tried changing the printf line in the sample C code to cast the char as an unsigned int, but it made no difference to the values printed.

Code:
printf("Character %d: %d\n", i, (unsigned int)c[i]);
 
I don't have the solution, I was only trying to give an hint.

BTW try:

Code:
printf("Character %d: %u\n", i,(uint8_t)c[i]);
OMFG, that solved it. Thank you!!!!!

http://codepad.org/KunnXIEF

This now returns the same values as PHP for the two bytes of the UTF-8 character. I can now get the font converter to export using the same values as are needed for the font to be recognised by the launcher, so Unicode characters should work now. Thank you so much!!!!!
 
  • Like
Reactions: ashinnblunts
Ok this is strange. PHP says that the two bytes of é are 195 and 169:
but C says that they are -61 and -87:

195 unsigned is -61 signed.
169 unsigned is -87 signed.

Instead of char, use the u8 type, which is basically the same as uint8_t, but a standard for 3ds (and gamecube) for buffers. But it shouldn't matter if it is signed or unsigned, since the value is actually the same, just interpreted in a different way (but you already know that).

By the way, extended ascii should provide enough for the most used characters on a single byte, but smdh files use all 2 bytes for text since they should be compatible with japanesse encoding (and others I guess).

Have you checked the unicodeToChar() function in utils.h?

edit: woops, you already solved it.
 
@mashers I tested out the new update and now I can see all the folders but it takes a lot of time to show them. I took a quick video to show you the problem.

 
Last edited by JJTapia19,
@mashers I tested out the new update and now I can see all the folders but it takes a lot of time to show them. I took a quick video to show you the problem.


I think somebody else had that problem and they solved it by backing up their SD, formatting and re-copying all the data.

I've just ported the PHP UTF-8 decoder to C:

http://codepad.org/mqiejVv3

This outputs the same value for é as the PHP script, so now all that should remain is integrate the decoding code into the font engine and the font converter, re-convert the font and test. But that will be a job for tomorrow as I'm exhausted now.
 

Site & Scene News

Popular threads in this forum