Worked a little bit on Leu, a click on row/column title it selects the whole row/column as used in other spreadsheet applications. On RTG Screens with 15bit or more colors the selection now blends the background color instead just replacing it, that means you can still see different background colors when selected.
Multi-line is something people where asking me for, so I implemented that, if you are in a cell typing you can use Ctrl+Enter to go to next line, instead of finishing the editing. I got a question, if I plan to support different Font sizes and type, and I’m not sure about that until now. It would need a complicated replacement table from the Windows/Linux fonts to typical Amiga fonts and back. Especially on classic Amiga the Font sizes of Windows and Linux are WAY to big. We will see.
Leu with Multi-line text, column selection and blended selection color.
A while before I was working on the cell format (number format, date, time and so on) but this is rather complicated. It needs a bit more time it’s still not reliable but I want to finish it before release the next version. Some of these features (like the selection blending) are already present in the Leu version I gave Paolo Besser for the Icaros64 alpha WIP.
Improved the real time raytracer (no GL, just pure Math-Power 😉 ) a lot today, first introduced movement, standard „wasd“-Movement and mouse look. then I thought it would be cool to select blocks and change/remove them, for that I had to rewrite the raytracer to remember where I hit which block, but then the raytracing part became much slower, so I wrote a second routine exclusively for selecting Blocks (and a face of a block) which worked nicely. Of course much cooler it would be to also set new blocks. Easiest way is to just look at a face of a Block and add there an other Block. And it works well. I made a little movie to show how it looks like now.
You might notice that the image becomes a bit worse when moving. I decided to lower the resolution when moving, so you can fast move but have a nice image when stand ;-).
Again I show that on Icaros64, why, easy, it’s much faster, around double speed I would guess. You might ask why that is the case, easy, you have a lot more registers in x86_64 also for SSE3-Math calculations so much less memory access. And I also guess the optimizer for x86_64 in FreePascal is better than the one for i386. But it comes with a price, the exe is much bigger, 160k for i386, 260k for x86_64, but still rather small when you consider what it can do already 😉
Again playing with 3D stuff, realtime raytracing, but this time a little bit stripped that it also can work on a real 68k Amiga, like the Draco, so without mirrors and so on. The new improvement by Charlie in the FreePascal compiler seems to work as it should be and also increase the speed a little bit, so it’s almost fast. Ok its still horrible slow, but hey the first version needed around 10s per frame, now it’s under 2s.
Also tested with AROS and because its the new „hot stuff“ of course on AROS64 and even the image is 4 times bigger it moves smoothly. If you make it the same size as the Amiga68k one, it needs around 8ms per frame but the window is very tiny.
It’s still heavy with floating point calculations so the 68060 is very good to use the 68881 will be much too slow. I also tried the Vampire 68080 which have a much faster but not so precise FPU. Good news it works, bad news it looks broken. I only use Singles everywhere and removed all Round() from the source but still it looks completely wrong, no idea why.
Paolo Besser works on a 64bit Version of Icaros (see also his website about it). I only try my AROS64 bit FreePascal stuff with my old linux hosted AROS 64 version, and there it worked fine. But the ABI of x64 AROS is not fixed yet, so still changes can happen. And there are some changes, Leu for example crashes on the Icaros64 alpha version, Paolo sent me. It crashes very early in the startup code. I started to debug that stuff but it’s very hard to debug at this point, that early in the startup. But my initial guess was more or less right, because the AROS devs tried to implement SMP they changed a lot of structures for additional locks and so on, so the Offsets of fields are moved. Usually an easy job just compare the the new C includes with my pascal counter parts. but it makes it much harder if defines and alignment comes to play, here also. The define was easy, there is a __AROSSYSTEM_SMP__ define which seems to be always enabled, even AROS is not compiled for SMP use (seems still too unstable) which includes and additional spinlock_t to MsgPort and Sempahore, so far so well. But it seems this spinlock_t is huge, by the definition I would say an Integer and a Pointer, but the size needed in the structure to cover up the missing offset shift is much more… something around 256 bytes. The structure is 128 aligned, this could be a key for that.
Usually that is not hard to find out, just make a small C program and test the sizes and offsets of the related structs, but… who have guessed it … on Icaros64 that is not that easy, because the gcc installed does not work, it just crashes. And btw. collect-aros, which we need fore linking in FreePascal also crashes, so for sure no compiling directly on the system.
But just by try and fail/crash and comparing the results of process and task structure to the output of Scout I got a somehow working version, it’s a very dirty hack, but for now it works, Leu works, FPC works (until collect-aros crashes when try to link, but without linking, everything is fine), FP-IDE is working (with the same problem like FPC of course).
Leu and FP-IDE on Icaros64
There is some more work to really make that structures correct, but for that I will wait until the gcc is working again. The described way to compile stuff for 64bit in C on the icaros webpage using metamake is hilarious if you just want to compile a hello world it’s way overblown. I tried it, but it does not work, also compiling AROS64 from source does not work, I guess you need some pesky parameter when calling configure which, of course, are not described.
