Picture Objects do not work as they should. If you specify an image file, it is loaded with wrong colormap. I tried various screenmodes and formats (ILBM, JPG).
Picture Objects do not work as they should. If you specify an image file, it is loaded with wrong colormap. I tried various screenmodes and formats (ILBM, JPG).
Yep. Tested it only now and you right. But its not looks like endian issues, or wrong byte swapping, it looks like just something wrong (like rendering image to 256cols, and give it a bit wrong palette) Also it loads image in not original size (but imho should ?).
That how it looks for me:
.
At right side original (jpg) by multiview, and on left how it opens by default (with wrong size, and fucked colors).
Btw, for me also when i press on "picture" button, the window for it hides over the main one. The same for you ?
Yes, my pics look similar when imported in an AmiFIG PictureObject: the image is recognizable but the colormap is wrong, as if converted to a smaller number of colours.
Quote:
Btw, for me also when i press on "picture" button, the window for it hides over the main one. The same for you ?
Yes but this only happens when running AmiFIG on a public screen (Workbench). If you use a custom screen, the Picture Object control window opens normally.
Yannick fix the problem for image loading. Now its fine:
.
There is still few some little bugs, but the one hardcore one, looks like this (reported from few users already) :
When I add a text object and then try to move it around (using the Move Objects tool), AmiFIG leaves mess (text artifacts) on the canvas wherever the mouse pointer moves. Although the mess will disappear if you update the canvas, it makes it difficult to position the text properly because the artifacts overdraw the picture and get in the way.
That problem not occurs on aros, and i think its aos4 specific, and realted not to text, but how some classic amigaos3.x api works. For now i have i one project in which i have exactly the same problem on aos4 (while on os3 all is fine): when you move the sprite, it leaves mess behind.
Related to 256cols, its in general make no so big sense imho today, and Yannick say that probably he will not support less that 16bit.
@xenic Maybe you can help with that "leave mess when move the text object" ?
Thanks, good to see bugs being fixed! Please also remind Yannick of what I posted earlier:
"There are a few minor annoyances, like for example, if you want to move an object using the MOVE tool, the object "jumps" to the upper left corner first, which is very inconvenient (you lose the original object position so finetuning object placement is almost impossible).
Also, some reserved keyboard shortcuts (see Amiga User Interface Style Guide, chapter 10) are used for proprietary functions, namely: RAmiga-C opens the Color Window (should be reserved for copy operations) RAmiga-Z opens the Zoom Window (should be used for Undo)"
"There are a few minor annoyances, like for example, if you want to move an object using the MOVE tool, the object "jumps" to the upper left corner first, which is very inconvenient (you lose the original object position so finetuning object placement is almost impossible).
Yeah ! I already notice the same few days ago, and report to Yannick already.
Quote:
Also, some reserved keyboard shortcuts (see Amiga User Interface Style Guide, chapter 10) are used for proprietary functions, namely: RAmiga-C opens the Color Window (should be reserved for copy operations) RAmiga-Z opens the Zoom Window (should be used for Undo)"
Will report about right now.
Maybe you can have a look at that "move text un-erased background stuff" ?
"There are a few minor annoyances, like for example, if you want to move an object using the MOVE tool, the object "jumps" to the upper left corner first, which is very inconvenient (you lose the original object position so finetuning object placement is almost impossible).
@kas1e The AmiFig output for exporting was changed and the script for export is no longer necessary (for the version at OS4Depot - things keep changing). Here is how to use export now: Open the Preferences (Menu Settings/Edit). Select the I/O tab.
In "Fig2Dev Command" enter: "fig2dev" if you copied fig2dev to C: or enter "fig2dev/fig2dev" if the command is in the AmiFig/fig2dev directory.
In "Fig2Dev Input option" enter: "-L eps" or "-L latex" depending on what output format you want.
In "Fig2Dev Output option" enter: "ram:figoutput" or a path & file where you want the output saved.
In the above example, the eps or latex file will be ram:figoutput.
@kas1e That's correct. The CallFig2Dev script is no longer needed and can be removed from the repository. Yannick must have rearranged the argument order to Fig2Dev so that it now works without a script.
The PNG option works but Fig2Dev calls GhostScript for that format. Use -L png (png must be lowercase) and be sure DH0:Utilities/Ghostscript/gs is in your shell search path. Either add the path in user-startup or copy "gs" to a directory that is already in the search path (like C:).
@xenic I mean not export via fig2dev, but exatly export menu called "PNG", which as i understand works over datatypes, and not use fig2dev at all (for fig2dev export there is another menu in export, called "export via fig2dev" ).
That what Yannick answer to me yesterday: Quote:
PNG export works under AROS, the code might however be quite specific, it's in bitmap.c. I'm using datatype write method (DTM_WRITE).
If you have a working example under os4 I can compare with what is implemented in AmiFIG.
As i understand PNG export should works thorugh datatypes. But for now, when i press Save for png-export, then it not create for me any file in the directory which i point , what make me think, that its just some bug in the locking/unlocking stuff or kind.
I'm not sure an *export* in any bitmap format (here: PNG) really works with datatypes - afaik it doesn't at least with OS3.9. It only *exports* IFF. Don't know whether this changed in OS4.x or not...
//write datatype object to file if (file = Open (Name,MODE_NEWFILE)) { dtw.MethodID = DTM_WRITE; dtw.dtw_GInfo = NULL; dtw.dtw_FileHandle = file; dtw.dtw_Mode = DTWM_RAW; dtw.dtw_AttrList = NULL;
if (DoMethodA(DTImage, (Msg) &dtw)) { Close (file); if (dst) FreeVec(dst); DisposeDTObject(DTImage); return(TRUE); } Close (file); if (dst) FreeVec(dst); DisposeDTObject(DTImage); put_msg((UBYTE *)msg_DatatypeError); return(FALSE); } }
So , it should save png-files, and on AROS it is, but something wrong with that for AOS4 (not exactly with code which i posted, but with the whole routine itself).
@kas1e I threw in some printf's and the saving stops at the NewDTObject() function in bitmap.c. I suspect that OS4 Datatypes only saves IFF. Both Multiview and RAWBInfo save images as IFF, even if they are loaded as PNG. The code could probably be changed to save IFF but I don't thing PNG is going to work. Maybe someone else who knows more about datatypes could confirm.
@xenic With help of Trixie, when i press on save for png , it create file, but its empty for now. I solve this by adding that: DTA_GroupID,GID_PICTURE, to NewDTObject stuff. Will try to invistigate it more, but your help are need it of course :)
I add some more debug-printfs, and found that on that piece of code from bitmap.c:
Quote:
//write datatype object to file if (file = Open (Name,MODE_NEWFILE)) {
printf("we trying to do DoMethodA\n"); fflush(stdout);
if (DoMethodA(DTImage, (Msg) &dtw)) { printf("we in domethodA!\n"); fflush(stdout);
Close (file); if (dst) FreeVec(dst); DisposeDTObject(DTImage); return(TRUE); } Close (file); if (dst) FreeVec(dst); DisposeDTObject(DTImage); put_msg((UBYTE *)msg_DatatypeError); return(FALSE); }
I never have "we in domethodA" words, what mean that DoMethodA not works as should ?
I never have "we in domethodA" words, what mean that DoMethodA not works as should ?
It means that writing the image to the opened file is failing. DoMethodA is supposed to write the image to the opened file. Something is probably wrong with the datatype object creation, the dtw structure or the dtb structure. Beyond that, I don't know enough about datatypes to tell what's wrong.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
