Amiga.org

Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Programming and Development => Topic started by: Yasu on July 23, 2015, 01:15:36 PM

Title: Deluxe Paint 1 source code released
Post by: Yasu on July 23, 2015, 01:15:36 PM
"With the permission of Electronic Arts, Inc. the Computer History Museum is pleased to make available, for non-commercial use, the source code to the 1986 version I of DeluxePaint. There are 89 files of C language source, comprising almost 17,000 lines of code in about 474 KB of text."

http://www.computerhistory.org/_static/atchm/electronic-arts-deluxepaint-early-source-code/
Title: Re: Deluxe Paint 1 source code released
Post by: olsen on July 23, 2015, 04:17:49 PM
Quote from: Yasu;792955
"With the permission of Electronic Arts, Inc. the Computer History Museum is pleased to make available, for non-commercial use, the source code to the 1986 version I of DeluxePaint. There are 89 files of C language source, comprising almost 17,000 lines of code in about 474 KB of text."

http://www.computerhistory.org/_static/atchm/electronic-arts-deluxepaint-early-source-code/
I had a quick look at the code and made a few interesting discoveries.

All the file names in the archive are using all upper case letters, e.g. "PRISM.C". Header file path names use '\' as a separator character, and not '/'. Path names are up to 8 characters long (e.g. '#include ' instead of '#include '). The "PRISM.TXT" file contains instructions for the linker, in particular how the overlay modules are set up, which allowed the program to run even on a 256KByte machine. The linker file references "lc.lib" which suggests that the Lattice 'C' compiler was used, which is not the same as the compiler used by Amiga, Inc.

All of this suggests strongly that "Deluxe Paint" was created using a cross compiler running under MS-DOS. At the time this was a cheaper alternative than to use a "Sun 2" or "Sun 3" as Amiga, Inc. at Los Gatos did. I remember reading that the MS-DOS based development system was used at Electronic Arts at the time, with curious consequences: "Arctic Fox" was developed on a machine with a wooden keyboard ;)

From my point of view the code uses the operating system very well. Unlike so many programs written in the early days, "Deluxe Paint" does not provide its own custom user interface but leverages what the operating system provides (this was not always possible at the time, though, as the toolbox for creating user interfaces was somewhat limited in the 1.x days). However, "Deluxe Paint" does use the Amiga hardware directly, such as for creating image masks (for brushes, stencils/friskets). The code does this cleanly in the prescribed manner: obtain ownership of the Blitter, set up the blitter, start it, wait for it to finish, yield ownership of the Blitter. On the other hand, testing which mouse buttons are currently being held down by the user involves peeking the hardware registers. There was no function for obtaining the current state of the mouse buttons until Kickstart 2.04, so that may have been a reason to go with the hardware access instead. Also, "Deluxe Paint" makes assumptions about the system and hardware architecture with regard to the layout and contents of bitmaps. These assumptions are made when read/writing files, performing data transformations (e.g. magnification) and when using the Blitter to move data. There was no abstraction for this in the operating system which "Deluxe Paint" could have used.

"Deluxe Paint" consists of 88 individual files. Each file is quite short and its contents are "functionally coherent", which means that they serve a common purpose and there is a reason why they sit together in the same file. This is how is should be done. In my opinion the code is well-documented and comparable to other code written professionally for the Amiga at the same time (1985).

Judging by the source code comments I would expect that the last changes were made to "Deluxe Paint" in November 1985. The year 1986 (publication) only appears in the copyright text which the program displays.

There are some bugs in the code, of course. The first one I spotted and which may have been far from obvious at the time is in that the mouse pointer images and the toolbox images which are part of the program itself are not stored in chip memory. Hence, if you start "Deluxe Paint" on an Amiga with true fast memory (or 'slow' fast memory, such as on an Amiga 500 with a 512 KByte memory expansion) then the user interface will become difficult to use. This "glitch" aside, "Deluxe Paint" properly asks for chip memory to be used for image data. There likely was no way to test the program with fast memory, back in 1985.

I venture that "Deluxe Paint" could be ported to a contemporary AmigaOS, if one finds a solution for the dependencies on the Blitter hardware. It could be done :)
Title: Re: Deluxe Paint 1 source code released
Post by: hishamk on July 23, 2015, 04:25:54 PM
Great analysis. Thanks for sharing.
Title: Re: Deluxe Paint 1 source code released
Post by: kamelito on July 23, 2015, 06:48:34 PM
Exactly what can be done with the source code based on the licence.?
It's too cryptic to me.
Kamelito
Title: Re: Deluxe Paint 1 source code released
Post by: guest11527 on July 23, 2015, 07:01:24 PM
Quote from: kamelito;792981
Exactly what can be done with the source code based on the licence.?

From reading the license, you can download the source and modify it for your own purposes, but you may not distribute the modified versions or sell original or modified versions.
Title: Re: Deluxe Paint 1 source code released
Post by: kamelito on July 23, 2015, 07:37:26 PM
Quote from: Thomas Richter;792982
From reading the license, you can download the source and modify it for your own purposes, but you may not distribute the modified versions or sell original or modified versions.


Pretty limited but interesting as a Learning exercice.
But I suppose that you can distribute patches and build system so anyone can build it's own version on top of the original code.

Kamelito
Title: Re: Deluxe Paint 1 source code released
Post by: som99 on July 23, 2015, 07:42:42 PM
Thank you, my weekend is saved :)

@Olsen - Thanks for the analysis:)
Title: Re: Deluxe Paint 1 source code released
Post by: Minuous on July 24, 2015, 03:37:31 AM
Hopefully DPaint 5 AGA will be open sourced too; not sure why they went with such an old version...
Title: Re: Deluxe Paint 1 source code released
Post by: B00tDisk on July 24, 2015, 06:18:02 AM
Quote from: Minuous;793012
Hopefully DPaint 5 AGA will be open sourced too; not sure why they went with such an old version...


"Because Electronic Arts," is why.  2015 EA sucks.
Title: Re: Deluxe Paint 1 source code released
Post by: guest11527 on July 24, 2015, 07:04:33 AM
Quote from: B00tDisk;793019
"Because Electronic Arts," is why.  2015 EA sucks.

Hardly. Because the initiative was taken by a museum, and because the job of the museum (this one, in particular) is to preserve milestones of digital art. DPaint I certainly was, at its time, a breakthrough. All later versions were surely better, improved, nicer... but no longer pushed the limits by the same amount as DPaint I did.

The program does not sit there to give you a drawing program on the Amiga. If you want a decent one, there is PPaint.
Title: Re: Deluxe Paint 1 source code released
Post by: Trev on July 24, 2015, 07:56:11 AM
I'm genuinely surprised by not only the release of the software but the news that EA has folks dedicated to preserving software internally. EA has claimed in the past that their Amiga software was effectively lost to time.
Title: Re: Deluxe Paint 1 source code released
Post by: warpdesign on July 24, 2015, 07:59:55 AM
The thing that surprised me is that it's C-only: there doesn't seem to be any ASM part in the sources. I guess the need for ASM came later.

In comparison, most Mac apps that have been open-sourced by the same museum (MacPaint, Photoshop,...) seem to include quite a large part of 68k assembly.
Title: Re: Deluxe Paint 1 source code released
Post by: olsen on July 24, 2015, 11:05:49 AM
Quote from: Thomas Richter;793025
Hardly. Because the initiative was taken by a museum, and because the job of the museum (this one, in particular) is to preserve milestones of digital art. DPaint I certainly was, at its time, a breakthrough. All later versions were surely better, improved, nicer... but no longer pushed the limits by the same amount as DPaint I did.
I would agree to that. However... "Deluxe Paint II" is not the "difficult second album" which would show whether the band which struggled to make the first album, that somehow became a hit, is here to stay. "Deluxe Paint II" was a major step up, both in terms of functionality and in documentation. It is a much more well-rounded product. It would be cool if one of these days "Deluxe Paint II" source code would be released, too, but my gut feeling is that the "Deluxe Paint" source code release was as much as we will likely ever see.

Quote

The program does not sit there to give you a drawing program on the Amiga. If you want a decent one, there is PPaint.
Well said :)
Title: Re: Deluxe Paint 1 source code released
Post by: olsen on July 24, 2015, 11:15:20 AM
Quote from: warpdesign;793028
The thing that surprised me is that it's C-only: there doesn't seem to be any ASM part in the sources. I guess the need for ASM came later.

In comparison, most Mac apps that have been open-sourced by the same museum (MacPaint, Photoshop,...) seem to include quite a large part of 68k assembly.
From what I learned by looking over the source code, the need to use assembly language was not acute because "Deluxe Paint" could harness the Blitter. It even hardly mattered that the 'C' compiler used in 1985/1986 was not an optimizing compiler. Most of the work done with "Deluxe Paint" is driven by user interaction, which is slow...

The Macintosh did not have a co-processor which would have helped the applications, hence the need to use (presumably hand-optimized) assembly language. Also, the Macintosh Pascal and 'C' compilers were just as poor at producing optimized code as the Lattice 'C' compiler used for "Deluxe Paint" at the time.

That said, the differences in these approaches even extends to the respective operating system. For example, the Amiga "graphics.library" is built around the co-processors (Denise, Agnus) and is written mostly in 'C' with significant portions rewritten or specifically written in assembly language. The original Macintosh QuickDraw by comparison was written entirely in assembly language, with no higher level language (Pascal) involved.
Title: Re: Deluxe Paint 1 source code released
Post by: bloodline on July 24, 2015, 12:18:19 PM
Fascinating! Many thranks for looking the code over!
Title: Re: Deluxe Paint 1 source code released
Post by: Thorham on July 24, 2015, 01:25:13 PM
Quote from: Thomas Richter;793025
The program does not sit there to give you a drawing program on the Amiga. If you want a decent one, there is PPaint.
Or Brilliance 2. Allows you to load images that don't fit in chipmem. It basically only allocates chipmem for the visible part of the screen.
Title: Re: Deluxe Paint 1 source code released
Post by: guest11527 on July 24, 2015, 01:39:45 PM
Quote from: olsen;793034
From what I learned by looking over the source code, the need to use assembly language was not acute because "Deluxe Paint" could harness the Blitter. It even hardly mattered that the 'C' compiler used in 1985/1986 was not an optimizing compiler. Most of the work done with "Deluxe Paint" is driven by user interaction, which is slow...
It's not that assembler is the answer to all programming problems either. Indeed, if C is fast enough, use it.  In this particular case, though, the flood fill is not the flood fill from graphics, but a custom implementation, and that could have taken advantage of assembler. But it was probably not worth it. Same for the circle drawer (which is the nice conic section Bresenham algorithm, though with a couple of "issues" for small circles. It's not so easy to get this right.)  
Quote from: olsen;793034
The Macintosh applications did not have a co-processor which would have helped here, hence the need to use (presumably hand-optimized) assembly language. Also, the Macintosh Pascal and 'C' compilers were just as poor at producing optimized code as the Lattice 'C' compiler used for "Deluxe Paint" at the time.
But then, most programs on the Mac build on top of the Quickdraw calls, so they could have been in Pascal as well (Pascal was the prime language for the Mac, C came later). Mac Paint is really just QuickDraw in all its excellence and not much else, but that's an entirely different beast in first place, being one of the first (or the first?) vector graphics program. I don't know which language it was written in, but my guess is Pascal. (As most high-level stuff in the early Mac models).  
Quote from: olsen;793034
That said, the differences in these approaches even extends to the respective operating system. For example, the Amiga "graphics.library" is built around the co-processors (Denise, Agnus) and is written mostly in 'C' with significant portions rewritten or specifically written in assembly language. The original Macintosh QuickDraw by comparison was written entirely in assembly language, with no higher level language (Pascal) involved.

True. Though, on the plus side, QuickDraw kept a lot more care on proper coordinate computation and raster coordinates, much better than Amiga ever did. It was designed for something entirely different, namely point-precise layout for professional graphics production. Actually, the quickdraw line drawer is not the average Bresenham algorithm you find in the blitter hardware (and in software), but a fixed-point linear algebra based version, and it can do more than just "thin lines" graphics and the blitter does.
Title: Re: Deluxe Paint 1 source code released
Post by: olsen on July 24, 2015, 02:42:23 PM
Quote from: Thomas Richter;793043
It's not that assembler is the answer to all programming problems either. Indeed, if C is fast enough, use it.  In this particular case, though, the flood fill is not the flood fill from graphics, but a custom implementation, and that could have taken advantage of assembler. But it was probably not worth it.
At this resolution (640x400 pixels maximum; PAL resolutions would have to wait until "Deluxe Paint II" became available) it probably would not have mattered much. Comparing the "Deluxe Paint" flood fill code with the "graphics.library" V34 implementation (which seems to have been written in 1985), the "Deluxe Paint" implementation appears to be more robust and far less complex.

The "graphics.library" implementation is written almost entirely in 'C' with just one down-coded assembly language subroutine involved. If I understand correctly what it does, it builds a mask bitmap one pixel at a time, observing clipping rules which come about because of bitmap boundaries. That mask bitmap then goes through the elementary code underlying RectFill(), allowing for the area to be filled in a single colour or to use a fill pattern instead. The "Deluxe Paint" implementation neatly limits itself to the task at hand and does not have to shoulder the entire work which the operating system would have to perform.

Funny thing, "Deluxe Paint" has a call to the operating system flood fill function (called "Flood()") commented out in favour of its own implementation. Some part of "Deluxe Paint" (this should be easier to trace from within a debugger) actually still calls Flood(), though. Why do it that way? I am speculating: because the "graphics.library" flood fill code is of the same age as "Deluxe Paint", it might not have worked well enough at the time to let "Deluxe Paint" use it at all times. The "Deluxe Paint"-specific flood fill code may have been a workaround.

Quote
Same for the circle drawer (which is the nice conic section Bresenham algorithm, though with a couple of "issues" for small circles. It's not so easy to get this right.)   But then, most programs on the Mac build on top of the Quickdraw calls, so they could have been in Pascal as well (Pascal was the prime language for the Mac, C came later). Mac Paint is really just QuickDraw in all its excellence and not much else, but that's an entirely different beast in first place, being one of the first (or the first?) vector graphics program. I don't know which language it was written in, but my guess is Pascal. (As most high-level stuff in the early Mac models).
MacPaint is written almost entirely in Pascal, with many utility functions written in assembly language. Strangely, the utility functions are not all graphics-related but provide interfaces to operating system functions, too. This is an odd mix.

Quote

True. Though, on the plus side, QuickDraw kept a lot more care on proper coordinate computation and raster coordinates, much better than Amiga ever did. It was designed for something entirely different, namely point-precise layout for professional graphics production. Actually, the quickdraw line drawer is not the average Bresenham algorithm you find in the blitter hardware (and in software), but a fixed-point linear algebra based version, and it can do more than just "thin lines" graphics and the blitter does.
Yes, QuickDraw was designed with generalized 2D rendering in mind with specific rules governing how the rasterization would paint bitmap pixels. The original QuickDraw even included functionality for colour rendering which was replaced in later operating system versions when this design did not prove effective. If you look at the design, it fits very well with how PostScript accomplishes the same thing.

By comparison the Amiga model was decidedly about bitmap pixels in planar bitmaps, not points or vectors.
Title: Re: Deluxe Paint 1 source code released
Post by: guest11527 on July 24, 2015, 06:42:04 PM
Quote from: olsen;793046
At this resolution (640x400 pixels maximum; PAL resolutions would have to wait until "Deluxe Paint II" became available) it probably would not have mattered much. Comparing the "Deluxe Paint" flood fill code with the "graphics.library" V34 implementation (which seems to have been written in 1985), the "Deluxe Paint" implementation appears to be more robust and far less complex.

The "graphics.library" implementation is written almost entirely in 'C' with just one down-coded assembly language subroutine involved. If I understand correctly what it does, it builds a mask bitmap one pixel at a time, observing clipping rules which come about because of bitmap boundaries. That mask bitmap then goes through the elementary code underlying RectFill(), allowing for the area to be filled in a single colour or to use a fill pattern instead. The "Deluxe Paint" implementation neatly limits itself to the task at hand and does not have to shoulder the entire work which the operating system would have to perform.

Whether early flood() implementations had bugs I do not know, but the reason for the complexity in the graphics implementation is easily explained: You can setup the RastPort such that the flood-fill fills the area with a pattern (or invert it) instead of only a solid color. You cannot do that robustly without an extra plane, so graphics first computes the area to be filled by marking the bits to be filled in the TmpRas, and then runs through a BltTemplate() on the TmpRas to fill the selected areas with a pattern.

IIRC, DPaint I did not offer such a function, and for a simple solid color flood fill, you do not need the extra plane. Plus, it costs extra memory. If you only had 256K in the base Amiga model, you'd better try to get away with as little memory as possible and avoid the extra plane.

One of the strange things about graphics is that you had to allocate the TmpRas yourself, which makes the whole construction somewhat fragil. Probably the design idea was to make graphics entirely static where graphics resources are only allocated and released by the user, and graphics only "fills the structures". This required a lot of internal structures to be documented, which was a rather bad idea because it made it almost impossible to extend them. And caused such weird decisions to store extended graphics mode information in the colormap (!), the only structure not documented...
Title: Re: Deluxe Paint 1 source code released
Post by: olsen on July 24, 2015, 07:25:06 PM
Quote from: olsen;792972
I venture that "Deluxe Paint" could be ported to a contemporary AmigaOS, if one finds a solution for the dependencies on the Blitter hardware. It could be done :)

Replying to myself: I can now build "Deluxe Paint" with minimal changes using SAS/C and the resulting program actually works :)

The one thing which instantly crashes it, however, is loading the fonts. I have to investigate that...

The source code is missing a 32 bit fixed point multiplication function called FMULT() which should be defined in "lfmult.c", but isn't. It was easy to find a suitable implementation, though.

The airbrush operation runs as fast as it possibly can, which currently renders it somewhat useless, more like dumping a bucket of paint onto the canvas ;)

Brush transformations (bending, shearing, rotation) work. These operations all build upon the fixed point multiplication code.
Title: Re: Deluxe Paint 1 source code released
Post by: kamelito on July 24, 2015, 10:09:07 PM
@Olsen,
I think that you can post the makefile this is not forbidden AFAIK.
Can you also ask Hypérion to release the 1.0 AmigaOS too ?

Kamelito
Title: Re: Deluxe Paint 1 source code released
Post by: Trev on July 24, 2015, 11:58:32 PM
Quote from: kamelito;793069
Can you also ask Hypérion to release the 1.0 AmigaOS too?

That would be cool, but you can learn just as much by reading the Wikipedia page on linked lists. ;-) And message queues. But it's more fun to tease about lists.
Title: Re: Deluxe Paint 1 source code released
Post by: olsen on July 25, 2015, 08:37:54 AM
Quote from: Thomas Richter;793058
Whether early flood() implementations had bugs I do not know, but the reason for the complexity in the graphics implementation is easily explained: You can setup the RastPort such that the flood-fill fills the area with a pattern (or invert it) instead of only a solid color. You cannot do that robustly without an extra plane, so graphics first computes the area to be filled by marking the bits to be filled in the TmpRas, and then runs through a BltTemplate() on the TmpRas to fill the selected areas with a pattern.

IIRC, DPaint I did not offer such a function, and for a simple solid color flood fill, you do not need the extra plane. Plus, it costs extra memory. If you only had 256K in the base Amiga model, you'd better try to get away with as little memory as possible and avoid the extra plane.

"Deluxe Paint" makes good use of TmpRas structures which it allocates as needed, but not in the flood fill operation. This is the first program which I have seen to use a TmpRas as the final parameter to BlitBitMap().

The flood fill operation fills the area line by line, after first figuring out which pixels should be affected on the current line. It then actually draws a line between these points using its own pattern fill function, which is equivalent to RectFill() but which directly uses the Blitter hardware.

Memory issues are a good explanation why "Deluxe Paint" uses this flood fill approach. Except for managing the fill span stack this implementation has minimal memory requirements.
Title: Re: Deluxe Paint 1 source code released
Post by: olsen on July 25, 2015, 09:00:45 AM
Quote from: kamelito;793069
@Olsen,
I think that you can post the makefile this is not forbidden AFAIK.
The makefile (or rather "smakefile") is part of the task, but a few things needed changing first.

Here is what I did:

- Changed all file names to all-lowercase letters.
- Replaced all by and removed all EOF characters.
- Corrected all '#include <..>' and '#include ".."' path names.
- Replaced "#if useTimer" in "reqcom.c" by "#ifdef useTimer", which corrects what appears to be a typo.
- Replaced "stscmp()" in "fnreq.c" by "strcmp()" which corrects what seems to be a bit flip. There is no function called "stscmp()" in the "Deluxe Paint" code, or for that matter the Lattice 'C' runtime library.
- Reconstructed the missing "lfmult.c" file which should contain the LFMULT() function. I borrowed the fixed point multiplication code from libfixmath (https://code.google.com/p/libfixmath/).
- All the header files in the "iff" drawer were missing. I copied the "iff" drawer from the original "EA IFF 85" source code, which matched perfectly.
- Tagged all built-in bitmap and sprite data as "__chip" for SAS/C, which has the effect of placing that data in chip memory.
- Replaced "BootIt()" in "prism.c" with '#define BootIt() ((void)0)'

A working "smakefile" looks like this, assuming that all the code is stored in a drawer named "prism" -- the 'idir="/prism"' will not work otherwise:

Code: [Select]
CFLAGS = params=stack data=far nostkchk idir=&quot;/prism&quot; cpu=any
LFLAGS = smallcode smalldata noicons

OBJS = \
   actbms.o airbrush.o bend.o bitmaps.o blend.o blitops.o \
   bmob.o box.o brxform.o ccycle.o chproc.o \
   clip.o conic.o ctrpan.o curbrush.o cursbms.o \
   cursor.o dalloc.o dispnum.o distance.o dopalett.o dosymreq.o \
   dotbms.o dpiff.o dpinit.o dpinit2.o dpio.o fill.o \
   fnbms.o fnreq.o fontinit.o geom.o hook.o hsv.o iffr.o \
   iffw.o ilbmr.o ilbmw.o initovs.o initread.o initwrit.o \
   keyjunk.o lfmult.o magbits.o magops.o magwin.o mainmag.o \
   makeicon.o maskblit.o menu.o message.o modes.o mousebut.o \
   packerf.o paintw.o palbms.o palette.o pane.o penmenu.o \
   pgraph.o polyf.o polyh.o print.o prism.o psym.o \
   random.o remap.o reqcom.o rot90.o rotate.o shade.o \
   shear.o spare.o stretch.o symreq.o text.o timer.o \
   unpacker.o

LIBS = lib:scnb.lib lib:amiga.lib lib:debug.lib

prism: $(OBJS)
   slink lib:c.o $(OBJS) to $@ lib $(LIBS) $(LFLAGS)
This builds a working "prism" program with SAS/C and V40 header files, although you will have to put up with some 2600 compiler warnings owing to the age and dialect in which the code was written ;)

If you want to build the code with a different compiler, you will need to replace the Lattice 'C' functions setmem() and movmem() as follows:
Code: [Select]
#define setmem(to,n,c) memset(to,c,n)
#define movmem(from,to,n) memmove(to,from,n)
Edited to add: I just discovered that "Deluxe Paint" also uses the Lattice 'C' function "stcu_d()", which however is not exactly the same as the variant which part of the SAS/C runtime library. This version has three parameters and works something like this:
Code: [Select]
int stcu_d(char *out,unsigned uivalue,size_t max_size) { return snprintf(out,maxsize,"%u",uivalue); }Mind you, SAS/C has no snprintf() function, it's just that the third parameter controls how many characters including the trailing NUL byte are written to the output buffer.


Quote
Can you also ask Hypérion to release the 1.0 AmigaOS too ?
I can ask, but untangling the Kickstart/Workbench 1.0 code from what was handed down is (in my opinion) not possible.

These operating system release versions were not clearly marked as being "v27", "1.0", "1.1", "1.2", etc. The change history does reach back to 1985 (RCS -> CVS -> SVN), but prior to that either SCCS was used or no SCM tool at all.

Meaning that the oldest coherent operating system source code is "1.2.1", which bears version number 34, its product name being "Kickstart 1.3".

In my opinion a more attainable goal would be in publishing the V34 "exec" and "intuition" source code (V34 is almost identical to V33), which both represent significant historic achievements, and which cover the whole span of Amiga operating system software from low complexity to high complexity. Both are very-well written and well-designed.
Title: Re: Deluxe Paint 1 source code released
Post by: kamelito on July 25, 2015, 10:05:12 AM
@Olsen
Thanks I'll try that.
Kamelito
Title: Re: Deluxe Paint 1 source code released
Post by: Yasu on July 25, 2015, 04:08:04 PM
Doesn't Cloanto own 1.0 to 3.1 since 2012?
Title: Re: Deluxe Paint 1 source code released
Post by: guest11527 on July 25, 2015, 04:38:12 PM
Quote from: Yasu;793108
Doesn't Cloanto own 1.0 to 3.1 since 2012?

To my very knowledge, they own a license that allows them to redistribute the kickstart and workbench disks and the ROM images. That's not the same as a license on the source code.

Hyperion has a license (and won a case for in in court) to use the 3.1 sources for continuous Os development (as in Os 4 and beyond). Whether they own the source code and can provide licenses on them for anything else (and for publication in particular) is another question that has not been brought to court yet. However, Hyperion is probably your "best guess" as whom you might want to ask.
Title: Re: Deluxe Paint 1 source code released
Post by: Gilloo on July 28, 2015, 11:02:21 AM
@olsen great ! I do the same with SASC6.0 and V51 includes

1) I wonder if the missing LFMULT function is not like that : (lfmult.c file)

typedef long LongFrac ;

LongFrac LFMULT(LongFrac a, LongFrac b)
{
  return (a * b) >> 16 ;
}

2) Don't forget that the original DPaint program is overlayed... so the makefile should contain the OVERLAY keyword, a # and stars somewhere ;)

3) to try the different resolutions, just launch prism with arguments
prism l => 320x200 (default)
prism m => 640x200
prism h => 640x400 (stack overflow when tracing big lines...)

enjoy this 30 years old stuff !
Title: Re: Deluxe Paint 1 source code released
Post by: olsen on July 28, 2015, 11:53:14 AM
Quote from: Gilloo;793193
@olsen great ! I do the same with SASC6.0 and V51 includes

1) I wonder if the missing LFMULT function is not like that : (lfmult.c file)

typedef long LongFrac ;

LongFrac LFMULT(LongFrac a, LongFrac b)
{
  return (a * b) >> 16 ;
}
No, this is not sufficient. You can multiply two 16 bit numbers and the product will fit into a 32 number. But the factors are fixed point numbers, each of which consists of more than 16 bits of information. You are effectively multiplying two 32 bit numbers, which will yield a 64 bit product.

For example, let's say we want to multiply 4 and 16. In fixed point format 4.0 = 4 * 65536, 16.0 = 16 * 65536. Multiply these factors and the result is 274,877,906,944, which is larger than the range of an unsigned 32 bit integer (= 4,294,967,295) permits.

You need a more complex function to handle this properly. The fact that "Deluxe Paint" is broken up into so many small code fragments, each of which implement a complete self-contained set of functions, suggests that "lfmult.c" must be a self-contained code file.

If it were as simple as implementing it as a single line function, then I would have expected it to be in a macro definition in "prism.h", and not in a separate 'C' source file.

Here is a nicer version, adapted from Code found at https://code.google.com/p/libfixmath/:
Code: [Select]

#include <exec/types.h>

typedef LONG LongFrac;

LongFrac LFMULT(x,y) LongFrac x,y; {
/* Each argument is divided to 16-bit parts.
**          AB
**      *  CD
** -----------
**          BD  16 * 16 -> 32 bit products
**         CB
**         AD
**        AC
**       |----| 64 bit product
*/
LONG A = (x >> 16), C = (y >> 16);
ULONG B = (x & 0xFFFF), D = (y & 0xFFFF);

LONG AC = A*C;
LONG AD_CB = A*D + C*B;
ULONG BD = B*D;

LONG product_hi = AC + (AD_CB >> 16);

/* Handle carry from lower 32 bits to upper part of result. */
ULONG ad_cb_temp = AD_CB << 16;
ULONG product_lo = BD + ad_cb_temp;
if (product_lo < BD)
product_hi++;

return (LongFrac)((product_hi << 16) | (product_lo >> 16));
}


Quote

2) Don't forget that the original DPaint program is overlayed... so the makefile should contain the OVERLAY keyword, a # and stars somewhere ;)
I used overlays before, when I did not have much of a choice. They are an ugly solution to an ugly problem. Everything becomes harder when using overlays, including debugging. No, I'm not going to foist overlays on anybody.

Quote

3) to try the different resolutions, just launch prism with arguments
prism l => 320x200 (default)
prism m => 640x200
prism h => 640x400 (stack overflow when tracing big lines...)
There's more. The second parameter allows you to set the screen depth. The command line parameters are documented in the reference card, which is available on the same http://computerhistory.org page as the "Deluxe Paint" source code.
Title: Re: Deluxe Paint 1 source code released
Post by: woof on July 28, 2015, 12:06:09 PM
Hello
@Olsen
Perhaps you can suggest the Computer History Museum to host also your modified sources: It will pedagogically show how little modifications was needed to make  up to date this well written old source

Alain Thellier
Title: Re: Deluxe Paint 1 source code released
Post by: x303 on February 14, 2016, 07:34:35 PM
Quote from: olsen;793060
The one thing which instantly crashes it, however, is loading the fonts. I have to investigate that...

The menu can only hold a few fonts & size, so if you have more than a few fonts available, "DP" might crash. But if you stick to just a couple of fonts, the code works as expected. It's simply not designed to have lots of 'em....

:juggler: