#541✎ 450the_squat1115First YearMy account is over 1 year oldWebsiteForum ContributorHiddenAchievementsIntermediate ProgrammerI can make programs, but I still have trouble here and there. Programming Strength
Poll will close on 20th July.
Oops. Forgot to close it. Oh well.
Alright. You decided that the Switch edition will run exclusively in direct mode.
It will hide and pause itself when going in the editor or running a program (in the main interpreter).
I may let it be changable, for further customization, but it will be done later, if I think of it again.
BTW IDK exactly how to do layers, so I just stuck 2 sprites on top of each other. They do act like layers though.
That way, the taskbar and the Whisker menu (XFCE4's start menu) are always on top.
Also, I can pull off nice animations for the session close dialog or other interrupts with sprite commands instead.
oof I didn't read the thing you said bc I was just too busy and replied fast so uh...
If you dont know how to do layers, that might be a problem.
Try getting sample codes from built-in games or something.
#542✎ 352CyberYoshi64Intermediate ProgrammerI can make programs, but I still have trouble here and there. Programming StrengthSecond YearMy account is over 2 years oldWebsiteNight PersonI like the quiet night and sleep late.Express YourselfMy Twitter post
I released the base with minor API from ミドリOS (It's not compatible with existing apps, since I changed the base a lot, such as function names and the method to draw apps.)
I still have a long way to go.
#543✎ 352CyberYoshi64Intermediate ProgrammerI can make programs, but I still have trouble here and there. Programming StrengthSecond YearMy account is over 2 years oldWebsiteNight PersonI like the quiet night and sleep late.Express Yourself(This applies to the Switch edition)
I've modified the UI basement to chamge the way, apps are drawn.
Basically, when an app is initializzed with AppInit(), it gets assigned its own playfield on the GRPs since there's a lot of room I don't need.
The function GetNewWinPos() searches for empty space in the GRP to give to the app.
Then, when the app gets to use the space I gave to it, I use 2 sprites to form the visible window on the screen.
Sprite 1 is the window border which can be used to interact with the mouse and make collisions easier.
Sprite 2 is the window canvas, basically the playfield of the app, which is displayed "inside" of sprite 1.
No, by looking for spaces in chunk sizes, it will be much faster.
This may be a mistake when very small apps are involved but I only bother to fix or mitigate this when the API is good enough for people to make their own apps.Transparent effects are possible.
The apps can be optimized by letting them only render things they needs static, only once rather than constantly. (Of course they can still render everything constantly like the 3DS version.)
When initializing or throwing away app processes, it will stop responsiveness of サカキバラUI for almost a second.
Apps will be more likely given loading times, depending on internal or external resources they need, e.g. LOADV arrays, GCOPY data from GRP4, ...
If all apps are taking more than 16ms total, they may be starting to flicker due to lack of double-buffer. (If I'd use double buffers, it'd cut the number of active apps at least in half)
About the double buffers from previous spoiler...
If I add these and apps take a full screen size, only 2 apps would be able to open.
With a small size of 64x64, it is theoratically possible to get ~24 apps open.
I kinda refuse to add a doublebuffer to apps, unless I get huge pushback or suggestions to add them.
Also, poll time yet again.