Artistic 2.0

[Harrierfalcon]

Shocked into action by PyroEdit 4.0 (and now Implicit), I've been working on Artistic 2.0.

For those watching my sig, I'm currently working on the easy parts, i.e. coding the sprite editor, etc. The projected features thus:

• Plugins, which you manually install, which add something either to the sprite or the picture editor. For specific parameters in one of my subroutines, you can't have more than 9 plugins at a time. I might add something to that subprog that allows you to have more than 9, but that's a no-go ATM.
  
• Sprite editing, any combo of 8 or 16, with sprite code generation.
  
• Picture editing, including a HUGE variety of functions and tools that I won't include for the sake of bandwidth. Suffice to say, it will cover your picture-editing needs.
  

And it's more graphical than Artistic 1.0. Look!

Sorry about the delay in typing the plugin name, I had a brain fart and forgot which key theta was. XD

Obviously, it's not that far yet, but it's getting there. Oh yeah, and whenever you see a black screen with white text like when it's loading, any text that you think would cause a domain error doesn't. Look!

[nitacku]

Nice. How'd you do the text trick? Asm?

Are you going to add support for modules?
If you do, then you'll have to watch out for when the module gets deleted or the user types in the wrong name.
I figured out a way to tell if a program exists or not using only xLIB.

Here's the algorithm:
real(10,2) //delete all exiting temp files
"name of module
real(10,0,1) //attempt to create temp file
"RET //This is the program that will run if the module didn't exist
real(10,0,1) //xLIB won't overwrite the temp if it already exists
prgmXTEMP001

With this code, you can prevent errors that would otherwise occur if the module doesn't exist.

[Liazon]

that does look pretty good.

[Harrierfalcon]

Thanks! :)

@nitacku: That's already handled (I <3 Celtic2 ). Invalid plugins, non-existing plugins, and pre-installed plugins are all working right now.

[Harrierfalcon]

Progress is being made slowly on this, I'm currently working on the sprite editor and making it both user-friendly and fast enough to be functional.

[nitacku]

Make sure you support grayscale editing, I'm going to need to create some wicked sprites. :biggrin:
Also, it would be really cool if real time grayscale editing could be turned on and off with a button.

A sprite > string command could be useful.
You could make an option to do either binary or hex.

[Harrierfalcon]

Sprite→String wouldn't be hard at all. I might include it as a plugin, IDK. However, I'm not planning on grayscale ATM...

But, I'm adding support for any range from 8*8 to 16*16 sprites.

[Liazon]

probably a good idea cuz I can't imagine using anything bigger than 16

[Harrierfalcon]

I've decided, that, rather than make it a plugin, I'm making sprite-to-[hex/binary] a standard function.

Progress is being made steadily, I've been more active here than any other of my current projects.

[Liazon]

isn't that generally very useful? i duno about basic, but for sure in ASM.

[Harrierfalcon]

I haven't really implemented it yet (I have the code, it's just not where it would be), so it is possible I could make it a plugin. I was just wary of that, because due to a constriction I have with a certain subroutine, you are limited to 9 total plugins.

[Demon]

Wow, good job -- it looks awesome!

Feel free to dig into and use some of the things in PyroEdit's cacophony of subroutines - like the sprite-to-hex part in the DCS icon generator, if you still need something for that. You could probably rewrite some of the routines I had in PyroEdit a million times better and faster in your editor.

[Harrierfalcon]

Nah, I wouldn't steal your code (except for prgmSTR2PROG) . I might peek at it to get some ideas though.

And at one of my failed attempts at making a z80 assembler, I have a bunch of subroutines that can convert anything between hex, decimal, and binary.

EDIT: After stealing some code from TI|BD, I got my menu subroutine to work a LOT faster .

[nitacku]

What kind of editors are you going to include in Artistic?

I'm going to include the ability to edit sprites, pictures, and maps in Implicit.
There must be something else that can be edited...I know, a program editor!
That would be too difficult, however, maybe not with Celtic2.

Well, I'll try to come up with some stuff to put into Implicit.
Maybe a separate category for creating modules?
Visual TI-Basic editor.

[Harrierfalcon]

Probably just sprites and pictures. But it'll be a lot more dynamic than Artistic 1.0, and a lot more useful and practical.

Funny you mention a program editor, check out my sig.

[nitacku]

Awesome!
Having a Basic IDE would make development way easier and faster.
The difficult part would be minimizing duplicate code and getting the IDE to compile structured code.
If those obstacles can be overcome, this could be the end of TI-Basic as we know it

[Harrierfalcon]

It's more of a editor than a IDE, but Exonide sounds so much cooler than Exonde. :)

It's going to have stuff like copy-and-paste (maybe multiple) lines of code, a go to line # function, a custom function menu, and perhaps a text tokenizer, so if you enter "n", "o", "t" it turns it into "not(".