DragonMod 1.0
Status: 75%
DragonMod can now execute modules and standby. Add and Remove features are being added now.

PyroEdit III
Status: 72%
All functions have been converted to modules except for PyroMap. Some of them still need to be rewritten a little bit.

DragonMod Example Screenshot:
That last one is fully comprised of miscellaneous things, then?
Yep, and it's all in one library program.
A) When is it going to be released publicly
B) Will it have documentation about how to use it (nvm, stupid question)

Looks good! If you release it early enough, might I use it in my FE game if it will work as I hope it shall?
I need one more subroutine (Celtic is still way too big):
...I need a program that does the following to complete this project:
- Store a string into a program.
- If the program already exists on the calc, the program's current contents will be replaced with the string.
- If the program doesen't exist, it will create a new one and store the string to it.
- If the program is archived, then it will try to unarchive it and then store the string.
- If something fails, an error will be returned.

...so that when you add and remove modules from a library, it can save
the modifications back to the library program.

And [hidden]yes, there will be documentation.[/hidden]
As a trivial question, is was that done in Assembly? The ^ thing looked a bit too fast for BASIC.
Nope, it's in BASIC. However, it uses xLIB, Benjamin Moody's Error Handler, Calcmaniac's Program to String subroutine, and a fast GUI routine I made.
Insanity wrote:
Nope, it's in BASIC. However, it uses xLIB, Benjamin Moody's Error Handler, Calcmaniac's Program to String subroutine, and a fast GUI routine I made.

could i ever see the BASIC source? I'm really intrigued...
I'll pre-release it after I add in the add/remove modules functions and make a little documentation. I can do that much without needing the last subroutine (and I guess I can use Celtic for the time being).
Whatever happened to "your screwed"?
Commended performance on TAKS and the fact that I deceded to not be lazy for once and took the extra initiative to pass all my classes with a C or higher and take summer school for advancement.

After all that, all I had to do was ask, "Can I?"
DragonMod -> DragonShell
Yep, DragonMod is going to become a BASIC shell. There's no point in making it a subroutine because you'd end up having to make a front-end every time, and that would take up more space.
This should answer more questions about what it is I'm making (I should of done this in the first place):
Note: Any missed projects are here now:

A BASIC shell -- yes, I said it, and I'll say it again -- BASIC shell. What sets this off from the million of BASIC shells at Ticalc.org is that this one will run its own format of program. DragonShell programs can be designed so you can contain multiple programs in one library, saving loads of space. It will also have some kind of interface to a library of neat subroutines -- GUI controls especially -- that you can use, including skinable windows, buttons, etc:

(Masking will be done later and if it won't hurt speed too much.)

Here are two more screenshots that demonstrate the multiple programs [modules] in a library (these are from DragonMod before I stepped it up, but you get the idea):
It's getting better, even though it's a bit slower now due to the masking, and could probably use some optimizing if there's any to be done. The executor is almost done (it can run modules out of a libarary), but I still need to add DragonMod's module scanner to the API.

I forget who's avatar I'm using for the background... Razz
lol. That's Brazuc's. Make sure you change it--I'm pretty sure UTI staff won't be happy seeing their avatar being used by a guy they banned.
Status: Aborted.
XPheonix was right - there's no point in a BASIC shell.
But here's some good news...

PyroEdit III
Status: 99%
And this time, I really mean it!
PyroEdit has been toally modularized -- that's double-speak for "there's gonna be a load of subroutines," but all except for about three are "[Theta][Theta]" prefixed so they will always be at the bottom.
Lots of subroutines may sound bad, but PyroEdit and the modules I've made are quite a bit focused on saving RAM. Modules and subroutines stay in the archive; PyroEdit copies them to RAM only as needed then cleans up. Modules that use subroutines clean up whenever that subroutine won't be needed again and the module is going to do anything later that could use a variable amount of RAM.
The modularization is also good for those who want to install, make their own, or improve upon an existing module. PyroEdit assumes that any program that starts with "[Theta][Theta]PE", but does not have another [Theta] after that, is a module, and it will poll it at start-up. Developing modules is easer than developing Plug-Ins for any previous version of PyroEdit have ever been.

Here's a screenshot:

And here's a screenshot of how easy it is to make a module:

Oh, yeah, and by the way -- the TI-Connect compatibility problem got fixed in this version.
That's more programming than I've been doing lately...
What's the other 1%? Uploading? And by the way, nice job. It looks really nice. How did you get it to recognize programs that start with [theta][theta]PE as modules?
I can't wait for this to be ready! I have been using v2 for quite some time now (PacMan!).
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 4 of 5
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum