A-EON Technology Acquires Personal Paint

[Duce]

Where can the version that was on Aminet until recently available for download at the moment?

Gotta admit, something sticks in my craw badly about software being released on sites like Aminet then being pulled.  But hey, if they bought it out, I guess it's theirs to do what they wish now in the long run.  I never used the program enough to pay for it to begin with, so no skin off me.  ADPro and the other oldies (even DPaint) still run just fine on OS4 and are better as it sits anyways.

Thankfully I do an automated mirror of Aminet for my BBS once every couple weeks, so I should still have it around for personal use.

[Thorham]

Great to see some software development. Really. Wish it would happen with IBrowse and some other old, but good, programs as well.

However, for now I'll stick to Brilliance 2. PPaint seems to load images into chipmem, while Brilliance 2 loads images into fastmem, and simply copies the visible part to chipmem, allowing you to work on huge images without ever running out of chipmem.

There's certainly room for improvement:

1. Handling of very large images. This is a an absolute must. You MUST add this.

2. Handling 24 bit color images as 24 bit internally and use HAM6/8 for visualizing the image. Brilliance 2 does this quite nicely. It can also be done a lot faster than Brilliance 2 does it (it calculates a palette for the image first, quite slow, and the conversion process itself isn't very fast, either). Good quality HAM8 rendering can be done at about 120 cycles per pixel on a 50 mhz 68030, so there's no performance reason to not have it.

3. Brilliance 2 has a horizontal interface orientation at the bottom of the screen. This is actually a second screen. This means that the interface will always have the right colors and resolution regardless of the screen mode you're using for the image.

There are undoubtedly some other things, but these are pretty important.

[broadblues]

PPaint seems to load images into chipmem, while Brilliance 2 loads images into fastmem, and simply copies the visible part to chipmem, allowing you to work on huge images without ever running out of chipmem.

It does not.

PLease gives reason for your asumption, plus deatails of the system you are running on. (that way I can help you figure out what my be wrong).

First guess would be using personal_agnus_blit.library rather than personal_cpu_Blit.library

Unselect the Menu->Graphics->AmigaBlitter option if selected save settings and restart.

 

There's certainly room for improvement:

Always. Even Photoshop can be improved :-)

1. Handling of very large images. This is a an absolute must. You MUST add this.

I'd love to take credit for this, but it exists since long before I saw the source code.

4000x5000 pixels was the largest I could get running on my SAM 440

2. Handling 24 bit color images as 24 bit internally and use HAM6/8 for visualizing the image.

This isn't going to happen very quickly, if at all, though never say never, Brilliance 2 was a total rewrite IIRC or is thet TrueBrilliance? not 100% familar with whioch names never even heard of that bit of software til I worked on PPaint.

In my 3.x days my choice was DPaint PPaint ot ImageFX

 
3. Brilliance 2 has a horizontal interface orientation at the bottom of the screen. This is actually a second screen. This means that the interface will always have the right colors and resolution regardless of the screen mode you're using for the image.

Seem to remeber ImageFX working like that too, it was pretty crap.

[TrevorDick]

Thorham

I presume you are refereeing to True Brilliance which was the 24-bit painting program. For me Brilliance 2 is akin Personal Paint, while True Brilliance is more related to Andy Broad's SketchBlock.  Anyway both programs (PP7.3 and SketchBlock) will be in the upcoming Radiance Multimedia Suite release.

BTW IIRC (and correct me if I'm wrong) wasn't Personal Paint the first Amiga paint program to break the 2mb chip RAM barrier?

TrevorD

[TrevorDick]

If someone who has both OS4 and MOS and bought the 68k version would like to give feedback they would be welcome :-)

You wish is my command. ;-)

I will give it a try later today.

TrevorD

[jj]

Jesus H corbert.  I think this might be the end.   What is wrong with us all.  People do nothing we moan.  people spend money and time and effort we moan.   It is about time people put up or shut up.  I have never seen more people moan about the efforts of others whilst doing f all themselves.

[giZmo350]

Great news! One question... Is there a hardware list of the pressure sensitive (I assume tablets) devices that are supported? I currently have a Wacom Artpad II that is somewhat supported by Formaldihyd on AmiNet but it works just so, so. Built in support for Wacom (Artpad II) tablets would be great!

By Chris Hodges
http://aminet.net/package/driver/input/FormAldiHyd

@AmigaKit... PLEEEZE acquire the rights to iBrowse!:)

[Thorham]

PLease gives reason for your asumption

It's not an assumption. I tried with a 1920x1024 image that loads fine in Brilliance.

plus deatails of the system you are running on.

A1200 with Blizzard 1230IV and 64mb fastmem.

Unselect the Menu->Graphics->AmigaBlitter option if selected save settings and restart.

Tried it, and it still wont load the image.

 

Always. Even Photoshop can be improved :-)

Very true

I presume you are refereeing to True Brilliance which was the 24-bit painting program. For me Brilliance 2 is akin Personal Paint, while True Brilliance is more related to Andy Broad's SketchBlock.

Brilliance 2 and True Brilliance are in the same package, and work in the same way. True Brilliance is simply the true color version of Brilliance 2.

BTW IIRC (and correct me if I'm wrong) wasn't Personal Paint the first Amiga paint program to break the 2mb chip RAM barrier?

Can't get it to work here.

[broadblues]

Great news! One question... Is there a hardware list of the pressure sensitive (I assume tablets) devices that are supported? I currently have a Wacom Artpad II that is somewhat supported by Formaldihyd on AmiNet but it works just so, so. Built in support for Wacom (Artpad II) tablets would be great!

It works via the 3.x Intuition Tablet API (and OS4 extentions to that) so any driver system standard driver should work. Anything using a custom protocol wont for the moment.

I've no dea what drivers do what on the 68k side I'm afraid, I never had a tablet for my a1200, and can't get the tablet I do have recognised by WinUAE.

[broadblues]

It's not an assumption. I tried with a 1920x1024 image that loads fine in Brilliance.


A1200 with Blizzard 1230IV and 64mb fastmem.


Tried it, and it still wont load the image.

 
Very true


Brilliance 2 and True Brilliance are in the same package, and work in the same way. True Brilliance is simply the true color version of Brilliance 2.


Can't get it to work here.

So do you have a RTG card or you using AGA.

What screen size / mode is it trying open? Because 1920x1024 is awfully close to 2Mb.

What error report are you getting when it fails to open.

Also make sure that autoscroll id off it the settings as PPaint may try to allocate a screen teh same size as the image and autoscroll on it.

[Thorham]

So do you have a RTG card or you using AGA.

AGA.

What screen size / mode is it trying open? Because 1920x1024 is awfully close to 2Mb.

By default it tries to open a 1920x1024 screen. If I pick the current screen mode (688x564 8 colors), it also says there's not enough memory.

What error report are you getting when it fails to open.

'There is not enough memory'.

Also make sure that autoscroll id off it the settings as PPaint may try to allocate a screen teh same size as the image and autoscroll on it.

Tried it, and it doesn't work.

Somehow I doubt it can do it.

[broadblues]

Tried it, and it doesn't work.

Somehow I doubt it can do it.

Done some testing on a AGA only WinUAE setup and can't get larger images to work. we did have testers working at 1920x1080 but on RTG based systems I think.

The 68k version seems to work better on AmigaOS4 than on 3.x which is pecualiarly ironic, because it has no ChipMem at all.

Will go digging in the source code for the reason.

[Thorham]

Done some testing on a AGA only WinUAE setup and can't get larger images to work. we did have testers working at 1920x1080 but on RTG based systems I think.

The 68k version seems to work better on AmigaOS4 than on 3.x which is pecualiarly ironic, because it has no ChipMem at all.

Will go digging in the source code for the reason.

It's a feature you'd have to add. Brilliance 2 will only open a screen that's the size of the visible area. You literally can't open anything larger (it won't let you, you can only make smaller screens). It loads everything into fastmem and copies image data to the screen memory as needed. Basically, you have the screen size, and page size. This also allows you to have many pages, and the only thing that takes up chipmem is the visible part of the screen.

Of course the drawback of this system is that it's slow with double scan modes in resolutions such as 640x512 in 256 colors, but when doing lowres work it's fantastic.

[broadblues]

It's a feature you'd have to add. Brilliance 2 will only open a screen that's the size of the visible area. You literally can't open anything larger (it won't let you, you can only make smaller screens). It loads everything into fastmem and copies image data to the screen memory as needed. Basically, you have the screen size, and page size. This also allows you to have many pages, and the only thing that takes up chipmem is the visible part of the screen.

Of course the drawback of this system is that it's slow with double scan modes in resolutions such as 640x512 in 256 colors, but when doing lowres work it's fantastic.

I don;t really have to add it as such, that's how it works on an RTG screen, though it does open as large a screen clip as possible, if the image is bigger still then the image can be dragged arround in the screen clip or scrolled with the arrow keys.

It does seem to use chip mem in combination with RTG when both exist which limits final image size and clearly on AGA it uses chip much more, but when the cpu based blitter is in use, then chipmem is not required.  I should be able to detect usage of CPU lib and "throw a switch" to disble usage of chipram.

[Thorham]

I don;t really have to add it as such, that's how it works on an RTG screen, though it does open as large a screen clip as possible, if the image is bigger still then the image can be dragged arround in the screen clip or scrolled with the arrow keys.

It does seem to use chip mem in combination with RTG when both exist which limits final image size and clearly on AGA it uses chip much more, but when the cpu based blitter is in use, then chipmem is not required.  I should be able to detect usage of CPU lib and "throw a switch" to disble usage of chipram.

Cool Did someone forget to activate this? Sounds like just the thing someone might overlook somehow.

[broadblues]

I Think it's too useful to be left off by accident, so I'm probably being overly optimistic, it more like a feature halfway there, I just need to find wat breaks when switching of Chipmem and see if it's fixable.