. /../LinoPaint/ 12345
written by Jaxe'd on Jul 16, 2005 14:57
This program started off as something I was just playing with and progressed to what I have here. I have further plans, but I figured now would be an okay time to show the progress.

<cd/zips/Jaxe'd/linopaint0.2>

Also, I have a question. The program runs about 50% to 60% of my CPU when it is doing the normal loop. When I start drawing in the area, the program runs about 80% of the CPU. Is there anything that uses that much CPU?
I have taken out certain peices of code at a time and the CPU usage would always stay up at around 50% to 60%.

Other than that, I think it is a pretty cool program.
└> last changed by Jaxe'd on July 19, 2005 at 12:14
written by Cryoburner on Jul 16, 2005 16:46
Fun little program! Do you plan on continuing to add more features to it?

I do have a suggestion for your 'pencil' tool. You've no doubt noticed that when moving the mouse quickly, it breaks up into lots of single points. In something like MSPaint, these points are connected by lines. For a basic pencil tool, it's probably best to not use antialiased lines, like those in my wulines library, so I suggest something like Peterpaul's Bresenham line plotter instead...
cd/zips/Peterpaul kl h/graphics (6 Kb)
You can just use the previous cursor position each cycle for one endpoint, and then check the current cursor position for the next endpoint.

For your system resource issues, I only took a quick scan through your code, but I think the most time is likely being used for clearing, redrawing, and retracing the entire display each frame. Instead, you should be able to just update those parts that have changed, like the area behind the mouse cursor, and the part of the image that's been altered. Additionally, you might try increasing the sleep timeout from 1 millisecond per frame to perhaps 5 or 10 milliseconds. You probably don't need to set your thread priority to very low though. For some background app like a clock that's good, but it could potentially make your program's performance slightly unpredictable when multitasking with other normal priority programs.
omg! toadstoolz!
written by Dumbum on Jul 16, 2005 21:00
Cool program.Now make the drawing area bigger and I could make nicer images than the one I made with ArtSCII!
(Because of the even smaller dotted-effect)
written by Jaxe'd on Jul 19, 2005 12:20
Here's an update:
I used Peterpaul's "graphics" library to draw a line between each point instead of drawing single points. I'm not sure how many colors I had in the last update, but I know I added some more colors. For now, there are black, white, red, green, blue, yellow, cyan, and magenta. The program uses very little CPU at this computer (at work), but of course this computer also has dual processors. :cheer
written by Barebones on Jul 19, 2005 12:26
Nice!
A cool next addition could be an area-filling algorithm. (And next, snap in Cryo's curve-drawing routines.)
written by Jaxe'd on Jul 19, 2005 14:41
Oooh!!
/me makes note of this...

I'll get back to you on that. :hmm:
kamikazemadman
written by Peterpaul kl h on Jul 19, 2005 14:56
Hey, this looks fun!
It compiled and runned fine here under linux. Glad to see that my graphics library is used.

graphics.txt also contains a routine to draw triangles, maybe you could check that out too.

Anyway, keep up the good work!
written by Cryoburner on Jul 20, 2005 03:34
Yeah, that line method seems to be working well. The graphics.txt library also includes the clipline routine for limiting lines to a certain area. I notice that you currently don't plot them at all when an endpoint falls outside the area, but it would probably be better to clip them right to the edge instead.
written by Jaxe'd on Jul 20, 2005 13:13
Ah, so I tried implementing the clipline in the program, but there appears to be a small problem. The problem is that when you hold the mouse down and hover it outside of the drawing area, then back in, it draws this line from the bottom right corner to where your pointer currently is located. I am not too familiar with the clipline, so I am not sure what i am doing wrong... Any ideas?

screenshot:
<link cd/pngs/Jaxe'd/linopaintclipline>

zip of the program with the clipline implemented:
<cd/zips/Jaxe'd/linopaint0.2a>

EDIT: wait... i think i know why it's doing that... i'll be back in a few.
Ok. That problem is fixed. I still have the problem of not being able to draw up to the edge of the drawing area, though.

Here's an example where I drew quickly from right to left across the draw area:
<link cd/pngs/Jaxe'd/linopaintclipline2>

and the new zip:
<cd/zips/Jaxe'd/linopaint0.2b>
kamikazemadman
written by Peterpaul kl h on Jul 20, 2005 13:27
Well, you should always check if one of the endpoints is inside the drawing area, and when it is, either the old one or the new one, you should display the line.

I took a glance at your code, and i think that you check if the mouse is currently inside the area, then draw the line. So, when you move your mouse outside the area, it won't draw the line.

I hope this explains it. And good luck.
--- EDIT ---
I also notice some things in your sourcecode:
You seem to rewrite large pieces of code which only differ slightly, For example you have two pieces for drawing on left and one rite. The only difference here is the color you use. Why not set the selected color in a variable, and call just one routine. I think there are more examples like this in your code. More modular source code results in better maintainable code. What if you want to change the way you trace the lines, you have to update two pieces of code in this case. What if you change something in your detection of buttons, you have to change 9 or 10 pieces of code. My advise is think of a way to group generic code in a function.

For your buttons and click events, you could check out the standard library gen/region.txt.

And finally, don't take this the wrong way, i don't mean to offend or criticise you, just to educate you. I think what i just said makes some sense, but if you don't no problem. Good luck and fun with your coding!
└> last changed by Peterpaul kl h on July 20, 2005 at 13:55
written by Jaxe'd on Jul 20, 2005 15:12
Thanks for that. I'll work on it.

No, I won't take it the wrong way. I asked for help and that's what I got, so I'm not complaining.
written by Nebuloso on Jul 20, 2005 20:46
This is just the kind of thing I think Lino needs to grow in the eyes of people in general. this is cool.

A few things I hope you'll add:

1: The possibility to choose your own colours with RGB values. Either just three sliders or one of those Photoshopesque colour pickers.

2: DIfferent thicknesses.

3: Area fill.

4: Zoom.

5: adjustable document size.

6: changing background colour (colour-picker or just black/white.)

7: layers?

There are more things, but I'll think some more about it.
written by Jaxe'd on Jul 21, 2005 13:15
I will have to work on some of these other ideas as I go along.

I have eliminated about 500 lines from the code by taking Peterpaul's advice about the generalization of the subroutine to draw the borders of the areas that I use in the program.

Also, I was able to get the clipline to work correctly, except for one thing. The pointer draws a single point outside of the drawing area if you drag the mouse pointer quickly.

screenshot:
cd/pngs/Jaxe'd/clipline (4 Kb)

zip:
<cd/zips/Jaxe'd/linopaint0.2c>

EDIT: Nevermind. I figured out a way to draw the line completely to the edge without drawing the point outside of the drawing area.
└> last changed by Jaxe'd on July 21, 2005 at 13:32
kamikazemadman
written by Peterpaul kl h on Jul 21, 2005 14:40
Jaxe'd said:
I have eliminated about 500 lines from the code by taking Peterpaul's advice about the generalization of the subroutine to draw the borders of the areas that I use in the program.

Also, I was able to get the clipline to work correctly, except for one thing. The pointer draws a single point outside of the drawing area if you drag the mouse pointer quickly.
Hey, now your code looks a lot nicer and it's easier to get an overview of the working of the program!

And about the dots, that's also what i got when i was making a quick fix yesterday.

I notice two things in your code which you might wanna look at:
  • line 357: gtpi drawpointer will be called in the next instruction, this causes the pointer to be drawn twice.
  • line 453: You sleep before you retrace the display. Doing it the other way will not improve the speed of your application, but might give it a little more responsive feel, as the changes to the display will be visible a few microseconds earlier.
Good work!
written by Jaxe'd on Jul 21, 2005 15:58
Alright, I have made a few changes. A few bugs have been worked out and I have made a small addition. There are two big boxes at the bottom that show the current color chosen.

screenshot:
<link cd/pngs/Jaxe'd/linopaint000>

zip:
<cd/zips/Jaxe'd/linopaint0.3>

Oh, and here's an image that I made using LinoPaint:
cd/pngs/Jaxe'd/clearskies (9 Kb)
reading this thread
no members are reading this thread
. /../LinoPaint/ 12345
38637, 16 queries, 0.164 s.this frame is part of the AnyNowhere network