Working on the Mapparium, implementing an view for the height and speed curve of a track. The new TAChart component became much more powerful the last years. Now one also can add multiple Y-Axis so different scaling for two curves.
When you click on a track (single mouse click) it shows the curves for this track with the time as x-axis and height and speed as y-axes. I’m not sure if the distance would be a better x axis as default.
I saw already on MorphOS that the arrows for spin edit are rather big if they are one over the other. The idea was to make them side by side.
The OpenStreetMap is now named Mapparium and I created a Release, until now only for MorphOS and AROS(i386). The Version for Amiga 68k needs a little bit more optimization, and for AmigaOS4 it needs a request ;-).
Implemented GPX reading and writing, really very easy. Tested with some of my cycle routes (I cuted the start away for the screenshot). It also saves the waypoints and tracks into a default.gpx to load at next start, its the easiest way to start. At the moment I draw a little rectangle at every track point and connect them with a line. Sadly it seems to be not possible to draw a thick line with the standard methods, the PenWidth and PenHeight in RastPort are ignored. so I guess this point approach works best for recorded tracks. For planed routes with little points its hard to see. Maybe I write an own line drawing routine, with Bresenham it should be possible to make.
OpenStreetMap with Waypoints and Tracks
Besides I increased the speed dramatically on drawing, on Amiga 68k its much faster now, even usable and resizing on MorphOS with less problems and much faster, it does not recalculate the complete image on every resize step, but only draws the image.
More work on the OpenStreetMap viewer for Amiga systems. If a Tile is needed it will be set to a Queue and an extra thread checks the Queue tries to load the file from the hard disk, if it does not exist there it loads it from internet. The image shows a special replacement image as long the image is loaded. Of course if you browse around soon the number of tiles become huge. At a time you need to clean the tiles from memory. I introduced a maximum tile number to hold in memory (currently 1000). At every tile the time of last use is noted. The list is sorted and the oldest are removed (oldest means longest time not used).
It works already very nice, I added a little statistic window to see, when tiles are loaded from HD or from Net. Later I will introduce a prefs window to configure the number of tiles to keep in memory especially for Amiga 68k would be important to reduce the value. 1000 tiles needs around 150 MiB. Also the cache on hard disk could be inspected and deleted then. I checked my cache folder, which stores the tile files since I started this work, there are 8400 files inside with a complete size of 150 MB, so its not so urgent to clean it. OpenStreetMap suggests to keep the cache images for at least 7 days or check the status online. I do not plan to edit, so for me it’s not so important to have the very last map updates.
The next step to become more useful I added a search function, already work very nicely, only had some problems with german umlauts (äüö) and other standard characters (é,è,Î and so on). The Input from the Edit needs to be converted to UTF8 using AnsiToUTF8(). Maybe I should do that already indide the LCL code (like I make UTF8ToAnsi when drawing text to screen, thats the reason the copyright sign work).
AmOSM with Search function
The further work will include waypoints and tracks/routes with import and export of GPX data, usual format of GPS devices (mine also) and maybe KMZ the Google Earth format. In principle it would be nice to also read GPS data from a real GPS device, which is connected via serial cable with computer. I’m wondering how to use serial connection in AROS, if even possible, maybe even with an USB to serial adapter, most computers does not have serial connectors anymore.
New Version for the Virtual Lazarus crosscompiler, some crashes with mouse events (OnClick, OnMove, OnEnter, OnLeave), Redrawing and resizing problems and of course the biggest change adding support AmigaOS4 (PowerPC). I removed some not needed files and installations, so the download is much smaller this time.
Changes in short:
FIX: Redraw problems on AmigaOS3
FIX: Size problems
FIX: Mouse event crashes
ADD: Support for AmigaOS4
CHG: Striped image from unneeded things, reduced download size
I am thinking how to make an online updater, in principle not so difficult with a script, svn update from repository, recompile/install all compilers/crosscompilers, update lazarus repository, recompile and install lazarus, done.
I created a Release for the Free Pascal Compiler including RTL, Packages and a pre-alpha version of the Lazarus component Library.
For me the AmigaOS 4 implementation is considered as “done”. I will take care only that changes in FPC does not break the OS4 port and also the LCL changes not break OS4 compilation.
As promised, I cared about drawing with alpha channel on m68k Amiga. Little bit background. When I make a StretchDraw() the raw data is scaled directly in pascal (to keep the alpha channel) via a nearest neighbor routine. And exactly there I need to touch every pixel to scale it, of course a good position to also care about the alpha channel. For speed optimization the special cases 0 and 255 alpha channel are handled separately. And its not so slow as I thought, so I let it inside.
Amiga m68k with alpha channel drawing (left) and as comparison on AmigaOS4 (right)
Besides this I worked more on size calculations especially on MorphOS, still not completely sure how it should be. An additional problem appeared in the OS4 LCL. The size calculation as done before crashes, because it reads the Width/Height from the the MUI object which seems to be forbidden inside the Layout. If think about it’s not very surprising because the layout is called before the window is opened and to get the right size the Layout must be done. So I had to rewrite the section with AROS in mind of course. Seems it works now (again? I hope). With this changes the EdiSyn now also work on OS4.
Working on the image drawing in LCL, not only for OS4 but for all, the problem is that it needs (semi-)transparent drawing. I started with Picasso96 for OS4 but it seems it still has no Alpha channel support. But luckily it also supports the cybergraphics compatible layer with the alpha channel support. So I changed everything in LCL back to cybergraphics, which is even much better, because now it’s the same for all platforms.
On this occasion the problem on MorphOS came to light. I always had the problem that at MorphOS the images are not shown. I thought it is a problem with resources but now it became clear, it’s the drawing the globalalpha value was too small.
Sadly the cybergraphics on classic AmigaOS does not support this Alphachannel, thats the reason the image has the black border in the screenshot. Maybe one could try to make a simple Alpha (0/1) by hand, which will be very slow I guess.
Besides I found a big Event problem. Got this as bug report already, it was just a not initialized variable. A little bit more testing and I will make a release and also create a Virtual Lazarus again with all 4 platforms :-).
The AmigaOS4 LCL worked somehow but it did not draw anything on the LCL drawing procedure. Added some debug output and it seems everything works as expected. Finally I got it to work. So now the ColorIt game also work, maybe someone want to try.