helmut wrote:Maybe a call of wind_update(BEG_UPDATE) before displaying a bubble fails (returns 0) if the menu is open.
JeanMars wrote:I don't know what could be wrong here; did you try another file selector? There is a known bug using myAES about the progress window not being properly displayed/managed.
You can try this intermediate version to check: vision.atari.org/download/temp/vision.zip
For ColdFire CPU, I'm afraid not as I'm using PureC.
JeanMars wrote:So no easy patch...
JeanMars wrote:There is a possibility I move to AHCC in the future but I have other things in current backlog, I gave a quick try but looks like I will need some time to compile using AHCC...
Let's keep in touch, as soon as I can move to AHCC, I'll ask you to do some test for ColdFire.
JeanMars wrote:And wind_update calls don't change a thing.
I set a different output folder for assembly files in PureC configuration.
BTW I have more and more problems making a full build with PureC (crashes, un-expected random compile errors, ..)
I should move to AHCC.
JeanMars wrote:Actually it behaves a bit different on my side as I don't even have this issue with myAES but only on XaAES (the one I'm using usually). And wind_update calls don't change a thing.
JeanMars wrote:- AHCC has high compatibility with PureC
I believe I could still use PureD)
gcc would lead to tons of rework (e.g. int-->short)
PS: still in the process to support PNG files, looks OK, I just have a crash on a certain PNG file because of setjmp 'C' function for error handling, basically for loading an image I call an identify routine and then a loading one.
JeanMars wrote:yep about assembly source:
- PureC passes parameters in registers, so all assembly files in VISION have this logic; would be a high risk nightmare to move to stack parameters,
- not sure mnemonics, syntax, macros are the same with PureA/gcc
And thinking about this, I'm not sure it makes sense for ColdFire:
VISION has 68000/68020 optimized routines for LZW decoding, bitplan manipulation, scaling, etc., these one will remain pure 680x0 code so no ColFire optimization on them.
So vido, I don't think compiling for ColdFire will make a difference in your case
JeanMars wrote:yeah, native execution power....
Is there a JPEG decoder on ColdFire (like on Falcon)? in this case JPEG images would decode as fast as zview as VISION makes use of JPEGD.
JeanMars wrote:VISION uses LDG but for image modifications, not loading/saving.
My question was more about if there is a JPEGD decoder for ColdFire (like on Falcon which uses DSP and Aranym which uses native JPEG code then).
If so, at least JPEG image can benefit of ColdFire code with VISION.
JeanMars wrote:Depends which application...
zview relies on LDG to load images
VISION has its own internal routines; for JPEG, it looks for JPEGD, if so it uses it else it fallback to pure 68000 code.
VISION could use LDG for loading/saving, with some rework, but not sure a 68000 application could call ColdFire LDG, I believe it has to call a 68000 LDG.
Users browsing this forum: No registered users and 3 guests