@Raffaele

So, has anyone rebuilt DPaint I yet from the provided source code? Looks like the program was originally called Prism.
Wonder if we could update it to build on Amiga OS4?

Scott

_________________
AmigaOne uA1-c 512M RAM - Only Amiga Makes It Possible!
Check my blog AmigaOne Computing

@scabit

Olsen and Frank Wille did.
Kamelito

@scabit

License seems a bit strict (personal use only). Well, to be honest I read only the first 2 paragraphs but anyway :)

@scabit

And what would be the point of that adventure ?

It's 30 year old SW costumized to run on ancient HW with a very limited OS.

Rebuilding a DPaint_I level paint app from scratch useing some GFX lib (GDK,cairo,agg or even SDL) and than adding a MUI interface would probraly less work.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @scabit And what would be the point of that adventure ?

The point of having an adventure is ... having an adventure

As a software developer who's been around for a long time, it is absolutely fascinating to see how professional, highly acclaimed and commercially successful Amiga software was designed in the early days of the platform.

You might think that this is some dinky, rusty Volkswagen Beetle with more than one flat tire, grass growing out of its gas tank, and which inside vaguely smells like something you wouldn't want to know more about. I have looked inside, and it's really a Jumbo Jet. This is a highly sophisticated design, very well-organized, very robust implementation. Amiga software of that vintage is (as far as I know) not supposed to be that great. Yet, there is "Deluxe Paint" 1.0, age 30, and it's a knockout.

Quote:

It's 30 year old SW costumized to run on ancient HW with a very limited OS.

It's a 30 year old killer application which uses its platform exceptionally well, to the point that it uses hardware acceleration: the Blitter's logic and arithmetic functions are employed for editing and rendering. This alone is exceptionally rare. I only know of a handful programs which do that, and do that in multitasking. And with less than 512 KByte of memory available (256 KByte in the original Kickstart 1.1 version in 1986).

Quote:

Rebuilding a DPaint_I level paint app from scratch useing some GFX lib (GDK,cairo,agg or even SDL) and than adding a MUI interface would probraly less work.

You could arguably knock together a basic bitmap paint program from scratch within a week. But you are unlikely to build something in this time span that equals "Deluxe Paint" in terms of system design, user interface design, algorithms and features. "Deluxe Paint" still does a couple of things which other paint programs found no need to implement.

For the record, it took me about half an hour to get "Deluxe Paint" running. It was missing code that had to be reconstructed (fixed-point multiplication), but the fact is that any program of this complexity can be made to work on today with minimal changes is something you do not see every day

Last edited by olsen on 28-Jul-2015 at 02:36 PM.

@scabit

Quote:

scabit wrote: @Raffaele So, has anyone rebuilt DPaint I yet from the provided source code?

Yes: last Saturday

Quote:

Looks like the program was originally called Prism. Wonder if we could update it to build on Amiga OS4?

It builds (with SAS/C 6.55, with only minimal changes from the original code; the GCC build still needs more work, though), but it does not run out of the box, on account of depending upon the Blitter hardware for its operations. Which sounds like a limitation, but it used to be a major advantage back in the day.

@olsen

I guess you missed the context here, as I was replying to scabit asking for an OS4 version.

Such a version would require a massive overhaul to the sources to get any useable result.

(a PPC binary that still relies on the OCS and therefore only works on Phase5 HW does not count as a proper OS4 port in my book).


Edit:

It's just that some people would cry out for an OS4 port on every released source even if it was the orginal Pong or some line editor from the 70s.

Last edited by Kronos on 28-Jul-2015 at 02:26 PM.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @olsen I guess you missed the context here, as I was replying to scabit asking for an OS4 version. Such a version would require a massive overhaul to the sources to get any useable result.

Um... I don't think so. The Blitter hardware dependencies need to be replaced. The direct planar bitmap access would have to be emulated. There would have to be restrictions on the number of colours used for images.

But all of these things could be slipped into an emulation layer which would sit between the modern AmigaOS and the 30 year old program code. It is really that well-designed.

Not sure how much sense that kind of work would do, but I reckon it's not so tough having gone spelunking inside the code for a couple of days now.

As for bug fixes, there's the rub. "Deluxe Paint" has its share of problems, had them since 1985.

Last edited by olsen on 28-Jul-2015 at 02:42 PM.

@Kronos

Quote:

It's just that some people would cry out for an OS4 port on every released source even if it was the original Pong or some line editor from the 70s.

I sort of agree, in the sense that time is wasted on outdated programs, and useless code, when you might spent the time on more modern things.

The people asking are just Nostratic about old things; I do not think it is out of desperation, as you make it sound like.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@olsen

But what would be the end result of that ?

Run DPaint_I as it was 30 years ago on OS4 ?
One can allready do that pretty well with UAE.

Point is these sources may have been written very well and produced outstanding results back than, but they are obsolete for anybody doing GFX today.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Kronos

Quote:

Kronos wrote: @olsen But what would be the end result of that ?

You could run the program within a debugger on contemporary Amiga hardware. Which can be useful, but then you can run it in a debugger under WinUAE (or other UAE variants) already. That is, the "Deluxe Paint" version built from the computerhistorymuseum.org source code.

As a paint program of this class, "Deluxe Paint" the historic milestone from which the influence spread to everything that came after it, but it's not a modern paint program by any standard.

It's still something that is worth looking at, and looking into. But it is not so much a tool which would make you more productive, should you want to use it in place of a more modern paint program.

Basic functionality aside, "Deluxe Paint" in this form just has too many limitations and bugs. For a start, it will read only up to 50 entries from a drawer, and in several significant parts of the program no sanity checks are performed with regard whether memory allocations did in fact succeed.

Quote:

Run DPaint_I as it was 30 years ago on OS4 ? One can allready do that pretty well with UAE. Point is these sources may have been written very well and produced outstanding results back than, but they are obsolete for anybody doing GFX today.

I agree with you. 30 years do make a big difference

@Kronos

Quote:

It's just that some people would cry out for an OS4 port on every released source even if it was the orginal Pong or some line editor from the 70s.

oooh...ohhh.....I want Pong for OS4!



Scott

_________________
AmigaOne uA1-c 512M RAM - Only Amiga Makes It Possible!
Check my blog AmigaOne Computing

@scabit

Yeah, maybe....




..... but you for sure don't want to build it out of the orginal sources

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@Olsen
Why not just replace blitter code by standard graphics library calls aren't they suppose to do the hard work for you?
Kamelito

@kamelit0

Quote:

kamelit0 wrote: @Olsen Why not just replace blitter code by standard graphics library calls aren't they suppose to do the hard work for you? Kamelito

"Deluxe Paint" uses the Blitter through direct hardware access in two different places.

The first place could be converted rather easily to use RectFill() or maybe a series of BltBitMap() calls. In fact, in the source code it says in a comment string (I am paraphrasing) that the implementation should be switched over to use the operating system.

The second place uses the Blitter in a fashion which is not supported by the operating system, and it's unfortunately a building block which several rendering and brush operations are constructed around.

The most low-level operating system function that provides a robust and convenient interface to the Blitter's logic operations is BltBitMap(). This API has one specific restriction which limits how far you can go with it. The Blitter can read and combine data from three separate sources and store the result in a designated destination. But BltBitMap() restricts this to the effect that you can only use two sources, and the destination buffer must be the same as the second source. This is not a severe restriction, and you could work around it by using intermediary buffers and several passes, but you will also have to rewrite the operating instructions for the Blitter.

You tell the Blitter through what is called "minterms" how to combine the three difference sources into what goes into the resulting output. Now instead of having to tell the Blitter using the original operating instructions to combine sources A, B and C, you'd have to reschedule and combine A and B, then combine the result with C to yield the final result. This changes the procedure, the algorithm if you will.

You can break down miniterms (if memory serves, miniterms are Boolean logic disjunctive or conjunctive normal forms, respectively; I haven't dealt with them since I took discrete math courses at university, more than 20 years ago) into equivalent expressions, but given how low-level the Blitter operates at this stage, it's not a lot of fun

As I said, in "Deluxe Paint" these specific Blitter operations are only the fundamental building blocks for higher level, more complex operations. This makes things even more difficult.

If I remember correctly (I haven't read and understood all the code yet), "Deluxe Paint" also uses the arithmetic operations which the Blitter offers and which are not accessible through the operating system APIs.

In so many words, this is going to be a lot less fun to implement than to just leave it as it is, an example of how you can do this very well and harness the Blitter for operations which perfectly suit the application.

Here's to absolutely nailing something, as opposed to stumbling along, barely achieving the same result with a lot more effort!

I think far better would be to have the sources for DPaintIV AGA and work up to remove it's limitations. But IIRC DPaint IV sources were lost. and version V was a rewrite with added bugs and loss of efficiency.
I doubt Electronics Arts gives a rats ass about releasing the sources though.

_________________

José

I recall that DPaint 4.5 AGA freed more RAM than it allocated. That is, if I booted without startup-sequence, did avail flush, start dpaint, exit dpaint, avail flush again, it would show more free RAM available than before dpaint was started.

DPaint V, or 5.2, is ridden with annoying bugs, so most of the time I continued using 4.5 AGA. It would be awesome if DPaint V sources could be released and bugs be fixed, there really is no other package that makes animation so easy and fun.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Jose

Quote:

Jose wrote: I think far better would be to have the sources for DPaintIV AGA and work up to remove it's limitations. But IIRC DPaint IV sources were lost. and version V was a rewrite with added bugs and loss of efficiency.

That sounds very unlikely.
V is very much like 4.5 AGA, but brought some big changes, such as attempts to support RTG and true colour handling, and use of ASL in stead of custom requesters. Clearly these changes introduced a whole range of bugs too.

Quote:

I doubt Electronics Arts gives a rats ass about releasing the sources though.

Yeah, but one can hope :)

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@olsen: for me doesn't make sense to patch the Deluxe Paint sources only to remove the direct access to the Blitter.

However if anyone wants to port it to non-Amiga machines, I think that the Blitter can be emulated. Waste of time, but possible.

@cdimauro

Waste of time? Isn't that why we are here in the first place?

Last edited by kolla on 28-Jul-2015 at 08:35 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC