I packed Sodoku as an ADF, not bootable becasue it needs intuition.library, so you have to load Workbench first. It needs around a 1.5 Mb RAM. Sadly I still not get the newer FPC Version to work (strange crashes, looks like some memory corruption, because it always crash at different positions) so the executable is still rather huge (550 kb vs 52 kb) and therefor needs a lot of memory to load it.
I dig out my old Version of FreePascal for Workbench 1.3 and I tried to use it with the latest FreePascal, and it seems not to work. Thats bad because the smaller exe size was after that, so the executables are still quiet big.
So I should check again how to do that.
But first I played a little bit with it and wrote a little Game for the Workbench. A Sodoku which worked quiet nice, just the graphics is rather difficult because many of the convenience feature to create Bitmaps and rastports and so on are not there so you have to do it by hand.
MAybe you do not know it but FreePascal turned today 25. On 8th June 1993 Florian Klaempfl started with current FPC source base.
I will take this opportunity to say thanks for that. It’s an awesome program and becomes better and better Also thanks to ChainQ which gave me the the chance to use my favorite language on my favorite computer system.
I tried the MUIMapparium on my real Amiga 1200 with 680030 50 Mhz (With 68882 FPU). Good news, it works somehow, of course it is slow but once the images are loaded, it moves ok. Unitl now it freezes a little bit when release the mouse button… maybe I should try to find the reason for that.
I also tried on a 16 color screen, much faster… but looks awful 😉 so I decided to make the Video with a 256 colors screen 😉 even it’s slower.
Still playing with Datatypes in principle not so difficult, maybe could make it a little bit easier with some wrappers. The Datatype system even take care of scaling the image to the actual screen depth and dither the image if needed.
Until now MUIMapparium need a 15Bit+ Screen because I use Cybergraphics functions to draw the stuff to window. But when loading the pictures with the Datatypes it would even run on an AGA screen with less colors.
I gave it a try and the first version works rather nicely.
MUIMapparium on a 32 color Workbench
Of course it’s just a ugly hack until now, not at all optimized and maybe even crashing or eating memory. But maybe worth investigating a little bit as alternative.
I added some debug output at AmigaOS4, so if you experience problems starting up MUIMapparium on OS4 check the debug output (e.g. Sashimi) it should count from 1 to 26 on the bootup, check if any numbers missing and send me the result on one of the forums I’m usually on.
Worked on the broken Search function, I guess I will publish this tomorrow, the new functions are not finished but without the search function the program is more or less useless. The new function is the list of Photo with EXIF GPS positions, as Mapparium also had. It can use Datatypes (need jpg Datatype of course) or the internal pascal JPG loaded, which seems to be slower most of the time, especially on big endian systems. The photos are grouped by date if you double click the date entry it try get all photo markers in sight, when clicking on a photo it shows it.
Currently the Search function is broken, because the service used for it changed to SSL only which is not supported by MUIMapparium at the moment.
I will work on this the next days, so wait for 0.7 to fix that.
and because there is an error in the source MUIMapparium will crash instead of printing the errorcode
The routing function is also affected by this of course.
I created the datatypes unit for AmigaOS4 and AROS and rewrote the ones for Amiga68k and MorphOS. OF course the aim is again to make them more or less compatible to each other. Of course also wrote a little test program and compiled for all systems which works nice.
DataTypes test for Amiga68k, MorphOS, AmigaOS4 and AROS
Now I have to learn how to actually use Datatypes in a program, especially seems sometimes the datatypes seems to scale down to 8 bit (256 colors) even the screen has 24 bit which I do not understand and if there is a way to let the datatype scale the image to the right size. I use the BitmapScale from graphics.library but this is awfully slow (At least on AROS, even my straigh forward nearest neighbor routine is faster than that).
When calculating the statistics value for the track export I thought it would be nice to have them for the normal Tracks Properties Window as well and also repaired the color indicator for the right and left axis for MUI (in Zune it worked).