I did a 2.4.0 beta1 last year, but this preparation was to no avail because there was some problem with the actual 2.4.0. Because cross compilers have always (or v. near) been useless to me, I intend to try that with an updated native gcc.
Since I got the SDK working, here's my rather small roadmap: RTTR, Transmission Qt, TORCS, Speed Dreams. After that I'll go on, and try to port every non-FPS game from the list in my first post (sorry FPS fans... including me ).
This is just like television, only you can see much further.
@tlosm It's hard to tell after a few days, but from the users standpoint Worbench didn't change much since the 3.x days. This can be a good or a bad thing depending on what are you looking for. As a developer I really, really like the Grim Reaper and the native GDB port. It makes debugging much less of a pain. While the cold reboot is definitely slower than MOS, OS4 has warm reboot, which is fast and does the job in most cases. Shared object (or rather dynamic linking) support is a blessing and a curse at the same time. Right now it's giving me some problems with RTTR...
This is just like television, only you can see much further.
yes mos i can confirm is most faster in booting and i can confirm Os4 is more similar to classic workbench , but for my personal taste i love it because of this, mos is more near to MacOsX in some way, Os4 is more classic Workbench enancement in the right measure from 3.9 to 4.1 there are only 2 revision ;)
Time by time you will become a great geek on os4 too, for sure right now you are a super geek compared with a lamer like i am ;)
but from the users standpoint Worbench didn't change much since the 3.x days.
Filer and dopus5 fill the gaps more or less, but yep, wb still the same old wb, just with some fancy bits there and there.
Quote:
and the native GDB port
GDB in current state works, but once you will dig in deep into, you will have problems (crashes, freezes and all kind of bugs). Better use db101
Btw, you also need to instal KingCon, as public default shell is pretty primitive and limited.
Btw2, and dont forget to insert in all code stack cookies, so users will have no needs to set stack manually or in icons, usually i do it like (btw, that built-in stack cookie won't override your stack setting if yours is higher):
That usually enough for any modern port to cover stack size problems, so users will have no worry about. Usually i just put that line somewhere at top of main.c or kind.
It's rather a while since I used KCon: (being an amigaos4 beta tester) but you can either make a modified Shell iocn on system that uses KCON: or the more extreme is to unmount CON: and RAW: and make mountfiles to mount KCON: and KRAW: but named as CON: and RAW:, there may be examples in the KCon archive, I'm not sure.
Btw, you may need to install also pngicon.module (so not only native os4 icons will works, but png ones as well). Usually newcomers have some problems with it like "why half of icons didn't showups" (because some of them just pure png ones).
I have stopped using pngicon.module, it seems its turn all my AmigaOS4 icons into PNG icons over time, I guess snapshotting icons saves the icons as PNG
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.