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
EdiSyn had some problems on the experimental Icaros, Menu look very strange sometimes it also crashes. I fixed the problem and re-uploaded the archive for EdiSyn. Because yesterday I played around with printing so a basic printing option is also included. It’s really very easy, its like copy the the text file to PRT: with a small header to make the font smaller.
I did some tiny fixes in EdiSyn and some big changes in the LCL also have an influence to the editor. So it makes sense to release EdiSyn again.
Fixed Errors:
- Some redrawing errors, multiple redrawing removed, so it should be faster now.
- Default colors after introducing the new highlighter restored
- Buttons of message windows fix, correct index of clicked button
- green marker for Hints in Freepascal output
- Basic printing (text only to PRT:)
- Bugfix for menu in experimental Icaros
Download as always on the EdiSyn Page
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.
I played around with AROS64 and freepascal for x86_64-aros. the compiler self works nicely, only sometimes some crashes because it does not make it’s own stack like the other amiga/aros implementations. I should really implement that soon.
For that I got the AROS source and compiled my own AROS 64 bootable CD and setup a qemu with it. There is no official AROS 64bit distribution now. I remember some announced one long time before but nothing happend. So now I will release my little work, together with a working freepascal compiler and named it „The 100% useless AROS distribution“ or short T100pUAD.
The Distribution gets its own page: T100pUAD Page
It includes some ore themes and freepascal, later I will try to improve it more and update it to the latest changes, maybe the 64bit get a little boost, it really needs it.
The freepascal IDE I did not get to work, always crash at the same place, but it’s deep inside of AROS and maybe some memory corruption before. So rather hard to find a reason.
I wrote a program to Inspect MUI properties. Very helpful to read out positions and recheck the size calculations of LCL. The main problem at the start was how to tell the program which object I want to inspect. The idea was to type the address from debugout. But then I noticed that the Userdata of the intuition Window structure points to the MUI Window.mui object. Thats means I can simply browse through all the windows on the screen and search for windows with a Userdata and try to find if it is a MUI object. Check if the Class of the object is „window.mui“. I tested also with other UserData contents, „mostly“ it does not crash.
But this only works on AROS, I tried the same on MorphOS but there the UserData is always nil. Seems they use an other method to link them together, its a pity.
The program for i386-AROS is named MUIInspector and can be downloaded here:
MUIInspector 1.0 for AROS
Sadly many important fields of the MUI object are not readable so not all important things can be read back to the list.
Be warned, when the program which is inspected is quickly changing, means destroy/create objects, maybe the MUIInspector is crashing. So its really only a debugging tool for me, but maybe other find it interresting as well
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.
