A-EON Technology Acquires Personal Paint

[Thorham]

Is this better than Brilliance 2?

[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.

[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.

[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.

[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.

[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.

[Thorham]

So much drama about something we don't own :rolleyes:

[Thorham]

Some fine tuning to predetermine the display mode in some future version might help with this. (if there isn't already an option I missed)

Something that may be useful to add is a mode requester. Allow the user to click an additional button before the image is loaded.

BTW which version were you using?

7.1