32bit TOS icons?

[leech]

Hey everyone, I've tried setting my desktop to 32bit colour and the icons turn into white boxes, these seem to work fine in every other bit depth I've tried.

I am trying to think if this also happened with TeraDesk/MiNT as well, but I think it was fine. Does TOS4.04 (or the 1.03c that the CT60e uses) support 32bit Icons?

[shoggoth]

Hey everyone, I've tried setting my desktop to 32bit colour and the icons turn into white boxes, these seem to work fine in every other bit depth I've tried.

I am trying to think if this also happened with TeraDesk/MiNT as well, but I think it was fine. Does TOS4.04 (or the 1.03c that the CT60e uses) support 32bit Icons?

Use NVDI for that.

[OL]

Hey everyone, I've tried setting my desktop to 32bit colour and the icons turn into white boxes, these seem to work fine in every other bit depth I've tried.

I am trying to think if this also happened with TeraDesk/MiNT as well, but I think it was fine. Does TOS4.04 (or the 1.03c that the CT60e uses) support 32bit Icons?

Really possible? How do you make RSC file with 32bits or 16 bits color depth?

If you have RSC file with 16 bits or 32 bits could you send me the file, I never seen such case?

[ThorstenOtto]

There is no such thing as icons with 32 bit depth. What you maybe mean is displaying icons of 16 or 256 colors on a truecolor display. Theoretically, TOS 4.04 should be able to do that, and teradesk will use that functionality. For what i can tell, it does not have fallback routines if the AES does not support coloricons, and will use the monochrome version instead. If that does not work for you, then either something seems is wrong with the VDI you are using, or the cicons.rsc file is broken. At least it works using XaAES here.

[shoggoth]

What you maybe mean is displaying icons of 16 or 256 colors on a truecolor display. Theoretically, TOS 4.04 should be able to do that, and teradesk will use that functionality. For what i can tell, it does not have fallback routines if the AES does not support coloricons, and will use the monochrome version instead. If that does not work for you, then either something seems is wrong with the VDI you are using, or the cicons.rsc file is broken. At least it works using XaAES here.

TOS4 does it, if you use NVDI.

There is a catch 22 in TOS/AES; the AES is responsible for the conversion of icon data to the native screen format - which is a bit weird, since this should really be carried out by the VDI. While the TOS4 VDI does, with a bit of back scratching and fondling, support 32-bit color, the AES doesn't. NVDI patches this somehow, but I didn't do that in SV_XBIOS.PRG.

[leech]

So I do have NVDI loading. First screenshot is 1920x1080@16bit

AtariTOS-16bit.jpg

1920x1080@32bit

AtariTOS-32bit.jpg

1920x1080@32bit MiNT/TeraDesk

AtariTeraDesk-32bit.jpg

Just wondering why the second one the icons disappeared on me. Also attached the DESKICON.RSC that I'm using. Can't recall exactly where I got that from though. Kind of seems to me it's the official one?

[shoggoth]

Ah, funny. I don't remember the details, but I expected it to work on NVDI. Will have to look into it one day, but it's not a priority at the moment.

It works on Teradesk because it uses the VDI to do the conversion from consecutive planes -> native graphics. The built-in desktop doesn't.

[leech]

Yeah, weird, eh? I did test some black and white icons I had laying around in some zip file and they seem to work fine in 32bit colour, so it's not like it just wipes out any icon.

My current task is to get the MS core fonts (like Arial) to work with NVDI, though I'll probably open another thread once I've thoroughly scoured the Internet. NVDI 5's manual doesn't mention much... that's totally off topic though.

The other thing is figuring out how to 'hide' SV_XBIOS.prg from xboot or similar programs so that it loads up before, but if I don't disable it in xboot, then it causes an exception (which of course is expected), but of course if I disable it in xboot, it renames it for the next time I boot up, unless I want to rename it every time...

Getting to the point though that my desktop is very awesome and usable!

[ThorstenOtto]

the AES is responsible for the conversion of icon data to the native screen format - which is a bit weird, since this should really be carried out by the VDI.

That's only partly true. AES is responsible for loading the resource file (which is different when coloricons are present), detecting the coloricons, choosing which one to display for the current resolution, and then adjusting the format. The actual conversion is usually done by using VDI functions.

[ThorstenOtto]

Also attached the DESKICON.RSC that I'm using. Can't recall exactly where I got that from though. Kind of seems to me it's the official one?

I i understand it right, the 2nd screenshot is from the internal desktop? Maybe its just the desktop that has problems.

[ThorstenOtto]

It works on Teradesk because it uses the VDI to do the conversion from consecutive planes -> native graphics. The built-in desktop doesn't.

Teradesk doesn't do any conversion. It just uses rsrc_load() & objc_draw() if it thinks that the AES supports color icons.

[shoggoth]

I wouldn't be mega-surprised if the TOS4 desktop does something funny. It's not a show-stopper, but I really expected it to work on NVDI.

[leech]

Also attached the DESKICON.RSC that I'm using. Can't recall exactly where I got that from though. Kind of seems to me it's the official one?

I i understand it right, the 2nd screenshot is from the internal desktop? Maybe its just the desktop that has problems.

Correct, it's with SV_XBIOS.PRG, NVDI 5, and a couple other things. But it's in 1920x1080@32. First one is the same but at 16bit.

[leech]

I wouldn't be mega-surprised if the TOS4 desktop does something funny. It's not a show-stopper, but I really expected it to work on NVDI.

Yeah, it's kind of weird. With Black and White icons they appear fine, that's why I figured it was something to do with interpreting the icons at a lower bit depth and so just showed them as white. It's a little worse once you open a drive, because then all you see are the names, since the icons are solid white on a white background.

[Rustynutt]

Not to be too un-technical, did you try deleting newdesk.inf ?

[leech]

Not to be too un-technical, did you try deleting newdesk.inf ?

Just tried that (well renamed it newdesk.inz). Same thing, white icons. It does kind of sound like it's the AES that handles this vs the VDI?

[mikro]

Yeah, this is known issue. Had a chat about it with Beetle a while ago, he also confirms this bug. As PeP says, not a showstopper but would be nice to have it working. :-)

[leech]

Well, I would rather this be a case of it being broken for everyone vs me being a special snowflake or 'you're doing it wrong...' agreed that it isn't a show stopper. Though I mostly wanted to try it due to Calamus 2015 LE requirements. It has to be in either 256 or True color to work. And it seems to crash for me under MiNT/XaAES. I need to update that sometime soon anyhow, since it seems there have been some bug fixes sonce the build I am using.

[OL]

Well, I would rather this be a case of it being broken for everyone vs me being a special snowflake or 'you're doing it wrong...' agreed that it isn't a show stopper. Though I mostly wanted to try it due to Calamus 2015 LE requirements. It has to be in either 256 or True color to work. And it seems to crash for me under MiNT/XaAES. I need to update that sometime soon anyhow, since it seems there have been some bug fixes sonce the build I am using.

I'm able to run it in black and white, you should perhaps try. So this software not work only under MyAES! I was thinking it was link to MyAES!

[leech]

Interesting. So for my testing, I currently don't have the registered version (apparently it can take 48 hours to get the registration code, and I did it about 20 hours ago). But the reason why I say it crashes in XaAES is that when you hit register, then hit cancel it says "Please wait..." and has a 'Break: Control + Shift + Alternate" If I do that in TOS it cuts out to the UI, under MiNT XaAES it gives me this;

Code: Select all

pid 11 CALAMUS):  XaAES:
Non-AES process issued AES
system call 104, killing it!

[leech]

Well, I would rather this be a case of it being broken for everyone vs me being a special snowflake or 'you're doing it wrong...' agreed that it isn't a show stopper. Though I mostly wanted to try it due to Calamus 2015 LE requirements. It has to be in either 256 or True color to work. And it seems to crash for me under MiNT/XaAES. I need to update that sometime soon anyhow, since it seems there have been some bug fixes sonce the build I am using.

I'm able to run it in black and white, you should perhaps try. So this software not work only under MyAES! I was thinking it was link to MyAES!

I lied! It does work under MiNT/XaAES. I'll probably open another thread to see if I can get help to figure out why, no matter what I put in MINT.CNF, I still end up with xaaes loading. Tried to try MyAES... but no such luck.

[shoggoth]

Please move this discussion to a new thread with a suitable topic.

Cheers

[leech]

Apologies.

Back on topic. I did test out Calamus in 32bit colour TOS with the white icons, and it seems to work fine since it's icons are black and white anyhow. So yeah, not a show stopper if it isn't interfering with any actual desktop use.