Replacement for VISION's color icon routines

[JeanMars]

Hi all,

I would like to replace existing color icon management routines for vision (in tools/xrsrc.c) because they are very old, very fuzzy and don't work for radeon card in 32 bit modes (Kroll knows that...).
My needs are:
Load icons from interface resource file
Pick best choice for current resolution and prepare the mfdb to display it later on
Setup the drawing routine
This has to work on all ataris not only ones with color icon in aes.
Can someonre point me to any existing free source code for.that?

Thanks, Jean

[ThorstenOtto]

they are very old, very fuzzy

Yes, but they are still the most portable.

and don't work for radeon card in 32 bit modes (Kroll knows that...).

What exactly is going wrong? I think, those (or similar) routines are used in a lot of applications that install their own routines.

Can someonre point me to any existing free source code for.that?

You can try to look at the source of XaAES, but the routines there are not really easier. Also, they are not easily to be used in other applications, since they depend on a lot of other functions. Another option would be the MagiC sourcecode, but that's in assembler.

For loading the files, you can take a look at http://atari-forum.com/viewtopic.php?f= ... te#p315762. Just use the diffferent header format with long offsets, if you need to.

[OL]

Hi all,

I would like to replace existing color icon management routines for vision (in tools/xrsrc.c) because they are very old, very fuzzy and don't work for radeon card in 32 bit modes (Kroll knows that...).
My needs are:
Load icons from interface resource file
Pick best choice for current resolution and prepare the mfdb to display it later on
Setup the drawing routine
This has to work on all ataris not only ones with color icon in aes.
Can someonre point me to any existing free source code for.that?

Thanks, Jean

Hello Jean

why not use AES when feature exist and use your routine if not?
appl_getinfo(2) return in intout[3] bit 1 if color icon supported. and in intout[4] bit 1 if interface format is supported. For more AES supporting your rsc file perhaps you can use Atari format. I suppose most 32 bit system support modern AES and support interface format (I think it the case for XaAES and for sure it is the case for MyAES)

Olivier

[JeanMars]

Hi,

@Kroll; what is the exact machine/TOS you are running?
@OL: this is already done in the current code, xrsrc.c installs its own drawing routine only if Sversion()<0x3000, problem is building the TC32 bitmap from 4bitplanes icon in RSC file
@Thorsten: what is wrong is creation of bitmaps for TC32 resolutions with CTPCI and Radeon video card (all others are OK). I did not get into details because I don't have such a machine (Kroll has) but it for sure Radeon driver is not so clean as VISION cannot detect pixel organization based on pset/vro_cpyfm calls (see FindScreenOrg in rasterop.c).
What xrsrc.c does for similar detection to create icons or TC32 is unclear to me but it seems it is based more or less on similar VDI calls.
However, some other painting tools (ZView, Photoline, Pixart ) are OK do this detection properly,

Today I have fixed the FindScreenOrg detection by falling back to usual 0RGB TC32 format, so images loads OK but I'm relunctant to change code in xrsrc.c ... So icons are displayed wrongly.

Any help appreciated,
Jean

[ThorstenOtto]

[
why not use AES when feature exist and use your routine if not?

If you have your own routine (because you want to also support AES that don't have coloricon support), why bother asking it first?

[ThorstenOtto]

Hi,
xrsrc.c installs its own drawing routine only if Sversion()<0x3000,

Sversion() only returns the GEMDOS version, that does not tell anything about AES features. If you want to go that way, you should really use appl_getinfo() as OL suggested.

[Kroll]

Hi,

@Kroll; what is the exact machine/TOS you are running?
Jean

I tested Vision on Falcon 030/060 under TOS and MiNT. If you want I can test on TT with video card and under Magic too on both machine.

Kroll

[JeanMars]

@kroll i believe radeon card is on tt? Does the issue show on magic and mint? And original tt tos?

[JeanMars]

Hi,

This Sversion call was part of the code I got a very long time ago, it has probably been modified from orginal xrsrc but I never looked deeply into it, just lived with it. Agree this call is not appropriate, however, I don't think icon drawing routine is the issue, whatever it is AES or internal routine displaying it, it should be same result. Here I guess the issue comes from the way the icon is computed in TC32 from 4bitplane icon is RSC file. And this is apparently faling aloso because some pset, or vro_cpyfm routines are not totally handled in this particular resolution in radeon driver.
So yes Krol, if you can test across your machines/AES/OSes that would tell more about root cause.

Thanks,
Jean

[OL]

Hi,

...
@OL: this is already done in the current code, xrsrc.c installs its own drawing routine only if Sversion()<0x3000, problem is building the TC32 bitmap from 4bitplanes icon in RSC file
...

Any help appreciated,
Jean

Look at Sversion is wrong, you have to use appl_getinfo as described before.

I not understand you can have issue transform to TC32 bitmap if you have not issue in 16 bit, only more issue is to detect 32 bit format but if you have an issue to detect it only color should be wrong but not white, only format I have seen is ARGB format, I think if not display as it should you have a problem with VDI to copy bitmap, it is possible I have seen such issue in past. Interface routine are buggy you can look at EG_LIB from Christophe Boyanique I think better : https://github.com/ggnkua/Atari_ST_Sour ... que/EG_LIB

Olivier

[OL]

Hi,

...
@OL: this is already done in the current code, xrsrc.c installs its own drawing routine only if Sversion()<0x3000, problem is building the TC32 bitmap from 4bitplanes icon in RSC file
...

Any help appreciated,
Jean

Look at Sversion is wrong, you have to use appl_getinfo as described before.

I not understand you can have issue transform to TC32 bitmap if you have not issue in 16 bit, only more issue is to detect 32 bit format but if you have an issue to detect it only color should be wrong but not white, only format I have seen is ARGB format, I think if not display as it should you have a problem with VDI to copy bitmap, it is possible I have seen such issue in past. Interface routine are buggy you can look at EG_LIB from Christophe Boyanique I think better : https://github.com/ggnkua/Atari_ST_Sour ... que/EG_LIB

Olivier

There is too ressource load in windom adapted from EG_LIB if I remember

[Kroll]

@kroll i believe radeon card is on tt? Does the issue show on magic and mint? And original tt tos?

Radeon card I have in falcon 060 with CTPCI. On my TT I have ATI MACH64. I will can test on my all machines and systems.
I have just tested and the problem with Falcon with Radeon card only, but what is interesting the display icons is correctly only with MiNT with MyAES. Under other system Magic, TOS, MiNT and Xaaes is bad.

On my TT with ATI Mach 64 under MiNT and TOS with 24 and 32 bitplanes everythink is OK

[JeanMars]

Hi all,

I removed Sversion call so all drawing is performed by xrsrc drawing routine. Results are not better.
Fo some reason, on a Falcon with Radeon card in TC32, it works only under Mint/myAES. I thought it was related to Radeon driver not handling some pset or vro_cpyfm calls but I'm running out of ideas right now

[ThorstenOtto]

What i don't understand: you say, when using the xrsrc routines, it works with MinT/MyAES, but not with Mint/XaAES. But those use only VDI calls, the AES is not involved at all. How do you currently load the resource?

[OL]

What i don't understand: you say, when using the xrsrc routines, it works with MinT/MyAES, but not with Mint/XaAES. But those use only VDI calls, the AES is not involved at all. How do you currently load the resource?

Yes I agree with you, very strange!

It would be nice to see if under XaAES without xrsrc routine if icon display as it should.

I not see the issue is link to screen detection if work under myAES. So we know issue is probably in userdef , as you said this is VDI only,

When I think to userdef I see 2 possible issue :
- AES Stack overflow, which gem library you use? If you use gemlib it is possible, on modern version there is an option to fix this, I can check if need.
- Lost of VDI option workstation, it depend which workstation you use in userdef, if you use default and not your own it possible you lost vswr_mode, under MyAES it is not possible but I think it is the case for other AES.

I don't know if it can help.

Olivier

[JeanMars]

Hi all,

I don't have explanations here, just reporting what Kroll mentions in his tests, agree it does not make sense to work with Mint/MyAES and not others with a Radeon in TC32.
Resource is loaded using Xrsrc_load:
int Xrsrc_load(char *rsc_name)
{
if ( choix_rsrc==-1 )
{
if ( (AESVersion >= 0x0400) || (appl_find("?AGI\0\0\0\0") >= 0) )
{
WORD a1, a2, a3=0, a4=0 ;

appl_getinfo( 2, &a1, &a2, &a3, &a4 ) ;
if ( a3 && a4&2) choix_rsrc = 1 ;
else choix_rsrc = 0 ;
}
else choix_rsrc = 0 ;
}

LoggingDo(LL_INFO, "Xrsrc_load: using %s", choix_rsrc ? "rsrc_load":"xrsrc_load") ;
if ( choix_rsrc == 1 ) return rsrc_load(rsc_name) ;
else return xrsrc_load( rsc_name, bidon_global/*_GemParBlk.global*/ ) ;
}
So basically, if AES supports color icons, it uses AES provided load, else fallback to xrsrc one. Asked Kroll for a test to see which path is taken depending on the OS/AES.
WIll keep you updated.

Thanks,
Jean

[ThorstenOtto]

Don' think that it is related to your problem, but in

Code: Select all

  appl_getinfo( 2, &a1, &a2, &a3, &a4 );

you should also check the return value of appl_getinfo. Depending on the how the binding is implemented, the output variables might not be set at all if the function returns 0.

[JeanMars]

Looks like it may be something like this as it works when choix_rsrc=0 and fails if VISION gives free hands to AES to manage color icons...
More feedback tomorrow

[JeanMars]

Hi,
On Mint, under:
myAES: rsrc_load is called and works fine. xrsrc_load doesn't work.
XaAES: xrsrc_load is called and does not work.

Don't get it, xrsrc_load should work on both unless the way of testing screen to convert icons is wrong because as I suspect, related VDI calls are not properly implemented. I had the same issue on VISION's screen routine to detect TC32 RGB organization based on pset/vro_cpyfm (see FindScreenOrg in gwindows.c) which falled back to default ARGB organization.

[JeanMars]

Hi all,

To start, some info about how VISION deals with resource files:
- If AES reports (Colour icons present) and (New resource file format (AES4) is supported) and (Interface resource file format (RSHDR:rsh_vrsn = 3) is supported) then VISION will call regular rsrc_load else it calls xrsrc_load which has its own support for color icon for all TOSes.
This is now done by the following code (forget about Sversion, no longer used):

Code: Select all

 	if ( (AESVersion >= 0x0400) || (appl_find("?AGI\0\0\0\0") >= 0) )
  	{
      WORD ret, a1, a2, a3=0, a4=0 ;

  		ret = appl_getinfo( 2, &a1, &a2, &a3, &a4 ) ;
      LoggingDo(LL_INFO, "appl_getinfo ret=%d, a3=%d, a4=%d, SVersion:%x", ret, a3, a4, Sversion()) ;
  		if ( ret && a3 && a4&2) choix_rsrc = 1 ;
  		else                    choix_rsrc = 0 ;
  	}
  	else choix_rsrc = 0 ;

and the problem I'm looking into:
- Almost all combinaisons are OK with VISION (machines/clones/VMs/TOS/Magic/AES/resolution)
- 1 case is not working Falcon + Radeon card + True Color 32bit mode

let me share the outcome of all these tests for all configurations:
Configuration Item |Log |Result
myAES |appl_getinfo ret=1, a3=1, a4=3 -->rsrc |OK
XaAES |appl_getinfo ret=1, a3=1, a4=1 -->xrsrc |Wrong display for icons
TOS |appl_getinfo ret=1, a3=0, a4=0 -->xrsrc |Wrong display for icons

So only when AES reports full support, regular rsrc_load is called and it works. As soon as xrsrc_load is used, it fails.
Let me insist on that: only in TC32+Falcon+Radeon card
What is different here is that also the VISION routine to detect screen organization does not work here. It is based on plotting red, green and then blue dots, get value back and deduce screen organization (FindScreenOrg in rasterop.c)
VDI calls: vswr_mode, vsm_type, vsm_color, vsm_height, v_pmarker, vs_color, vro_cpyfm (from screen to memory)
Something similar in done by test_rez in xrsrc.c to convert icons from standard to specific format
VDI calls: vswr_mode, vsl_ends, vsl_type, vsl_width, vs_color, vsl_color, v_pline, vs_color, vsl_color, vro_cpyfm (from screen to memory)

And both are failing there; so there should be some VDI call that is not acting as it does in other resolutions; possibly vro_cpyfm (from screen to memory) is not working (already saw that with FVDI on Aranym in 256color modes).

I found a workaround for VISION's screen organization detection (fallback to ARGB which is Radeon format) but no idea for xrsrc. Also wondering whow myAES rsrc_load is solving this.

Any ideas? I'm about to give up on this.
Thanks,
Jean

[OL]

Hello Jean,

MyAES do it's own detection and if I add it in kernel it's only to reduce size before it used screen.ldg.

Detection is based as you on write line of different color, hope you not look directly in memory but copy from screen to offscreen buffer you control?

This way is a bit old style it work on all system I know, now most software look at Eddi cookie, I think you should look at it, if not exist use your detection format. I not do anything special for Radeon card

Olivier

Hi all,

To start, some info about how VISION deals with resource files:
- If AES reports (Colour icons present) and (New resource file format (AES4) is supported) and (Interface resource file format (RSHDR:rsh_vrsn = 3) is supported) then VISION will call regular rsrc_load else it calls xrsrc_load which has its own support for color icon for all TOSes.
This is now done by the following code (forget about Sversion, no longer used):

Code: Select all

 	if ( (AESVersion >= 0x0400) || (appl_find("?AGI\0\0\0\0") >= 0) )
  	{
      WORD ret, a1, a2, a3=0, a4=0 ;

  		ret = appl_getinfo( 2, &a1, &a2, &a3, &a4 ) ;
      LoggingDo(LL_INFO, "appl_getinfo ret=%d, a3=%d, a4=%d, SVersion:%x", ret, a3, a4, Sversion()) ;
  		if ( ret && a3 && a4&2) choix_rsrc = 1 ;
  		else                    choix_rsrc = 0 ;
  	}
  	else choix_rsrc = 0 ;

and the problem I'm looking into:
- Almost all combinaisons are OK with VISION (machines/clones/VMs/TOS/Magic/AES/resolution)
- 1 case is not working Falcon + Radeon card + True Color 32bit mode

let me share the outcome of all these tests for all configurations:
Configuration Item |Log |Result
myAES |appl_getinfo ret=1, a3=1, a4=3 -->rsrc |OK
XaAES |appl_getinfo ret=1, a3=1, a4=1 -->xrsrc |Wrong display for icons
TOS |appl_getinfo ret=1, a3=0, a4=0 -->xrsrc |Wrong display for icons

So only when AES reports full support, regular rsrc_load is called and it works. As soon as xrsrc_load is used, it fails.
Let me insist on that: only in TC32+Falcon+Radeon card
What is different here is that also the VISION routine to detect screen organization does not work here. It is based on plotting red, green and then blue dots, get value back and deduce screen organization (FindScreenOrg in rasterop.c)
VDI calls: vswr_mode, vsm_type, vsm_color, vsm_height, v_pmarker, vs_color, vro_cpyfm (from screen to memory)
Something similar in done by test_rez in xrsrc.c to convert icons from standard to specific format
VDI calls: vswr_mode, vsl_ends, vsl_type, vsl_width, vs_color, vsl_color, v_pline, vs_color, vsl_color, vro_cpyfm (from screen to memory)

And both are failing there; so there should be some VDI call that is not acting as it does in other resolutions; possibly vro_cpyfm (from screen to memory) is not working (already saw that with FVDI on Aranym in 256color modes).

I found a workaround for VISION's screen organization detection (fallback to ARGB which is Radeon format) but no idea for xrsrc. Also wondering whow myAES rsrc_load is solving this.

Any ideas? I'm about to give up on this.
Thanks,
Jean

[JeanMars]

Hi Olivier,

Detection is based as you on write line of different color, hope you not look directly in memory but copy from screen to offscreen buffer you control?

Correct, I'm using vro_cpyfm to copy from screen to memory.

Any doc for this Eddi cookie?

Thanks,
Jean

[ThorstenOtto]

https://freemint.github.io/tos.hyp/en/b ... _2C_20EdDI but you basically only have to check its presence so you know that you can call vq_scrninfo(). All information is then returned by that call.

[JeanMars]

HI,

nice to see. However I have a workaround for screen organization (probably not perfect but viable) but I have nothing for color icon in Falcon+Radeon+TC32+(not myAES).

Kroll, I'm sorry but I have to give up on this; simply to much work and investigations to support a single configuration. To me it's probably something not supported by Radeon VDI driver in TC32 which breaks color icon adaptation to current resolution.

Cheers,
Jean

[Kroll]

@JeanMars, OK, understand you and sorry for trouble.