VISION 4.1a is out!

[JeanMars]

Hi vido,

yes but that would require:
- Compile VISION for ColdFire (move to AHCC, might not be easy)
- Add LDG feature to VISION for laoding/saving images (did not look but might be not straight forward)

I don't know how many ColdFire are on the field but compared to Aranym/Magic on PC, I would bet ColdFire does not win

[vido]

yes but that would require:
- Compile VISION for ColdFire (move to AHCC, might not be easy)
- Add LDG feature to VISION for laoding/saving images (did not look but might be not straight forward)

I don't know how many ColdFire are on the field but compared to Aranym/Magic on PC, I would bet ColdFire does not win

Hi Jean,

As VISION works on the FireBee just adding LDG feature to VISION would help a lot as LDG modules would run natively and VISION would get all images format import supported by LDG modules.

There is more FireBees out there. I dont know exact number, but its greater than that
And it still can be produced by anyone

Vido

[lp]

I maked some zView load modules. Complete list here: http://atari.gfabasic.net/stg/zcodecs.htm I ended up writing these for zView because I found GemView scheme harder to implement and all the docs are German.

However, the scheme isn't perfect. The load modules can't report back what went wrong (like a read error) or why a file was rejected (like an invalid header). If two different formats use the same file extension zView sends it to the first module that supports that file extension. I don't think zorro put enough thought into it. It is what it is.

[PeterS]

I have tried Vision before on the Milan with Minat/XaAES and it had issues. I just tried the new release.

1. The infill painting doesn't work, it just adds a single pixel horizontal line.
2. The button is dialogue boxes are a bit slow to respond, requiring a press and hold to get them to work.

[JeanMars]

Hi Peter,

for infill, I think it is a limitation of the v_contourfill API which may even crash on some VDI because of last parameter set to -1
For button slow to respond, I did not see a difference with other applications; could you elaborate?

[JeanMars]

@lp/vido: is there a description for such ldg usable by zview?
BTW unless a 680x0 application can load a ColdFire ldg, there is no interest to have this; and compiling VISION for ColdFire may be complicated especially because of the pure 680x0 routines I don't want to port to 'C'.

[vido]

@lp/vido: is there a description for such ldg usable by zview?
BTW unless a 680x0 application can load a ColdFire ldg, there is no interest to have this; and compiling VISION for ColdFire may be complicated especially because of the pure 680x0 routines I don't want to port to 'C'.

I am sure 68k application can load Coldfire LDG. If 68k application runs on Coldfire it is actually Coldfire application with some emulated instructions.
With Coldfire compiled LDG it is just less emulated instructions.

[lp]

@lp/vido: is there a description for such ldg usable by zview?
BTW unless a 680x0 application can load a ColdFire ldg, there is no interest to have this; and compiling VISION for ColdFire may be complicated especially because of the pure 680x0 routines I don't want to port to 'C'.

https://sourceforge.net/p/z-tools/code/ ... zcodeclib/

There must be some confusion yet. LDG itself comes in both flavors. zView codecs are also built for both. The end user simply installs 68k or coldfire stuff depending on their needs.

[vido]

There must be some confusion yet. LDG itself comes in both flavors. zView codecs are also built for both. The end user simply installs 68k or coldfire stuff depending on their needs.

I think he asks if VISIOn has to be Coldfire compiled to run Coldfire LDGs?
And I believe if 68k version of the VISION runs on the FireBee it can use Coldfire compiled LDGs.

[JeanMars]

Hi,

Yes that was my question because in zview the CF version of app calls the CF version of ldg i believe.
BTW, i'll have a look at zview plugin integration to estimate the workload.

[vido]

Yes that was my question because in zview the CF version of app calls the CF version of ldg i believe.
BTW, i'll have a look at zview plugin integration to estimate the workload.

Not exactly. I use Coldfire compiled Zview abut I use Coldfire and 68k compiled LDGs.
Lonnys LDGs are only 68k version and I use them with Coldfire Zview.
And it can be also the other way arround (on the FirBee).

Great! I hope you will find it easy to integrate!

Vido

[PeterS]

Hi Peter,

for infill, I think it is a limitation of the v_contourfill API which may even crash on some VDI because of last parameter set to -1
For button slow to respond, I did not see a difference with other applications; could you elaborate?

If I click on a Button (OK) as I normally would, nothing happens.

If I click and hold for 2-3 seconds then the Button operates.

I will test it again to make sure it was not some glitch. I had just run Vision 4.0 so that may not have helped.

[JeanMars]

@vido: looks like zview is pretty similar to VISION regarding image design; the big difference is that a ldg loads an image line per line, which should not be too complicated to handle from VISION.
Just a question of time to find, I have already a consequent backlog but will look deeply into this in the coming weeks.

[vido]

Hi Jean,

that sounds great and I am eagerly waiting new version of VISION
I believe that will really make VISIOn more usefull on the FireBee

Thanks,
Vido

[Cyprian]

Not sure this message would interest many people but to celebrate 25 years of VISION, painting & image management application, I just released a new version!
With many nice improvements, among them:
- TT-RAM handling
- Dynamic memory allocations tracker
- Making use of NFJPEG Aranym feature (thanks to Zorro/zView for inspiration as zView JPEG decoding speed just blew my mind )
- File Logging feature
- New LDV: Black Hole (tribute to Stephen Hawking)
And much more cool stuff as detailled here: http://vision.atari.org/vhistoe.htm

Hoping some would still enjoy this!
Have fun,
Jean

Just to let you know, under Aranym, Vision shows me wrong colors for attached BMP file.

[JeanMars]

Hi Cyprian,

what color resolution are you using in Aranym?
If it is not truecolor, use 'Tab' key to switch between color palette image and protected palette. This mecanism is used to avoid that an image with similar color for color used for text and background makes VISION not usable.

Cheers,
Jean

[Cyprian]

Hi Jean,
1280x768 32bit

[JeanMars]

Ok will try on my side this evening. In the mentime you can try to use bmp zview plugin instead of vision's internal one, just have a look at http://vision.atari.org/vhistoe.htm and change vision.ini accordingly.
Happy new year,
Jean

[Cyprian]

Actually I tried to convert BMP to IMG which zView doesn't support.

[JeanMars]

Hi Cyprian,

I fixed the bug, you can download a fix here: http://vision.atari.org/download/temp/vision.zip
My suggestion was to use zview plugin in VISION as explained at http://vision.atari.org/vhistoe.htm

A remark about saving then to IMG:
1- Use a 256 color resolution to perform this (or use Batch Conversion from menu) as VISION saves in current resolution color
2- VISION does not support IMG export in TC mode
2- If I remember correctly, VISION IMG format output is sometimes not readable by other viewers

Let me know about the result,
Jean

[Cyprian]

I added a correct path to zView "CODECS" folder in zvLDG in VISION.INI file.

Now that BMP is opened and shown fine.
It is 8bit color picture and I tried to save it as XIMG but Visions shows me error message "This file is a non-loadable version of the given format", and output IMG file is 0 byte lenght.

[JeanMars]

Hi Cyprian,

Note that for zView codec handling you also have to use GlobalPriorities in vision.ini to state your preference (1,2-->VISION first, zView second; 2,1-->zie first, VISION second).
In your case (default), it's VISION first, so new release correctly handles the BMP load.

However, as you are in TC mode and image is in 256colors, it cannot be saved as an IMG (VISION's limitation).
To work this out:
- Use a 256color resolution mode -or-
- Save to another format (I recommend TIFF in your case) -or-
- Use Batch Conversion from File menu

If you can tell me more about what you want to achieve (save to IMG for what?), I would be able to telle the most appropriate path to take.

Cheers,
Jean

[Cyprian]

Jean, sorry for the late reply.
I just was trying prepare a desktop wallpaper for Thing desktop. Despite of truecolor video mode, Thing accepts max 256 color IMG files, therefore I was trying to convert jpg to 8bit img file.

[JeanMars]

Hi Cyprian,

I made the test; set a 256 colors resolution, loaded a JPG image into VISION, saved it to IMG.
VISION/Smurf/Pixart loads it OK but Thing loads it wrongly,
So not sure it's a VISION issue here.

[Cyprian]

ok, thx