Dev/Bugreports for SKKBAUI

...

I guess you should remove it. It's kinda... annoying.

No, I'll keep it, I'll just update the buttons, so the 2 buttons don't trigger when clicking once.

I've fixed the keyboard barely responding and am going to try getting the ABTN fixed. Now, it's no secret that サカキバラUI lags heavily on o3Ds or on n3DS if 4+ apps are running at once. Do I change the system, so the focussed app only is actively running, do I use proprietary BS or keep it as is? (Games on the desktop and heavily-loading moments of apps would profit from the first thing, everything from the second but is not easy-to-build at all and the third is non-optimal.) [poll=p714][/poll] Yet Another Poll For Ya

EDIT: Rephrasing it, as I am really bad at describing the moment I post a message to anywhere. ^{(There's a bug with SBFM though and I guess trinitro may not even listen but anyway)} I made a BMP to GRP tool where I can import BMPs raw into SB using SBFM and convert it using my SB program. (Definetely worse than 12Me21's and trinitro21's online tool but at least it works) I've done this to convert images offline cuz I don't always get access to the internet or I'm just too lazy opening the tool to convert files by clicking all over the place.

Other news

I'm reimplementing Midori OS package support but I'll use my own code instead of Autz's because my launcher is written a lot differently and also messes up my theme packages (like the Alpha OS X fancy package). The menu settigns has finally got the 2nd sub-menu where you'll be able to change various settings of SKKBAUI. GamerCymreig has translated SKKBAUI into Welsh, UK English and a bit of Japanese in both the menu and the desktop. (I'll implement the menu's ability to read from the language packs later on.)

(There's a bug with SBFM though and I guess trinitro may not even listen but anyway)

What's the bug?

(There's a bug with SBFM though and I guess trinitro may not even listen but anyway)

What's the bug?

It seems like, as if SBFM eats the last element as the last pixel of the BMP just doesn't get rendered as the code reached the end of the DAT file. Every time I want to add a BMP to SB, I first have to append null bytes to the end to get the last pixel appear. Edit: The reported file size is correct but it ignores bytes if: IF (FILESIZE MOD 4)!=0 then ignore the bytes and end the file prematurely It doesn't like appending null bytes to the end product itself I think

(There's a bug with SBFM though and I guess trinitro may not even listen but anyway)

What's the bug?

It seems like, as if SBFM eats the last element as the last pixel of the BMP just doesn't get rendered as the code reached the end of the DAT file. Every time I want to add a BMP to SB, I first have to append null bytes to the end to get the last pixel appear. Edit: The reported file size is correct but it ignores bytes if: IF (FILESIZE MOD 4)!=0 then ignore the bytes and end the file prematurely It doesn't like appending null bytes to the end product itself I think

Yeah that's because of integers being 4 bytes and not parsing properly because of that. I'll make sure Trin's aware.

I've got some bad news regardimg サカキバラUI on o3DSs The UI is so full of functions in awkward places in complex IF cases and so forth. The short answer: I have to rewrite it (on my own) for the o3DS systems. That is gonna take around 3-4 months because school will start soon. EDIT: This also includes apps like the settimgs to be more o3DS-friendly. The launcher will be staying the same but there must be a seperate desktop code for o3DSs.

I've got some bad news regardimg サカキバラUI on o3DSs The UI is so full of functions in awkward places in complex IF cases and so forth. The short answer: I have to rewrite it (on my own) for the o3DS systems. That is gonna take around 3-4 months because school will start soon. EDIT: This also includes apps like the settimgs to be more o3DS-friendly. The launcher will be staying the same but there must be a seperate desktop code for o3DSs.

Well, I think... Instead of just the desktop, why not just disribute it as a seperate version. It will be in the same download but the setup chooses the pack dependimg on the 3DS model (using HARDWARE). Maybe that'll give more power to o3DS users

I've got some bad news regardimg サカキバラUI on o3DSs The UI is so full of functions in awkward places in complex IF cases and so forth. The short answer: I have to rewrite it (on my own) for the o3DS systems. That is gonna take around 3-4 months because school will start soon. EDIT: This also includes apps like the settimgs to be more o3DS-friendly. The launcher will be staying the same but there must be a seperate desktop code for o3DSs.

Well, I think... Instead of just the desktop, why not just disribute it as a seperate version. It will be in the same download but the setup chooses the pack dependimg on the 3DS model (using HARDWARE). Maybe that'll give more power to o3DS users

And make it so the n3DS version locks out o3DS users, in case somebody edits the setup to install the n3DS version no matter what version of 3DS they are using?

And make it so the n3DS version locks out o3DS users, in case somebody edits the setup to install the n3DS version no matter what version of 3DS they are using?

That sounds completely unnecessary. They have to edit the code to install the N3DS version in the first place, so why bother locking O3DS users out if they want to use the N3DS version? It's not recommended, but at the end of the day it's their choice.

(Maybe not the best idea but anyways) I can translate the OS to spanish. Thats my native language.

...

Well, I think... Instead of just the desktop, why not just disribute it as a seperate version. It will be in the same download but the setup chooses the pack dependimg on the 3DS model (using HARDWARE). Maybe that'll give more power to o3DS users

And make it so the n3DS version locks out o3DS users, in case somebody edits the setup to install the n3DS version no matter what version of 3DS they are using?

I let the setup decide, whether to use the o3DS or n3DS version depending on the HARDWARE value which is perfect for this purpose. Locking out is useless as these people editing will see on their own that modifying may render サカキバラUI not really usable (considering they use o3DS and try n3DS), removed features or completely different use.

I can translate the OS to spanish. Thats my native language.

That's why there's a special slot for languages like Spanish. Ready to be taken. Just copy the english pack, rename it to LANG_ES.LNG and use the language pack editor. The first srring for thst pack should be "ES" (If you don't know the

controls

While choosing a string: L - Choose a language pack to load (Lose unsaved changes) R - Save file A - Select string Up/down on D-Pad: Move cursor B/X/Y are for dev purposes and shouldn't be used as it messes up the text in the desktop. While editing a string: X - Clear that space and copy to clipboard R - Insert text from clipboard A - Keep changes for save B - Discard changes (restore what was there before) Left/Right on D-Pad: Move cursor through text

) Oh, not to forget: The SMD files have to be translated individually using the SMD creation tool. (I know, it's not nice but at least you can tell me to leave these in English if you aren't interested in translating those.) EDIT 2: Speaking of, should I revise the language packs, so I can embed help information for certain strings as GamerCymreig had a few problems too.

Example

st,nd,rd,th,th,th,th,th,th,th,th,th,th,th,th,th,th,th,th,th,st,nd,rd,th,th,th,th,th,th,th,st ^ You understand this? If not, these are the endings for ordinal numbers for 1st to 31st. If it's universal, like German, a simple dot or whatever is ok.

Keyboard on o3DS

If you've looked into the IMAGERES.DLL you might have spotted the big spot in the spritesheet that says "User graphic area" (UGA) Originally, I wanted to include sprites to SKKBAUI but kinda refused to. This is not going to be utilized on o3DS cuz this space is absolutely perfect for the performance issues that o3DS have. Spoiler alert: It was the keyboard along with other small things I am going to use a sprite-based keyboard, like Midori but keep the clean design of the graphic keyboard. Whether I'll be able to reproduce the keyboard using sprites including its features is currently A GAME THEORY however. The o3DS may lag a little bit for a frame or two when switching keyboard layouts though as I need to get it to read from the same list as the graphic keyboard but only once instead of constantly.

^ Speaking of, some new keyboard layouts are coming soon, including:

Spoiler

- A layout like on a simple calculator - A simple Number pad - Japanese keyboard (like the area from SB's keyboard) for o3DS

I'll include some APIs to switch keyboard layouts to those if they are needed in some way.

How to reproduce:

• Set the theme to WinXP
• Open About OS
• Click on the desktop

I assume this is because the dialog box takes data from the theme (in this case, the coloring). Workaround: None (yet?)

How to reproduce:

• Set the theme to WinXP
• Open About OS
• Click on the desktop

I assume this is because the dialog box takes data from the theme (in this case, the coloring). Workaround: None (yet?)

Ah, I see. It's not that strange. I forgot to reset GCOLOR after drawing the base of the start button:

DEF DSG_00000001_StartButtonPre:GCOLOR #LIME:...

The GCOLOR didn't get reset afterwards.

...

Well, I think... Instead of just the desktop, why not just disribute it as a seperate version. It will be in the same download but the setup chooses the pack dependimg on the 3DS model (using HARDWARE). Maybe that'll give more power to o3DS users

And make it so the n3DS version locks out o3DS users, in case somebody edits the setup to install the n3DS version no matter what version of 3DS they are using?

I let the setup decide, whether to use the o3DS or n3DS version depending on the HARDWARE value which is perfect for this purpose. Locking out is useless as these people editing will see on their own that modifying may render サカキバラUI not really usable (considering they use o3DS and try n3DS), removed features or completely different use.

I can translate the OS to spanish. Thats my native language.

That's why there's a special slot for languages like Spanish. Ready to be taken. Just copy the english pack, rename it to LANG_ES.LNG and use the language pack editor. The first srring for thst pack should be "ES" (If you don't know the

controls

While choosing a string: L - Choose a language pack to load (Lose unsaved changes) R - Save file A - Select string Up/down on D-Pad: Move cursor B/X/Y are for dev purposes and shouldn't be used as it messes up the text in the desktop. While editing a string: X - Clear that space and copy to clipboard R - Insert text from clipboard A - Keep changes for save B - Discard changes (restore what was there before) Left/Right on D-Pad: Move cursor through text

) Oh, not to forget: The SMD files have to be translated individually using the SMD creation tool. (I know, it's not nice but at least you can tell me to leave these in English if you aren't interested in translating those.) EDIT 2: Speaking of, should I revise the language packs, so I can embed help information for certain strings as GamerCymreig had a few problems too.

Example

st,nd,rd,th,th,th,th,th,th,th,th,th,th,th,th,th,th,th,th,th,st,nd,rd,th,th,th,th,th,th,th,st ^ You understand this? If not, these are the endings for ordinal numbers for 1st to 31st. If it's universal, like German, a simple dot or whatever is ok.

Keyboard on o3DS

If you've looked into the IMAGERES.DLL you might have spotted the big spot in the spritesheet that says "User graphic area" (UGA) Originally, I wanted to include sprites to SKKBAUI but kinda refused to. This is not going to be utilized on o3DS cuz this space is absolutely perfect for the performance issues that o3DS have. Spoiler alert: It was the keyboard along with other small things I am going to use a sprite-based keyboard, like Midori but keep the clean design of the graphic keyboard. Whether I'll be able to reproduce the keyboard using sprites including its features is currently A GAME THEORY however. The o3DS may lag a little bit for a frame or two when switching keyboard layouts though as I need to get it to read from the same list as the graphic keyboard but only once instead of constantly.

^ Speaking of, some new keyboard layouts are coming soon, including:

Spoiler

- A layout like on a simple calculator - A simple Number pad - Japanese keyboard (like the area from SB's keyboard) for o3DS

I'll include some APIs to switch keyboard layouts to those if they are needed in some way.

Well... Honestly I don't know how to use the language pack editor. _{What IS this thing?}

Well... Honestly I don't know how to use the language pack editor. _{What IS this thing?}

It is a kind of text editor. The controls stand right there. The [Add string] as well as appending x lines or removing them requires a special dialog box to be pressed "OK" on but they aren't useful for anyone except me. To start: - Launch it - Press L and select LANG_EN_US.LNG - Press R and then B and replace the "_EN_US" to "_ES". This will copy the file and let you work on it. - Change the first string from "EN" to "ES". - Go ahead and translate. You can take your time on that. TBH I don't know why it's difficult to use as I think it's straightforward to use.

I've got the sprite keyboard working. Was pretty easy and the best part. It doesn't lag. I still need to implement stuff before making a public test. (I'm thinking... why not just use this version for both o3DS and n3DS?)

I replaced the fatal error screen with this screen. This works well on o3DS as well. I've also improved all other menus for o3DS and can release a beta for o3DSs in a few days.

Size comparison

A single character definition is 132 bytes big, compared to ~272 bytes. RGames, and anyone else who wants to use my XCMD.LIB library with this size change, can ignore it and wait for my next update if the size being ~10x smaller is wanted. (Note: These first value below is not correct because I use an old XCMD.LIB from the download and compare that to the new XCMD.LIB's CFD fonts which have new character definitions in them. I simply forgot to back up the 2nd-latest version and *poof*, it's gone.) Old FNT instruction: 656111 Bytes (640,7KB) for 6 fonts All 5 CFD files with 6th font embedded*: 434684 Bytes (424,5KB) All 5 CFD files without 6th font: 293884 Bytes (287,0KB) Add a 6th CFD to total size: 322924 bytes (315,4KB) _{* The 6th font was used in all other fonts, making my files are ~26KB larger than expected but I'll make it a new font pack for that to reduce the sizes to the calculated size above} A simple LOADCFD command which takes a similar attribute to FNT will load the data and FONTDEF the content. FNT will just be a shorthand now that points to LOADCFD to keep backward compatibility with old SKKBAUI programs, including the SKKABUI menu