A-EON Technology Acquires Personal Paint

[broadblues]

Can we make feature requests?

- onion-skin light table style animation editor (as in DPaint)

Currently there is a storyboard feature, but not onion skinning but the mode promotion to 24bit opens up possibilities under AmigaOS4.

- ability to rotate and move animated brushes in Z-axis.

That one easier, this already exists.

Animbrushes can be rotated, and scaled (which is the 2D equivalent of Z axis motion).

There is a rexx script to handle animation a long pasth etc. which gives direct equivalents to some of the DPaint features people complain is missing.

[broadblues]

Layers

Not sure how layers would work in an 8bit gfx program, layers based programs such as ahen , SketchBlock, reply on alpha blending and other advanced pixel manipulations like multiply add subtract that do not translate well.

Do you have an example of a 8bit program using layers so I can see how it works in relation to them?

 I know ImageFX has alayers facility, but that as well only works for RGB buffers, with a 'frames' version for colourmapped, which is not the same as it's for animation not blending, and as such is covered by PPaint superior animation features.

[broadblues]

it would be nice to at least have a compatible 68K version for MorphOS, I'd be up for buying that.

There no reason that the 68k PPaint 7.3 shouldn't work on Morphos, there is code within, that I haven't messed with, for detecting Morphos. If the 71.c works the 7.3 should too. If the 7.1c has issues then those issues likely remain unless they were fixed by accident :-). It's not been tested on MOS though.

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

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

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

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

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

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

[broadblues]

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

More research in the code, reveals that my original assertion that it uses fastmem when using the CPU based blit lib was 100% true.

I can open a 1920x1080p image on a WinUAE setup with only AGA (ie no uaegfx based RTG) which is as close as I can get to my retired a1200.

Such an image uses 1.97MiB of mem, which allowing for workbench at 256 and ppaint screen itself clearly doesn't fit inside a 2Mb limit.

In fact I have 298,984 bytes left over.

However one issue I did see is that intially it throws up a requester saying insuffiecient Chip mem for the requested screen, this is because it tried to allocate a max overscan super hires laced 256 colour screen. It then fell back to a simply None Overscan Hires-Laced

Max overscan off 1472 x 566 = 833152 bytes so maybe a bit tight with the WB and any background images open at the same time.

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)

There may still be an issue with even larger images.

BTW which version were you using?

[broadblues]

How about if we find a developer to do the port for free?

er what if I arrange for someone to do your job for free? :-)

BTW. If I have PPaint 7.3 from Amiga Forever, can I get future updates of PPaint for free without buying next year's AF?

7.2 comes with AF not 7.3

[broadblues]

If I still get paid, bring it on!

lol that defeats the point a little :-)

So, can I get it updated to 7.3 and up?

By buying it from AEon yes.

{edit}

You updated your comment. It may or may not be me that works on any update but whoever did so would have a fair amount of work on their hands.

I'm not prejudiced against MOS / AROS BTW AWeb was always cross platform (though itix did most of the coding for MOS I was always happy to intregrate it, and avoid breaking it)

[broadblues]

So versions sub 7.1 will note be avaliable elsewhere? Why does it matter then if I host them, anyone gets hurt by it?
If so it seems this falls under the title "Abandonware" in my book.

Certainly it does not. Ignoring the fact that abandonware is not a legal concept,  it refers to abandoned software, which PPaint is clearly not now, nor has it ever been, being always at least distributed by it's original copyright holders and now developed by the new ones.

And PPaint 7.1  will run on any age of machine, so older copies are redundant.

[broadblues]

Has anyone tried the 68k version of 7.3 with AmigaOS 4 or MorphOS? I would like to buy a copy if it works well

Can't speak for Morphos but it will run on AmigaOS4, **but** oddly enough the AmigaOS4 version will run much better, not just faster because it's native but also it makes better usage of the more modern API functions and can promote screens to 24bit allowing smoother integration (no monitor resync it screen switching) and true colour previews in the Story Board.

The 68k version will attempt to run in low memory mode on AmigaOS 4 because it can't find any chip mem the PPC build knows about this and doesn't panic :-) The PPC version will never accidentally run the angus based blit library, so avoiding a crash the 68k can have when running on an OS4 machine.

If you buy both you get a discount...