Working more on the Trackview to show the height and speed track, added a simple Popup Menu and a Data Reader. In the beginning I wanted to use the Bubble function of MUI to show the coordinates, but it flickers like hell if you move it over the map (because you have to destroy and recreate every time) and it makes very bad redrawing errors. On AROS for example when the bubble is over an other part of the window, the background behind it will not repaint, when the bubble disappear. On Amiga the background of the window is visible on the edges instead of my curve background. Also added a fine grid for better visibility of Values and heights, still fixed but maybe later can be disabled via menu.
I implemented a on screen (on-map) menu for zooming and to show the side panel, so do not need use the menu. I did that already for Mapparium but there only released for the special ARM version. There is also a key control available, the + and – keys can be used for zooms and cursor keys for movement.
I guess it will need one or two more version for MUIMapparium to reach the features of Mapparium but I guess it will be MUIMapparium will takes the Mapparium place (and Name) in the end.
Still playing with locale settings on Amiga systems. FreePascal offer a possibility to care about international settings like decimalseparator, date formats and currency symbol. So I looked a little bit into and the system is comparable, still much work, so I’m not sure if really put to every start of a program, or maybe it would be better to put it to a separate unit and you have to include and invoke it by hand. We will discuss that.
Testprogram with Germany, USA and UK Locale Setting
Starting the same test program 3 times and changed the Locale Country setting in between. (For me rather funny that the currency format for positive and negative Values are so different not so nice if you have them in a table) But so far it works very nicely.
LCL has powerful packages for example the Chart component (or the Edit component with Highlighter). MUI already have some, but not so powerful and not available for all platforms (especially ARM-AROS and AROS64). I try to keep on the included basic classes to keep it compatible.
I used the very powerful TAChart component in Mapparium to show the Height/Speed trace of a track. Of course for MUIMapparium I also want to have that, so I started to implement a plot class for MUI. Not so powerful but already very nice with two Y-Axes, Zoom and Autoscale.
MUI Plot component start
It already works rather nicely, as first approach can be used like this.
I designed it already in a very abstract way in principle a TPaintBox for MUI and based on that the Plot class, that means I can use them in other programs as well.
Activated the localization for MUIMapparium currently only for english and german (of course ;-)) implemented also the local library unit for AmigaOS4 so localization is available on all platforms.
I also activated the AREXX interface currently only two commands are implemented: goto lat lon [zoom] to jump to a position and addwaypoint lat lon “Name” to create a waypoint. The Portname is the same as for Mapparium an example script can be found in rexx folder. The AREXX port does not work for AROS, Zune has no AREXX support currently.
I tried to compile it on AROS64 sadly the program did not work, it just freeze. Little bit strange sometimes it start but crash directly. I tried some other programs on AROS64 and they work rather nicely so why MUIMapparium not. The difference was easy it uses threads, finally I found the solution, the Critical Sections in FreePascal are mapped to SignalSemaphores of Amiga. In contrast to other OS the SignalSemaphores are not just simple pointers but a complicated structure. The given size there was ok for 32 bit Systems but for 64 bit the structure is much bigger. I included it for that release maybe someone want to try it 😉
Working on a very old bug. I’m not sure if someone noticed it, at least nobody reported it. The coordinate to pixel conversation was not very precise because it used a average resolution for every tile. This works well for higher zoom levels where the resolution does not change much inside a tile. But for lower zoom levels, especially the whole world picture this is certainly not right any easily visible when using way points. See for example Mapparium 0.6 on the right side of the image, all way points are (and tracks) are shifted to north. The solution was not very difficult but needed some thinking, basically a rounding error and precision problem.
MUIMapparium (Left) and Mapparium (right) Waypoint position comparison and german locale
I also start to play with localization. I never did that before, especially not in FreePascal but it’s not very complicated, just diligent work to replace all strings. So next version will also be available in german (and maybe later some more languages, at least I got an offer for french localization). There is one small problem with that, there is no locale library unit in FreePascal for AmigaOS4 so either I make some defines to turn it off for OS4 or implement the library unit.
Had some time to work a little bit on MUIMapparium, mainly implemented way points and tracks including loading and saving, same formats as Mapparium. Due to multiple requests I created a OS4 version again, but I have no way to test it. Still it’s only a very early version of MUIMapparium.
Yesterday I was at the Amiga and retro computer meeting here in Berlin, always nice to be there and talk to the people. ChainQ was also there so we worked a little bit on this strange WBStartup problem on MorphOS. As some already mentioned in the comments to MUIMapparium, it is not possible to start fpc compiled programs at MorphOS via an Icon. The programs just do not start directly freeze, the reason is simple, when starting via Icon the WBStartup Message is sent to the application via an MsgPort at the Process structure. Freepascal waits for this Message, which never arrives. After some trying we found, that the needed structures and functions in fpc are in good shape so not the root of this problem. The problem appeared when ChainQ changed the startup code from a assembler one to a pure Pascal startup code. So my guess was that it somehow relates to the needed symbol inside the executable, which defines it as a MorphOS executeable __abox__. Of course I do not have much knowledge about it, just a wild guess. But it turns out that this was quite right. The first problem is that I used an older version of vlink, which seems to have a bug and removed this symbol (because never used). After an new compilation of vlink the __abox__ symbol is there but still it do not work. ChainQ knows a little bit more about this stuff and also knows whom to ask in the inner circle of MorphOS developer what could be the root of it. Some strange things I was able to see, the program I started stopped when starting via Icon. But via TaskManager you can see, two of them are started. An other thing with Snoopium you can check when the program does at the start. Especially the OpenLibrary function is interesting in this case. You can see how the program tries to open the ppc.library, which I learned now, is a sign that MorphOS thinks that this program is an PowerUp executable, which explains the odd behavior. In the end the solution was not so difficult, FreePascal did not set symbol type and symbol size as expected by MorphOS. (The size is important because the __abox__ symbol should point to a longword with value one) It appears FreePascal already have a function to care about such things, which only have to be activated for the MorphOS compiler. Finally it’s fixed again. Thanks for the help.
Some people ask me to supply a Version of the MUIMapparium presented yesterday. No problem, please just remember it’s heavy work in progress, not much is working currently. In principle only Mapping and searching function, but this is already nicely working on all my available Amigas. Please note the m68k-Amiga Version needs RTG (or it will just crash), OS3.1+, MUI of course and without network it’s not really useful ;-). The Amiga Version works nicely on Vampire A600 (RTG Screen) but should also work with every 68020+ Amiga with graphic card, just a little bit slow perhaps. (FPU is not needed, in contrast to Mapparium)
Some days vacation, used the evenings in hotel to re implement Mapparium in native MUI and with fpimage for loading the PNG files and Drawing. The Drawing is faster than LCL (the LCL wrapper is huge, already slow) but still rather slow. At last I wrote a own Drawing routine which made it fast enough to start it on a native Amiga with Vampire A600. And it’s nicely usable even without FPU but of course on a RTG Screen.
Tried some (Integer) Speedtest, some people asked me about. Of course I’m also interested if my feeling (double 060/50 speed). I used some code from Benchmarks Game. Especially the tests: fannkuch 10 and BinaryTree 15. (68060/50Mhz= A1200 with Blizzard 1260, MorphOS = MacMini 1.4Ghz, UAE/AROS/Linux = Athlon FX 8120 3.16 Ghz)
Speed rel. to 060
Speed rel. to 060
MorphOS 68k emul
So my feeling was more or less right, it’s around double speed to 060, so it’s a nice step but far far away from UAE. More interesting for me would be FPU processing but at this point the comparison would be very dramatic and a little bit unfair because Vampire still have no FPU support (even it’s everywhere announced, but seems even next version will not have FPU).