As the language expands, so does the necessity to have a half decent GUI!!

-=-=-

On the main GUI, I still need to decide if I'm sticking with the style of buttons that are already there.
The Run button (The main button!) is only half the height of all the other buttons on the top of the GUI. But is it better to make the Run button bigger, or to make the rest of the icons smaller?!

At the moment, the icons are 48x48 pixels, which appears to work well enough for stumpy fingers on a touchscreen, but are oddly oversized on a desktop view.
They're also way too big when in a portrait view, as there's too many icons to fit neatly across the screen.

Additionally, that left-hand project sidebar could do with a Hide button, (another button?!!) so that the main coding area works better when in portrait mode.

Over on the Symbol side of things, I could definitely do with finishing off/starting that GUI, too. It's half abandoned, where it currently is, with a ton of functions that aren't even coded yet.
Simple drawing functions like Rect, Oval, Line, Fill are all missing.
Copy and Paste are none-existent.
Those are pretty much essential.
An undo?
Perhaps.
I'm rubbish at doing undos! (See code box)

And again, Portrait view.. Grrr..

So, yeah, that's a lot of stuff to do..

Meanwhile...

Michael Fernie isn't happy with the 32x32 pixel limit on sprites.
Obviously any bigger means those Symbol lines get even bigger, but as well as that, things aren't exactly running smoothly with oversized spritesheets as it is.
I've been trying to come up with the best method for storing the sprites, and allowing them to be nice and fast when thrown around the screen.
Lots of testing is needed on lots of devices and lots of browsers, before I'm absolutely sure on what the best method for storing and drawing the sprites will be.
Lots of tiny sprite sheets, or a few larger spritesheets?

For what it's worth, everything ingame in Browsercade uses 32x32 sprites, so.. you know.. it's not impossible!!
Just be sure to turn off AntiAlias, to keep oversized sprites crisp and clean, or it all gets ugly and blurry.

Meanwhile, Meanwhile...

A few days ago, I sifted through the Amstrad CPC command list, plucked out any commands that might be workable, and popped them into a text file.
Although that list is still about 100 items long, it's definitely shorter than it was, and has been super handy when it comes to adding features to the language itself.
I now need to dig through other BASIC variants, add more standard commands to the list, and determine differences between them all, figuring out which versions of commands should take priority. In most cases, I'll likely be airing on the side of the Amstrad, since that's the one I'm most familiar with.

C64, ZX Spectrum and BBC Micro are the main ones I'll be digging through, but I'll probably jot down some examples from more modern languages. Blitz and SmileBASIC being the obvious contenders.

There's also AMOS, but I seem to remember a lot of AMOS's structure being based around setting up objects (BOBs) and then moving them around, rather than the Blitz style of "Just draw stuff".
This is also the main difference between the Switch languages SmileBASIC and Fuze. Smile is happy to just draw images onscreen until you can't draw no more, whereas Fuze really seems to struggle doing that, and instead relies on pre-made Sprite objects.

I'm not currently going to be attempting Sprite Objects and the like. Given my horrific coding style, I expect they really won't be any better than just doing it yourself! But if I ever get to that point, I'll likely end up doing something odd and unexpected. I usually do.

.. You're waffling again, Jay!

Anyway, if you've used any specific BASIC language that I haven't yet considered, be sure to let me know what it is, and I'll look it up and see how compatible it is/could be.

Meanwhile, Meanwhile, Meanwhile....

I really need to get those Arrays working..!