When starting EdiSyn on MorphOS many debug outputs appear in the LogTool which tell something about an odd BltTemplate call. Luckily Jaca from IRC and ond morph.Zone was able to help me and identify this problem as a text output to a bitmap over the edges without a clipping layer. And thats right, I use a buffer bitmap and rastport which does not have a layer. He kindly explained me how to install a trivial layer to it and it work. Much faster now (4 messages per second or so, on every redraw). So I made a little Video about the basic EdiSyn function.
It looks very slow, and sometimes the mouse seems not to react properly but this is only because its recorded via VNC, I didn’t find a screen recording tool for MorphOS.
Besides this I solved the sizing problem for MorphOS. The Window object in MUI returns the outersize of the window, Zune the inner size. The ClientRectangle is taken from this Value in LCL, the problem is that when the ClientRectangle is requested the Window is not open and later it’s cached somewhere so never asked again.
So on GetClientRectangle I check if the window is open and reduce the MUI returned size by the Border of the Window structure. Additionally when the window is open (set visible to True) I invalidate the client rectangle cache, there is a special call for it.
This results in a reasonable size calculation, at least the result looks comparable to AROS/Zune:
I tried EdiSyn on MorphOS before looked kind of ok but the text was not visible. Today I got an idea for the reason, the minimum/maximum size constraints hit me again :-O. My Drawing areas are Groups and as long there is nothing inside the maximum size is rather small. So the solution is rather easy connect to all my own Classes a Layout Hook. EdiSyn works now better, still looks a little bit strange, and also does not really work, still needs some work, but hey I’m happy already.
EdiSyn on MorphOS
This weekend I changed a lot in the Freepascal packages for MorphOS and Amiga. For both moved the OpenLibrary and CloseLibrary to Initialization Section and Finalization Section. This bug was the reason LCL programs always crashed on Exit on both platforms. Because this bug is now removed it worth to setup a nightly compilation of the LCL for both MorphOS and Amiga and include it into the nightly experimental Releases. At First I cared about MorphOS sadly I had to deactivate the „vlink“ as linker it seems to have problems with resources. But besides this its working fine.
So from now on Freepascal 3.1 including the latest LCL compilation can be always found at:
FPC – experimental Releases Packages
Freepascal MorphOS with LCL
Unarchive the file, there is a folder pp with icon inside, place it where ever our want, make an assign Freepascal: to this pp folder. Add the binary folder to path: „path add Freepascal:bin/powerpc-morphos“.
Navigate to your sources and compile your program with „fpc sourcename.pas“ or if it is a Lazarus (LCL) source with „fpc projectname.lpr“. Examples for Lazarus sources usable with this LCL implementation you can find in fpc-tests/lcl.
With this new fixed LCL for MorphOS I recompiled some of my AROS LCL Programs for MorphOS. THis time I striped them and packed the program with lzmaloader to make the executable smaller. So here they are:
- ColorIt – Game – Flood the field with the same Color
- FPCMines – Game – Minesweeper clone
- BinShifter – Game – 2048 clone
- PasteQuick – Application – Copy Clipboard contents to Pastebin.com and receive the link in Clipboard
I tried to find the origin of the slowness for buffered drawing at MorphOS and it seems I found a clue. I allocated my Bitmaps always without BMF_DISPLAYABLE and this seems to be the Origin of the stuttering mouse and speed problems, now I changed all AllocBitmaps to use this flag and all it fast, especially the Bootup is now fast as I would expect. Seems my Drawing routine needs a little bit more work and thinking. At least its fast now and the color problems are also gone.
EdiSyn on MorphOS, at least it does not crash anymore, but it need long time to start and the SynEdit does not show anything, Menu also does not work, hmm strange.
Some more strange things appear, the Edits does not show the contents if the edit cursor is active in it, when one leave the Edit, the test is visible, also the TextEditor and Scrollbars have some strange colors. But it become even more strange: When I start the m68k-amiga version on MorphOS it looks ok to me (also in WinUAE or on a Native Amiga 1200)
I noticed something strange in MorphOS LCL, I made a little Painting program in LCL. When the mouse moves over the image and the window is not active it works as expected (coordinate and pixel color) but when clicked into the Painting area or the window is active it becomes very slow and the mouse pointer stops.
I made some tests and noticed the difference is that the main painting region gets repainted and there it becomes slow, but its not the drawing routine self.
MorphOS SimplePaint
The drawing works at the moment in this (buffered) way:
- MUIM_Draw – Event appears
- MUI_AddClipping – set a Clipping
- Create a new Buffer RastPort
- Create a Bitmap (AllocBitmap) for the Buffer Rastport, with width and height of the drawing area, Depth from the MUI rastport (from Renderinfo), BMF_MINPLANES or BMF_CLEAR and the bitmap of the MUI rastports Bitmap as Friend Bitmap
- ClipBlit of the MUI Rastport to the Buffer Rastport
- Drawing of the LCL things to the Buffer Rastport
- ClipBlit of the Buffer Rastport to the MUI RastPort
- Destroy Buffer Rastport and Bitmap
- Remove Clipping
- Leave Draw Event
If I remove the Buffering, so draw directly onto the MUI RastPort it stays fast and the mouse pointer makes no problems. When the program starts this stuttering mouse pointer is maybe related to it also? I noticed also other programs have this stuttering mouse on start (OWB for example). I still have no idea why.
This year freepascal got a big advance on many levels, in general with the freepascal 3.0 and for the Amiga-style systems also. Even more advances on the LCL/Lazarus topic on Amiga, AROS and MorphOS.
It began in 2014 already, when I restarted the MUI LCL implementation for AROS. Begin of 2015 I cared more about some applications to test the implementation especially the owner drawn things. So I wrote ColorIt and FPCMines for AROS and tried to write or port some little apps and some more.
A milestone reached in march 2015 when I got the SynEdit component to work. The little test program I used to play around with the needed changes in LCL grew on requests from the AROS community to a full usable Editor, which got the name Edisyn. By improving the editor many additional features are included into LCL, like key events, advanced mouse events, tabs, scrollbars, colors and much more.
With all this improvements I felt ready to give the lazarus ide another try and finally at least it starts. So we are on a good way to bring lazarus natively to work on AROS.
But how about the other platforms (AmigaOS and MorphOS)? I did already some changes in the code with the other platforms in mind. When the resource support was enabled in freepascal I took the opportunity to try to port the LCL for MorphOS and m68k AmigaOS. Which somewhat worked but not in the same way as in AROS especially the layout did not work and the program always crashed on the end. But it gave me much insight how MUI is working also for AROS Zune which is a little bit more error tolerant than the original MUI.
Also on the freepascal front some new things appeared, the support for x86_64 AROS was included, but sadly because of the ABI difference the port is still not finish and unusable. I’m waiting for the ABI switching feature in freepascal. The implementation is done just I need the decision to do it in the proposed way.
In October I did something unusual for me, I did C coding for AROS, trying to code a dynamic Amiga-style Library (in this case sql) to use it in freepascal AROS. But later I found out this wrapper library is not needed and I can directly use the C linklibs as they are.
At the end of the year I took more work again on the MorphOS and m68k Amiga LCL and finally got it to work. So the first LCL programs can be compiled for MorphOS and m68k Amiga.
What 2016 will bring
I hope I can join the two LCL implementations (AROS on the one side and MorphOS and Amiga on the other) together again. Bring the MorphOS port to the same level as AROS, that maybe Edisyn will work. The next logical step would be to continue on lazarus ide and try to make it somewhat usable.
to everyone who read this 😉 I hope you have a nice christmas meal and some quiet time with the family, I will certainly have.
As Greeting to everyone I wrote a little program, nothing special, just a christmas tree and some falling snowflakes (needed 10 minutes to write in lazarus, I watched the clock).
You can download this little program for:
Amiga, AROS, MorphOS and if someone is interested the Source
Since MorphOS works rather nicely I tried to compare with Amiga 68k some more things have to be changes, especially drawing is much more difficult. AmigaOS3.x does not have the concept of RPTAG_FGColor to set directly the forground color with 24 bit values instead you have to use ObtainBestPen and so on. And there it is difficult to find out how long this Pen should stay before it can be released again. A little bit helping here is the Pen and Brush concept but for Background color and Text color its not really helping. But finally its working. But the picture looks very strange. After some testing I noticed that the GfxMove command make something strange, Even I call it with GfxMove(RastPort, 120, 130); the point is somehere in the negative region for X and Y. But Draw(RastPort, 120,130) for example work. Ok MY GfxMove call looks not like this but more like
GfxMove(RastPort, GetOffset.X + X, GetOffset.Y + Y); (Getoffset is a function which returns a TPoint) It seems that the m68k compiler have a problem with this construct because if I calculate an NX := GetOffset.X + X; and NY := GetOffset.Y + Y and then Call GfxMove(RastPort, Nx, Ny); it work. really strange. Besides it seems sometime it does not update the background and you get something like a ghost pattern hmm still much things to investigate. But for now I’m very happy that it already somehow work.
LCLTests on Amiga, MorphOS, AROS, Linux, Windows
I compiled the two test programs Button (Source) and PaintBox (Source) on every platform I have available.
There we have:
Upper line, Left Linux, Right Windows (via Wine)
Lower line from left, AmigaOS3.9 (WinUAE), MorphOS (via VNC), AROS (Linux hosted)
All programs compiled from the same source without a single ifdef, as you can check at github. Amazing isn’t it :-D.
