icon.library 46.4 test versions

[PeterK]

Ok thanks Foul.

Just curious, is there any speed gain noticeable on your system?

This def_icon bug should be fixed in 46.4.245 now.

[Foul]

Without blitzkick and custom graphics.library, my system is much slower.
I dont need any bench to show that, my eyes are enough.

Just opening big games drawer could be twice speed :-)

edit : 46.4.245 seems ok...

[PeterK]

Updated to icon.library 46.4.246

Fixed a small bug concerning app-icons.

[Bamiga2002]

46.4.246 runnin' good. What I marked was that icons seem to display a tad faster when disabling PowerIcons-patch.

[PeterK]

icons seem to display a tad faster when disabling PowerIcons-patch

Yes correct. There are no effects, no speed increase, when the PowerIcons patch is running, because PowerIcons needs the colormapping of the selected image for the icon dragging and that was already reduced to a limit of only 40 colors since the old days of IconBeFast. But without PowerIcons there is just one image now which has to be mapped to the screens colors instead of two.

[Foul]

i'm learning asm and when i'm trying to assemble sources, i got this error with Asmpro 1.18 :



it seems to refer to "Icona_Dummy", but nothing found... is it normal ?

[PeterK]

Hi Foul,
these declarations can be found in the Commodore includes, in icon.i for this case.
You have to tell your assembler which files you want to include for the compilation and where your INCLUDE: directory can be found. All the included files that I used are listed at the top of my source code. I'm using PhxAss as assembler with 68020 support enabled and all symbols are case sensitive. You may not find some of the LVOs, because I made my on file for these symbols.

Do you have the NDK already? http://os.amigaworld.de/index.php?lang=en&page=12

[Foul]

all includes installed and found during compilation...

will check NDK and icon.i,

thx

edit: my icon.i and lvos.i are different .. maybe because i'm using 3.1 ones...

[Foul]

again sorry :



After that, i stop annoying you with asm things

[DrCinicus]

Use move.l instead of mevea.l

Bye
Fabio

[PeterK]

@Foul & DrCinicus
Thanks for reporting and correcting this wrong instruction, but PhxAss ignores and corrects that typo anyway.

Updated to icon.library 46.4.247

Fixed two small bugs and a big one which is called blindness

[PeterK]

Updated to icon.library 46.4.248

Just another small fix for a bug introduced in 236.

[altcomputing]

Hmm, I found that when I degrade my AfAOS+PNG Icons system to boot to PAL, icons that will otherwise revert to default images, display trashed (with or without AfAOS running). But If Picasso96 is initialized (but not used to display icons) they are OK in PAL modes.

[PeterK]

Hello altcomputing,

I guess, that happens because IPrefs sets the default icon memory to FastMem on your system, which works correctly with the Picasso drivers, but not with a standard PAL configuration. If you want to use a pure PAL configuration then you should either install FBlit on your system in order to use FastMem for icons or you have to open the Workbench preferences and set the icon memory type back to ChipMem.

[altcomputing]

Originally Posted by PeterK

Hello altcomputing,

I guess, that happens because IPrefs sets the default icon memory to FastMem on your system, which works correctly with the Picasso drivers, but not with a standard PAL configuration. If you want to use a pure PAL configuration then you should either install FBlit on your system in order to use FastMem for icons or you have to open the Workbench preferences and set the icon memory type back to ChipMem.

Tried that... no success.

The thing is that when WB is on a PAL screen, but Voodoo driver is present in DEVS:Monitors, and has therefore been initialized, icons are OK on a PAL screen. But If i just remove Voodoo driver and reboot there's a mess on the screen. So it seems to have something in common with Picasso96.

I think that icon.library guesses from the fact that the RTG is running to move icon data to Fast, regardless of what is actually being used to display WB screen... But I'm a no programmer, just my guess.

I will try to focus on it and give more details.

[PeterK]

I think that icon.library guesses from the fact that the RTG is running to move icon data to Fast...

No, it's IPrefs v44+, that is reading ENV:sys/Workbench.prefs to decide if you want FastMem or ChipMem for your icons.

My icon.library (the most recent versions) just checks if FBlit is running. And if so, then the icons will get FastMem too.

[altcomputing]

Hmm... I'll have a closer look at it then. Maybe Workbench Prefs Editor is fooling IPrefs... Will try to delete prefs and give it a try. But anyway, why does it work when I remove RTG driver?

[PeterK]

I've just tried out a pure PAL system without P96 monitor drivers installed and it works here, no matter if I use FastMem or ChipMem or if FBlit is installed or not.

Please, send a screenshot and some more details about installed libraries.

[altcomputing]

Grab1.png is the issue - There's a regular OS3.9 BB2 + some updated libs, LoadMonDrvs was not run in startup-sequence, therefore it defaults to PAL:HiRes.

Grab2.png is exactly the same, but with LoadMonDrvs ran at startup. The Voodoo driver has been initialized, but not in use - still a PAL screen.

I also tried leaving out the Voodoo driver from DEVS:Monitors and trying that way with LoadMonDrvs so it only loaded standard monitor drivers - result is exact to Grab1.png.

Forgot to mention, those messed up icons are PNG ones!

[PeterK]

Which version of the graphics.library is installed and are there any patches?