Initial port of new Paint app. NEW VERSION #14

@Arcane5150

There is no logic connection beetwen lodepaint and gish. Gish used datafiles (and how game look based on that data files). LodePaint use only 3 data files, and they only for toolbar/tool images/ buttons.

That "like linux font like" its just because author choice that look by SDL in his engine (so there is nothing linux related).

The only conenction beetwen Gish and LodePaint, that they boch have open source :) But their look not mean Linux or kind.

@kas1e

Nice port, thank you! I was wondering: is there any chance to replace the program's custom filerequesters with ASL ones? It's really terrible getting 100% CPU usage even when selecting files to load/save

@trixie
Yep, will be nice to add that.

@all
Today i trying lodepaint on PC/WinXP with such config:

- Radeon7000 (so, the same as we have)
- 1.1 ghz of cpu Intel Celeron (so, the same as i have on my peg2)
- 256mb of ram only (i have 1gb)
- slow hdd (i have better one on peg2).

And the result: LodePaint works _ABSOLUTLY FINE AND FAST_ even in 1024x768 mode (+that winxp full of trojans and viruses and crappy slow addons).

So, for now, i see only one problems why LodePaint works not so fast on our amigas: bad drivers, bad(slow) realisation of warp3d and bad realisation of opengl (because of warp3d layer between). Or dunno what else. But on the almost the same hardware it already works fast.

Uhm. That bad for aos4. Looks like today aos4 can't be compared even with heavy-loaded winxp on the almost the same hardware. Before i think that aos4 will be better in terms of speed on almost the same hardware. But reality is worse. Maybe after 1-2 year when we will have bug-free mesa and new drivers, maybe then..

Strange why Hyperion not have in high-priority making normal 3D subsystem, and we have something "more or less ok / better than nothing".

Quote:

just checked and it's fine now..thanks

@328gts

Funny you have same numbers in your nick as the latest OWB version.

@all
New version in os4depot query. New since last one:

-- -Added GIF format support (only loading). Animated gifs are loaded as a single image with all frames laid out horizontally.

--- Removed the triangle tool, it was replaced by the polygon tool long ago already

--- Added palettes "CGA" and "Tango"

--- Fixed bugs with paste as selection: previous selection not lost anymore, and undo works for it

--- Made the opacity of the generate scanlines filter customizable

--- Gave the generate tiles filter two separate opacities.

--- Added Generate Gradient Quad filter

--- Added "Overview" panel showing a small zoomed out version of the painting

--- Updated manual

Also it looks maybe a bit faster now.

@kas1e

You're awesome dude...thanks again

@kas1e

Thanks for the update! Also, good to hear that ASL requesters can be implemented.

@all

New version in upload query on os4depot. Changes:

-- Added "Pointillism" filter, the first artistic filter
-- Added Morphology filters: dilate, erode, open, close, gradient and top hat
-- Changed some more GUI graphics (the style of the menus)
-- Fixed multiple GIF image import bugs (was endieanes issues and some typo mistakes).
-- Beginnings of skins support. It can now switch between 3 built-in skins (default, negative, old). So, for now, Mason (or everyone else) can create aos4 related skin for.

Hope in next few versions add ASL reqester for all file operations , and plugin support (because aos4 have .so support, it can be pretty easy, will see).

@kas1e

great work man! keep it up! :)

@kas1e
First of all thanks for your hard work on our version of this software, it is much appreciated.

However I believe that your statements above, about AmigaOS not even being comparable to a slow XP box are quite incorrect if said in general terms, and probably language barrier made them look that way.

As you said what's not comparable, are the 3D drivers and open gl support (and NOT Aos in general), and if an application is based on those things than you are right, AOS cannot compare even to a weak XP machine.

Bu as you know, there are old GFX programs like TVPaint and ArtEffect that even though they run under 68K emulation they are WAY faster than LodePaint, and probably a fully native OS4.1 version of ArtEffect would not only run faster than LodePaint on Amiga but also faster than similar programs you might run on your XP box.

So, just as you did, let's ask loud for new fast 3D, but at the same time let's not say Amiga "in general" cannot compare to a slow XP machine as it's not true in a general sense (I bet you a dollar that the final release of Timberwolf will run faster on your Peg than FireFox running on that XP box of yours )

@DAX
Well, any OS based on parts: drivers, API, video subsytems, kernel and alt. On aos4 we have bad relisation of video subsystem (p96, which not modern and have problems by design in general (about which Rogue already say to me) ), slow relisation of 3d drivers (warp3d, which are old and maybe not so good designed), and realisation of opengl done without any drivers, just over warp3d (which all in all bad idea too), some AOS4 api (i am not sure, but imho) are old and because of 68k support still old (and slow).

So, some parts of AOS are slow. Then i think we can say "aos4 slow in that and that parts if compare with winxp". I am sure that for some parts, aos4 are better (because if not, strange that we all here). But that topic is about programm based on OpenGL, which can be _much_ faster , and we not need to say different, we just need found the solution and make it fast.

@ALL
Plugins works now ! Thanks to AOS4 with their Shared Objects support !

@kas1e
Agreed.

Thinking abour this program though I believe we have some sort of "quirk": on AOS4.1 we also have another graphic program whos UI is rendered in OpenGL and it's Blender.
How come Blender runs so nicely (specially on Sam the difference among the two is night and day)?

Could you test the following for us (?): launch Blender and put Suzanne on the screen alone, add a Subsurf modifier, raise the level to "2" and try orbiting around her.
How different it is between PegII and that XP box?

Let us know!

@DAX
Quote:

For sure possible to do everything faster than LodePaint do, but it done already in that way (not by me), so there is nothing what we can to do with (only complite rewrite, which a huge-huge job and will make no sense, better done one from scratch). I do not know how Blender do his rendering, but i think its not rerender every frame as in modern computer 3d games (as LodePaint do), and because of it it faster. Its just real world :) No one want to think about 500-800mhz machines in all the world (mostly), and we can be only happy, that something even run more or less ok for us :) Of course i ask main coder about some speedups, but not sure that he will in interest to do complite rewrite of rendering code, only because amiga-users have slow hardware (in compare) and bad relisation of OpenGl (sad truth). He even say that "he not make it as multiplatform in mind", and its just some luck, that we have "contact" and he help us with some amiga-related modifications and bugs which i report for him.

Of course if anyone will found the same quality by functionality and design opensource ppaint app , which we can easyly port to aos4 - it will be cool. But for now that all what we have. Imho tha even better -> we see problems of aos4 in full.

@kas1e

All though not strictly a pixel paint package - I have mentioned InkScape elsewhere Kas1e if your up for that challenge, but I believe there are few dependancies (more sigh) that need to be in os4 first. Although maybe worthwhile getting the ground work in place.

So many dependancies missing from os4, Trevor and his team sure got a busy year ahead of them.

@djrikki

Are you ready to put some money on an amigabounty for inkscape ????

thats could help a programmer for doing the job (with lots of donations)

NOTE: I'm not a developper..

@ALL

New version in os4depot query. Changes since last release:

-- Fixed support for floating pointing textures (such as RGBA32F, etc) for our MiniGL, because MiniGL do not works with FP textures(one more limitation example for all who say that new MESA and 3d are not necessary). so adding conversion/cheking. If no GL_ARB_texture_float present, then convert them to unsigned char. It also solve the problem with HDR images (.hdr and .rgbe formats) at all (before it was buggy on aos4).

-- Give message to the user when a filter doesn't support a certain color mode (before it simply did nothing without any indication why)

-- The crop operation now says in a warning dialog that a selection area is required for it to work.

-- Began internal code refactoring of dynamic operation parameters. When done, they will be convertible from/to everything, like XML, GUI dialogs, C-structs, plugins, etc...

-- And the most interesting: Plugins support ! For now plugins diveded on 2 types: filter plugins and image_format plugins. Filter plugins its for making more new filters, and format plugins its for expand lodepaint buy new file formats. With that release there is 1 filter plugin and 3 image_format plugins. While filter plugin do nothing so usefull (its just example of "sine" filter), image_format plugins are interesting :

-- LibJpeg plugin: by default LodePaint have internally reading/saving only classic jpeg, and not progressive ones. When you will put libjpeg plugin to plugins directory, lodepaint will automatically swith to new plugin, and you can works with any kind of jpegs (include progressive).

--DNG plugin: for working with DNG images (format done by Adobe, and for making that plugin uses SDK from Adobe). Prepare that DNG images sometime very heavy (10-20-50 megabyte of size), so, for slow amigas with slow cpu and small amount of graphics memory it will be a pain and problematic (but still, can be usable on modern hardware).

-- OpenEXR plugin: for working with high dynamic-range (HDR) image file format developed by Industrial Light & Magic.

For using the plugins, just put from "plugins_unused" direcotory these plugins which necessary for you to the "plugins" directory. In general just copy them all.

I also make LodePaint for now as dinamic binary (to make it works normally with plugins), so, very possible that some errors can happenes. Feel free to post here any bugs/problems which you have with.

@kas1e
Now this is shaping up really good! Do you think it will run well on the X1000 (might seem a given, but with our current 3D drivers....AND...the way this app was made....).

@DAX
I think that even with current realisation of Warp3d, on x1000 it will works fine. Just because of faster memory , faster bus, faster CPU and alt. Even on my peg2 with 1ghz its cant be called as slow (but still, not reactive fast of course).

When i talk with Kiero (author of morphos tinigl), he say that even morphos a bit slower in 3d in compare with the same (almost) hardware but with win32. Not because of drivers, but also because of faster hardware itself (not in terms CPU raw power only, but about all those memory-transfers and alt). So, i expect that all will be ok (maybe even with new Sam). But still, we will loose 50% of speed while warp3d beetwen.