AmigaOS 3.2 and beyond

[wiser3]

@ OS 3.2 devs and team members
Thank You, Thank You, Thank You !!!

[bubbob42]

Originally Posted by Daedalus

Any chance this behaviour can be changed?

Yes, and not only because it annoys me, too.

[Daedalus]

Originally Posted by bubbob42

Yes, and not only because it annoys me, too.

Sweet, thanks

[Olaf Barthel]

Originally Posted by Daedalus

Regarding OS4, there's still a small amount of development going on, with the most recent update being released just before Christmas. It's currently using V54.x components.

I happen to use 68k software that's OS4-aware, so there's definitely software that could fall foul of such a versioning conflict unless it's somehow worked around.

It's not ideal, but OS4 has a concept of API versions, which means a single library can have multiple different interfaces, which allows overlapping and potentially incompatible functions to be segregated. If no specific interface version is requested, you get the old 3.1-style interface for compatibility with older software, and to use newer versions of the functions, you need to request an appropriate API version. Perhaps a similar scheme could be adopted, or even the same scheme, with the 68k exec defaulting to requesting a specific 68k interface version?

Nothing has been decided yet. It's still a long-ish way off before a solution has to be in place and, if they let us, we would try to have one before there's really no more runway left

Personally, I would like to keep the existing APIs in play as they are. The exec.library architecture and its APIs are powerful and restrained, for lack of a better word.

AmigaOS4 needed to extend them, with the library function call mechanism being the interfaces. They are more than a collection of function pointers because calling the functions implicitly passes the interface address itself to the respective function. This reproduces how the Amiga 68k ABI works with its register sets and the role of register A6, only using 'C' syntax.

If I remember correctly, the interface approach reuses functionality which already exists in the GNU 'C' compiler. While this could work for the 68k platform, too, there's the problem that the code which GCC generates is not as well-integrated and suited for system programming as the code produced by SAS/C out of the box. This could be changed, but who knows in which time frame. Would be supremely cool if it were possible!

There's also the question of how to provide interfaces for 68k assembly language use (could look different, might require macros), and whether or not the interface functions would support parameters in registers. My guess is that all parameters would be passed on the stack. Which has its drawbacks Just look at intuition.library before V45. The Green Hills 'C' compiler producing great, optimized code could not compensate for the multitude of "let's push those registers on the stack... call the function... that function pulls them off the stack and puts them back in the the same registers" dance steps. When we rebuilt intuition.library with SAS/C and registerized parameters enabled in the code generation option intuition.library became much, much shorter, and not just through function inlining.

As I mentioned, there is still time to discuss alternative approaches until we settle on one. It might be good if only a small change would be required and the architecture and design of the exec.library API could be preserved. It's so neat

[kamelito]

@Olsen
See how fast games made by Abyss are using GCC I’d say it’s good enough maybe better than SAS/C for code optimization. That said it brings other problem’s like regression testing effort.

[Ulysses13]

I'm loving 3.2, so thanks guys. Also enjoying following the weekly streams which shows how much work and love has gone into the new OS.

I'm not a hardcore developer deep in the technical weeds, but I do enjoy tinkering, and I'm a graphic designer by trade, so like a nice looking Workbench.

My main request for AmigaOS would be updates to IconEdit and Palette Prefs.

The current IconEdit only understands legacy icons and 4 colours. It would be great to have it updated to support editing the various kinds of icons that can now be found on a typical system, as well as acknowledging larger colour palettes. Basically do for IconEdit what you did for TextEdit.

I'd also love an update to the Palette Preference app. So it can show more than only 8 colours, and has built-in FullPalette-type palette locking. I use FullPalette as I have a nice 16 colour scheme I have developed and it lets me design my wb as I like. It mostly works, but not always. It would be great if AmigaOS would let users define a larger palette and solidly lock the Workbench colours if they want to.

[boemann]

Originally Posted by Ulysses13

My main request for AmigaOS would be updates to IconEdit and Palette Prefs.

The current IconEdit only understands legacy icons and 4 colours. It would be great to have it updated to support editing the various kinds of icons that can now be found on a typical system, as well as acknowledging larger colour palettes. Basically do for IconEdit what you did for TextEdit.

You mean something like this that I'm playing around with

Mind you it is still early days

[Ulysses13]

OMG yes. I love you.

Looking forward to that.

[Daedalus]

Originally Posted by boemann

You mean something like this that I'm playing around with

Oh yes

[boemann]

Originally Posted by Ulysses13

OMG yes. I love you.

Looking forward to that.

My current projects are:

• IconEdit
• Scrollback in Console
• TextEdit ARexx

I need to spend considerable time on all of them, so don't be disappointed if it takes a long time before you see anything

[Ulysses13]

No problem, we're good at waiting for stuff round here!

[Tigerskunk]

Originally Posted by boemann

You mean something like this that I'm playing around with

Mind you it is still early days

nice *slow clap*

[hUMUNGUs]

Originally Posted by boemann

My current projects are:

• IconEdit
• Scrollback in Console
• TextEdit ARexx port

I need to spend considerable time on all of them, so don't be disappointed if it takes a long time before you see anything

24 bit iconeditor ?

[PeterK]

Originally Posted by hUMUNGUs

24 bit iconeditor ?

Oh no !! Not a 24 bit icon editor, please !

If we could wish something without any chance to ever get it then we would need a 32 bit icon editor with alpha channel support.

[hUMUNGUs]

Originally Posted by PeterK

Oh no !! Not a 24 bit icon editor, please !

If we could wish something without any chance to ever get it then we would need a 32 bit icon editor with alpha channel support.

even better :-)

[Ulysses13]

@boemann How have your team made the current GlowIcons? Do you use an Amiga application or do you make them on the PC/Mac?

If PC/Mac, what's the process of getting them from Photoshop/etc to an Amiga icon?

If you make them on the Amiga, what tools do you use?

[boemann]

Originally Posted by hUMUNGUs

24 bit iconeditor ?

Not going to happen - too much work, not even sure this stuff will happen even in a basic way. it is just what i'd like to work on.

[boemann]

Originally Posted by Ulysses13

@boemann How have your team made the current GlowIcons? Do you use an Amiga application or do you make them on the PC/Mac?

If PC/Mac, what's the process of getting them from Photoshop/etc to an Amiga icon?

If you make them on the Amiga, what tools do you use?

No idea, i'm not involved in glowicons. I personally use the classic icons

[Ulysses13]

I prefer the classic ones too, I like the restriction of the limited colours in the design. My ideal would be a locked 16 colour WB palette.

To be honest, I feel like all the other formats that have followed are just like any other colour icons on Windows95/MacOS9 etc. The classic ones have a unique 'Amiganess' to them. I think the limitation is part of that.

I'm just curious about it, as clearly a lot of work has gone into them, and also it feels like now they're such a central part of the OS install, that they're the new standard.

[boemann]

I wouldn't call them the new standard. Classic or glowicons live side by side. I've contributed a lot of the new classic icons that are included in 3.2, and they are all drawn in the 3.2 IconEdit.