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 😉
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).
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.
Just playing around a bit, with color and sound. RGB fits onto the keyboard inside the case without any change to the original stuff. React to the sound and with a little GUI to change the config, of course in FreePascal.
Next thing about Leu was the clipboard, originally I only planed to make a simple solution, where only the texts get copied. But when I thought about, the Amiga clipboard is perfect to use as multiformat clipboard, as windows has. The clipboard on Amiga systems is in principle just a IFF file and there you can put in everything you want. You can put in a Text (e.g. IFF-FTXT) or an Image (e.g. IFF-IILBM) or a sound (e.g. IFF_8SVX). And because IFF is tag based its also possible to put more then one format at the time into.
So I started to write a own clipboard routine for Leu, which takes the selected cells and put them to Clipboard as OpenOffice XML (like the ods file) and as standard text as tab separated list.
And this works rather nicely as you can see:
I also added a little requester to set the number of Cols and Rows
If you want to download the latest version go to the Leu Page
I tried Leu on a real A1200 with 68030/50 Mhz and a 32 color AGA screen. It worked but the idea to redraw everything if you type something in, was not very smart. (To show the changed calculation results)
I changed that to a function which checks which cells are changing because of this cell enter, in principle which formula depend on this cell. And it’s working quiet well. Time for a little video
I noticed the colors are still very buggy on big endian systems, I have to care about that again later, in the saved file the colors are swaped, I must debug that. Should be not too hard, I fixed that already once at the loading of files.
As it was the case with borders, I took the LibreOffice color requester as GUI blueprint for my Leu color chooser, Basically it’s the same as for the borders. The only difference, you need two of them, one for background one for text (in principle a one more for border color, but I left that out for now.)
Leu also got a own Page now where always the newest version can be found and some central information about it. For now I will not keep a history for it, because still changing too much things.
To get a little bit away from the converting business, which is a bit boring to be honest, I started with some basic formatting options in the GUI. Font and alignment are rather easy, just some buttons which set the property of the all selected cells. A little bit more complicated are the border settings, especially because there you need a special input element.
I tried with buttons but it took very much space and the names on them are not really useful. Like in usual spreadsheet applications it is better to just show the result with a little graphic. It’s the first time I used the TMUIBitmap object, very handy and easy to use.
Besides that I created a combobox like element, when you click onto the button a new borderless window open with the different border buttons inside and if you select one, or click somewhere else the window automatically close again. Not very difficult with the MUIClass-system.
First, I want say thanks to all people send me texts or code snippets how to read TurboCalc TCD files some where very helpful. Sadly in none of them the functions are nicely explained so in the end it came to just straight forward try out with the Manual and write for every function a line in the file to check the result in Leu. But finally the most functions which are available in Leu can be converted from TurboCalc. I’m not sure if it makes sense to make a TurboCalc writer, because it’s a dead program, nice but dead. Writing is hard because you need to know everything about the file, and some of the comments in the text files suggest that TurboCalc is very picky when the tags are not in the correct order or somehow divert from the ideal format.
On a special wish I also implemented a possibility to inline edit the cells, without changing to the edit box. Until now you can only insert a new contents, and not use the mouse to set the cursor. When you can grab the mouse you can also set the cursor in the edit field.
What I’m not really getting, is why the people are excited about that program, it’s not like there is no spreadsheet program, there is TurboCalc, ok it’s old but fairly nice working and there is Ignition, I never used that but from screen shots it looks rather decent. At least much more advanced than this piece of crap 😛
Maybe the people are just happy, that someone codes something. Speaking of which here is the latest Version: 0.05 with edit feature, finally an Icon and TCD function loading.
Notice it can also export the table as HTML or as Wikitable. (just use the endings “.html” or “.wikitable_pipes” .wikitable_wikimedia”). Ok that will be more useful, when I introduced stuff to change colors, borders and fonts.
I played a lot with TurboCalc and it’s files, and checked the fileformat. I still have some very old files from around 1995-1997. An finally a little bit stuff is working.
The second file is my timetable of 2nd semester in university, I printed it out to hang at the door. (yeah, I had color printer back in the days, a termo-transfer printer) As you can see the properties and colors comes nicely to Leu even the Formula, I need to try more functions to see how to convert them to the Leu functions. Of course it’s also possible to save that file again as Libre Office file and load it there. That’s how it looks like in LibreOffice
The Leu application had a big bug under MorphOS, it was impossible to use the scrollbars as long there was part of the grid underneath. The click always went directly to the grid, so the scrollbar never got it. This did not happen under AROS Zune or Amiga MUI 3.8, so it must be something special of the MorphOS MUI implementation.
After a pointer of jacadcaps at morph.zone the solution was rather easy. When you register in MUIM_Setup which events you want to be notified of there is a new flag MUI_EHF_GUIMODE for TMUI_EventHandlerNode.ehn_flags, introduced in MUI 4 which tells MUI to NOT notifiy you about events happen in a part of your element which is hidden. For example if your element is on a Tab control but your page is not visible at the moment, or like in our case, the element is partly hidden by the scrollbox. This behavior was the default behavior for old MUI 3.x on Amiga as far I can see. Beside, I see uses for such feature, it should be extremely seldom, that you want to be notified about clicks on your non visible part. For me it is very odd to make this seldom needed to old versions incompatible behavior as the new default, and not, as I would suggest create a Flag which turns on the new way for event handling. Btw. even in this case I would expect some kind of marker in the event that this was triggered on a hidden part. You have nearly no way to know that somewhere in the tree above you some element could cause that.
But in the end, the most important part is I know it now and it also explains some strange behavior I had in the LCL (clicks on sleeping windows, clicks on not visible tabs) which should all be fixed by that.
I also did a new compilation of Leu, this version now already has a open and save requester, it should be able to open xls, xlsx, ods and maybe csv files (if you change the pattern I preconfigured). The output format you define by the extension, I tried xls, xlsx, ods, csv and html and all seems to work as expected.