Updated Online Amiga FPC Compiler again with the latest CRT unit and also tried a bunch of console based games using CRT units, all work more or less (some need some adjustments in the code) some of them are even single file pascal source files, so can be used in the online compiler.
Fixed some little problems on MorphOS and also some little problems inside the DeadCold code (missing error checking) and for that I forked the original repository to my github.
Tried DeadCold on my Draco (in principle 68060 Amiga with RTG Card) and it works rather ok, certainly playable. With some little errors of course, but a nice showcase that it can work.
On my Amiga 1200 (030/AGA) it also work but the colors are not there, needs some debugging.
On AROS the rouge-like Game DeadCold works already rather nicely so I decided to make a little release, maybe someone want to try and see if it also work on other AROS installations.
Someone might ask how the crt is going, and how useful this is already. I want to answer it with a little screenshot:
DeadCold on AROS
That is a nice little rouge-like game called DeadCold, written in FreePascal for the console. As you can see it runs and the picture looks right. (it’s not perfectly right, but somehow usable). And because a little video tells much more about how this game runs here is also a little video about it:
There are some drawing problems, especially on the messages and sometimes some of the map disappear but not bad I would say. There are also some messages about removing critter failed… but that seems some error in the game code.
The colors is badly hacked for now, and only works for AROS, I’m not sure if I can upload that this status to the official repository, I will work on it a bit more.
Most Tutorials about Pascal use the CRT unit in a very early Lesson. They use it only for ReadKey() to wait for a key at end of Program. It would be of course the same to just use a ReadLn and wait for an Enter.
I tried already to implement CRT before using an old implementation, but exactly this ReadKey implementation does not work at all when KingCON or other console replacements is used.
Now I got a hint in MorphOS Forum (always a very good Source for Implementation hints) to set the console in RAW: mode (using SetMode()) and then just read from the console the pressed keys. If console in raw mode, one can read cursor keys and F keys from the console.
I tried that and on MorphOS and AmigaOS3 it works well, Read blocks until a Button is pressed. But AROS of course is different again 😉 it always returns a Value sometimes 185, sometimes 184, not really know what that means. I thought about some kind of timer event but this should look different.
But finally it works, mapped some keys like F-keys and cursor. Also worked on the output gotoxy and colors, the colors are a little bit tricky, because the Amiga console only supports the first 8 pens (as far as I see it) so I cannot just ObtainBestPen, and the first 8 Pens are usually fixed and not the colors I need. I try to change them with ObtainPen but when they are already taken I just try to find one which has a close color, which does not work very well. Solution unknown.
I compile the example of ReadKey as example3.pas and compiled a little RPG-Game I found which is console based, which is a good testcase for colors and GotoXY. Of course looks not the same as in the DOS console but it is usable.
One disadvantage of writing a program relying on web resources is, that you have to update that program everytime the webresource is changed/updated. In the next days the search for MUIMapparium will break again, and the Find by IP/ Find me is broken a while before already.
So I updated MUIMapparium to Version 0.8 I also added some small new features, like some more shortcuts and also by popular demand to jump automatically to the first search result. Best update soon before the search function does not work anymore.
Also the 68k freepascal compiler got some updates which hopefully improve the stability and speed of the m68k-amiga Version.
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 😉
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.
