I guess I will need to stop development of this program until I get a useable TI.
There is a chance that I can buy one from our school or one from my classmate, so possibly I will be able to continue soon again...
Sorry for that, people!

I mamaged to get a TI now, I will continue this project soon. But right now I have had not enough time...
Sorry for the delay!

I am very excited that you manage to get one! How did you do that? Did you buy one from your school? I look forward to the further development of this project.

No, my friend gave me one for free

And about the project: Currently I am working on a Flyer for our chess club, this won't take that long, but maybe a week or so... After that I will continue again (Cursing Basic once again because of the missing possibility to add comments) .

Ahh, to add "comments" in basic, just put the comment in a new line in quotes, like this:

:Some Code
:"Your Comment Here
:More Code

This will add a few cycle to the execution of the program, and it sets Ans to a string of your comment, but it works.

Thanks for the trick, but I prefer not to do this as it is easy to confuse with a regular string when scrolling fast and it is hard to filter that out when releasing the program. Anyways, some time ago, I wrote a small program which added readability to Basic, it allowed multiple letter variables and labels, and adding comments. Then it compiled the program to regular basic...
I will try to find it somewhen later.

Okay. So I am glad to announce I am continuing this project!

The first thing I will probably do is make my calculator work properly (I mean the keys) and check if the program is still running well on the new one, as I sometimes had strange issues regarding cross calculator compatibility. If found out that the contrast changing in the intro seems to be battery level dependent so I will try to make it use not at a pre-set contrast level but tge contrast level the user sets. This will sure affect it's length, but I don't know any solution :/.

Then I will work on making the file handling part that comes right after the menu. I had the idea I could add an ability to add own scripts for for example brushes, they will then be at the entry "Manage Files/Add Script...", which will bring up a dialog. Also, I guess I will need to rework my while GUI and user/calculator dialog system, the current one is not that good. I plan making a real GUI system, allowing multiple elements a page. Those will be changeable with the arrow keys.
Do you have other ideas/suggestions/requests?

PS: I will try to make a function to resize images. I once tried this however, and all my attempts didn't get faster that about 45 minutes to resize the whole screen by simple bilinear interpolation! So I will need serious help with this...

I am still trying to make the after-menu file creating part. That's a really hacky piece, as soon as you try to optimise it!
Anyway, sadly I didn't get any working results yet :/

keep on trying I would love to try out a more complete version of this as I love GIMP and it's tools

I just lost some of the work... Well, it was not much but annoying anyways.
I decided I will make a new todo and features list now. Here it is:

General features planned/in progress/implemented:

• Full GUI (Always under development)
  
• Own Filesystem (Under development at the moment)
  
• Basic shape drawing tools (Nothing done at all, but is absolutely no problem)
  
• Installation program (Nothing done at all)
  
• File managing (Nothing done at all)

Image processing algorithms planned/in progress/implemented:

• Flood fill (Done and optimized, implemeted the ScanLine algorithm)
  
• Masking (Area selecting) algorithm (Done, implemented an own algorithm)
  
• Layering algorithm (Nothing done at all, but I know what to do)
  
• Dithering brushes (Nothing done at all, but I have an idea)
  
• Stamp tool (It was requested, and nothing done yet, but I have an idea)
  
• Scaling algorithm (Nothing done at all, possibly the hardest piece

Any support appreciated!

Edit:
Forgot the todo-list (). Here it is:

There are somethings I need to do due to changing my calculator.

• Correct the intro, make battery level independent (Some testing needed, will release today)
  
• Check lib compatibility (Seems fine)

Edit 2:
Forgot the stamp tool, added now. And I changed the yellow color, as requested in SAX

I like the new todo list

I don't have access to my PC right now, sorry. In about 1 hour I will post a screenie and the code.

And I have a question for Kerm:
Is there some sort of API or something for DCS7? What I need is a program which can enable the setting "Third party libraries" for my installer, so the user does not need to do this manually. Is that possible?

Edit:

Code:

Okay. So, I almost finished the file creating part, using an IDE (SourceCoder) helped a lot. I still didn't test it, as I need to change the library from CopyProg to DCS and that is required for the code to run. I also ask to vote in the poll, so I can do this part correctly from the beginning.

A note about the poll question: I possibly could add an option for the user to select this, but it would be a really memory-eating feature. I want to keep the overall program smaller than 10 KB after installation.

I also had a new Idea:
I could do support for plugins in some places, so the user may program custom brushes/algorithms/whatever. These can then also be available for download as functionality extension packs. What do you think?

Sorry for being impatient, but I ask everyone again to vote in the poll please.

Also:
Are there any opinions on the "API"? Do you have ideas on how it might work exactly?
What about the scaling algorithm? Does anyone know anything faster than pixel replication or have a fast implementation of it? I want to keep the scaling time down to about 2 minutes per full screen or even less if possible.

Thanks for helping, I will continue coding once anything is clear.

I think it makes the most sense to store everything as AppVars. The problem with storing data files as programs is that they clutter up the PRGM menu, and unless you suddenly turn this into an assembly program that can use Doors CS's associated file API to make image files open automatically in TIMP when you run them, I can't think of a good reason for them to be in the PRGM menu. To your other questions: I think that having an API for plugins sounds like a cool idea, but I'd wait until you have made more progress on the program first. Presumably all that plugins would need would be access to the Options data and access to the image buffer. I think that DCS GUI small windows for each plugin would look visually cool, but that's just me. For scaling: take a look at this image scaling tutorial, which reviews some of the available methods. As it says, you're always going to be trading off between quality and speed.

For such low-resolution images I believe hqx is the better choice. I found some sort of idea here. I believe this is almost similar to the hqx algorithm if ignoring the binary decomposition part, though.

I will try to make a fast implementation, some of the Celtic III tools like base conversion should do a good job here.

Making a plugin system is an interesting software design exercise, but brings some complexity. You should indeed proceed further with most other features before implementing a plugin system.

Thanks Lionel, I will do it that way.

I ran across a problem, however:
Celtic det(18 and det(28 (at least those two) seem to malfunction.
My scaling algorithm scans the screen by 2*2 blocks, which get returned as a binary string containing the on/off state of pixels. I supposed to convert that string from binary to hexadecimal ("det(18") and from hexadecimal to decimal ("det(28") and based on that number I select the corresponding enlarged tile. But the problem is that for example det(18, "0000 returns "03030303 or something like that, in fact every input returns nonsense. When this is inputted to det(28 the program crashes with an ERR:INVALID DIM.
Why is that so? I already checked DCS and unflagged and flagged the library setting back again.
If that seems to be a bug:
I am running DCS 7.2 on a TI-83+ with OS 1.19.

Edit: If there is an easier way of converting the base, it is preferred of course. To be honest I was really surprised not to find a base n to base m converter in Celtic III.

Why do you use Celtic to convert base-2 to base-10? There are tons of them in the TI-BASIC subforum Code Routines. For example this one:

Code:
or this one (self-made, it uses a list of 4 elements):
Code:

Using Celtic is probably faster, not to mention smaller, since the base conversion code is already there.