For those of you that don't know what paint.net is, it is a graphics software that is comparable to photoshop. I think it would be a good idea to make a program that simulates PDN. The features it would need to have would be:
*fill selection
*invert selection/whole screen
*gaussian blur/plain blur
*layers
*ability to chose size of drawing with zooming abilty (optional)
*magic wand tool/selects portion of screen until it meets something of a different color
*flipping horizontily/vertically
*text with different sizes
I would also like to add some greyscale but thats a little bit too much for now. If anyone has any good routines for any of these it would be helpful, I Know I'll need some help with this.

First, Paint.NET is awesome, but in no way is it comparable to photoshop or trying to be photoshop.

Second, WHY? What possible use does this have? You are talking about advanced image creation and manipulation on a tiny b&w screen. There really isn't a point.

That said, if you want to attempt this, you'll need to do it in assembly to get anything resembling speed out of it. And somehow I don't think you have anywhere near the skills needed to do it.

Ok, honestly I have never used photoshop, so sorry if I offended photoshop.

Second, the reason...mainly to take my favorite graphics program on the road with me.

Third, do I really have to use assembly. Is there a converter between basic and assembly. Doesn't basic get interpreted as assembly, so shouldn't there be a way to permanently assemblify it(is that a word)? If not then I guess I better get learning assembly.

There is a converter, but I've never gotten it to work, also it's not as fast as normal assembly, and yes BASIC is interpreted, but that doesn't mean you can convert it well...BASIC is wry different then assembly.

I don't know if you have tried this, but theres an app called BBCbasic (Z80). It's written in semi-normal ti-basic, and it's super fast. Much faster than ti-basic, not sure about asm though. Would that maybe be a good choice? It would fix the speed problem.

Yes I have tried it, and it's not written in semi-normal ti-basic, it's written in assembly, and it's an interpreter for an old version of computer basic.
You could itry it if you wanted, but I don't think you would be able to view the pictures in anything but the BBC basic interpreter. Also BBC basic would be hard to learn and then write something like this right away in. I'd focus first on finishing learning enough of ti-BASIC.
Also why don't you just use pyroedit?

I have used BBCbasic, I know a good portion of the language of both BBC and ti basics. I could use the manual for BBCbasic for codes I don't know. Is there a part of Ti-basic that I just don't know or haven't proven I know, because everyone is thinking I don't know the Ti-basic language

I don't like pyroedit that much because:1. Waaaayy too many files to download (at least when I tried to download it last) 2. Takes up too much ram (ie when I tried to download it, I got a ERR:MEM error. IDK i'll try it again. I'll post if I liked it any better this time than last.

Ah ok.
Well why are you sending it all to the RAM? Aren't you suppose to send it to the archive? Also it has to have that many files if you want it to work...the algorithms and etc are big...

TI-BASIC if full of vast secrets. Many of them likely unintended. There's lots of interesting stuff you can do that you will probably never have a chance to use.

Ok I have reloaded pyro edit, and I have to say it was done well. The reason why I must have gotten an error before was I must have had something else downloading with it. Oh and also for whatever reason (might need a patch if it doesn't have it already) when I send grouped files to my calc (ti 84 plus silver) There must be a code that gets sent or something and it cuts the file off early. Thus leaving me with a mem leak because it loads whole file but counts the program as part (it actually only counts the program as 16 bites and when I try to delete it, it deletes the file above it). (hopefully not confusing) either way Pyroedit is good but not what I was talking about.

before you say something, yes I know that I can make mods to it and I will.

@Will_W can you maybe list some of them?

Optimizations with some of the rarely used math commands. A chance to actually use the elusive IS>( or DS<(. Maybe find a way to use the way it rounds FP numbers to 0 sometimes. The inability to break execution during the SortA( or SortD( commands; seq( too.

Thanks, does anyone know a good code to fill something, such as the microsoft paint tool?

BBC basic has some splash fill I believe. I have a TI BASIC splash fill routine on my parents' PC, I'll see if I can find it later today.

If you would please, I would like to see the source. I've been thinking of ways to do it, but they always seem like they would do something wrong. Like miss something or go outside the boundries that your filling in

There is no viable TI-BASIC to ASM... brandonw is trying a new TI-BASIC interpreter. Dunno how faster it is going to be. Check in his svn the progger.

BBC Basic can be fast enough to your needs. It has fill commands so it would be fast.
ASM is ideal.

But this is not a great idea... The screen resolution is too small for complex things...

thats why you would be able to make the screen resoluton like 4x making the screen actually ~376/248. Then being able to work on specific sections of the canvas then zoom all the way out to see full picture (with the resolution of 4 logical pixels per pixel). Plus I would like to find a way to make a computer picture to ti picture converter. I suppose the only way to get even remotley good picture quality would be to make at least a 3 level greyscale, even if it means turning pixels on and off really quickly (unless theres a better way with BBCbasic)

p.s. anyone like my avatar, made it with PDN

Haven't dug up the code yet, but the basic idea is this:
You start with one pixel
That pixel is alive
If there is empty space next to it, it spawns a pixel in it
It then dies
Then you repeat with it's offspring until there is no more growth
There is something in place to prevent two pixels from spawning a pixel in the same place

hmm. cool I'll have to try that, I'll try to get a working code up by tomorrow, unless you find the code that is

Anyone got a better way to do splash fill?

Wait theres only one problem I think... if you come across something already on, won't that just create another one, or maybe you could (yes I know it's a memory hog but) keep calling a program for each pixel that is a repeat inside a prorgram and on on on. and in the repeat it checks for pixels and for each pixel it stores x and y then runs itself, and when its done with its pixels it goes back and repeats...does that make any sense?


i.e.

MainProgram
pxltest(x,Y)->A
if a=1
then
"woops one more thing
if not(pxltest(x-1,Y-1)
then
x-1->x:Y-1->Y
prgmMainProgram
X+1->x:Y+1->Y
end
ETC