It's absolutely clear to me when exec-sg will be done we could have a new EnancherOS with all remaining parts owned by Hyperion replaced.

It can make sense in a next time, but now why do it? Are there some hidden messages to Hyperion?

Amiga community needs more clarity, we don't need obscure plans. Thanks.

@Capehill

Maybe with OS4 default datatypes you can’t save in all picture formats because there’s full support only for load.
Use iff ilbm format, it’s our standard for pictures.
We are amigans we have our peculiarities

@Capehill

You can use this to save an ILBM or change it for PNG.
Why not IFF ILBM?

@broadblues

I have modified code to try to implement custom chunks as suggested by Edgar, iff file is saved but opening it with an editor does not show presence of desired informations (custom chunks)

Here is my code, please look at followinf line

SetDTAttrs (o,NULL,NULL,DTA_Data,"***dino***",DTA_ObjAuthor,"***pippo***",DTA_ObjCopyright,"***pluto***",TAG_END);

it should do the trick and I added some different tags just to test, but nothing hoped happens.

Maybe it's a not fully finished impementation of iff datatype library.

/*----------------------------------------------------------------------------*/
/* Save the inner contents of a GZZ window as IFF picture using datatypes */
/*----------------------------------------------------------------------------*/
int32 savewindow (char *name,struct Window *win)
{
struct BitMap *bm;
Object *o;
struct BitMapHeader *bmhd;
UBYTE *cmap;
ULONG *cregs;
long i;
long w,h,d;
long ncols;
BPTR fhand;
struct ViewPort *vp;
int32 Error;

Error = TRUE;

if (bm = gzzarea (win))
{
w = win->GZZWidth;
h = win->GZZHeight;
d = GetBitMapAttr (bm,BMA_DEPTH);

ncols = (d > 8 ? 0 : 1 << d);

vp = ViewPortAddress (win);

if (o = NewDTObject (NULL,
DTA_SourceType,DTST_RAM,
DTA_GroupID,GID_PICTURE,
PDTA_BitMap,bm,
PDTA_ModeID,GetVPModeID(vp),
(ncols ? PDTA_NumColors : PDTA_DestMode),(ncols ? ncols : PMODE_V43),
TAG_END))
{

/* **** */ SetDTAttrs (o,NULL,NULL,DTA_Data,"***dino***",DTA_ObjAuthor,"***pippo***",DTA_ObjCopyright,"***pluto***",TAG_END);
//SetDTAttrs (o,NULL,NULL,DTA_ObjCopyright,©RIGHT_CHUNK,DTA_ObjAuthor,&USERNAME_CHUNK,TAG_END);

GetDTAttrs (o,PDTA_BitMapHeader,&bmhd,TAG_END);

bmhd->bmh_Width = w;
bmhd->bmh_Height = h;
bmhd->bmh_Depth = d;
bmhd->bmh_XAspect = 22;
bmhd->bmh_YAspect = 22;
bmhd->bmh_PageWidth = (w <= 320 ? 320 : w <= 640 ? 640 : w <= 1024 ? 1024 : w <= 1280 ? 1280 : 1600);
bmhd->bmh_PageHeight = bmhd->bmh_PageWidth * 3 / 4;

if (ncols)
{
GetDTAttrs (o,PDTA_ColorRegisters,&cmap,PDTA_CRegs,&cregs,TAG_END);
GetRGB32 (vp->ColorMap,0,ncols,cregs);
for (i = 3*ncols; i; i--)
*cmap++ = (*cregs++) >> 24;
}

if (fhand = Open (name,MODE_NEWFILE))
{
i = DoDTMethod (o,NULL,NULL,DTM_WRITE,NULL,fhand,DTWM_IFF,NULL);
Close (fhand);
if (i)
Error = FALSE;
else
Delete (name);
}

DisposeDTObject (o);
}
else
FreeBitMap (bm);
}

return Error;
}

I manage only 8 bit and 24 bit screens so other cases have to be excluded.

I can confirm setting PDTA_Remap to FALSE in NewDTObject function call resolved my issue, now pictures are correctly displayed.

About custom chunks sadly you confirmed my fears.
..but what are these defines in "datatypeclass.h" include file?

#define DTA_ObjAuthor (DTA_Dummy+110)
#define DTA_ObjCopyright (DTA_Dummy+112)
#define DTA_ObjVersion (DTA_Dummy+113)
#define DTA_UserData (DTA_Dummy+115)

Anyway IFF could be better supported because it's still a good standard to write data and represents one of the amiga good peculiarities.

I hope there will be written some high level calls to use datatypes in a more easy way in next OS releases.
i.e. SaveWinBitmap or LoadBitmapWin functions call with some useful arguments to pass in

I did not set the following TAG to FALSE

"PDTA_Remap,FALSE"

I remember it should be default.

Anyway I have anoter issue to resolve.. How I can add chunks inside iff file I have to write?
In "datatypeclass.h" include file I read, among others, following defines

#define DTA_ObjAuthor (DTA_Dummy+110)
#define DTA_ObjCopyright (DTA_Dummy+112)
#define DTA_ObjVersion (DTA_Dummy+113)
#define DTA_UserData (DTA_Dummy+115)

I'd like use them to write and read some values inside iff file (picture in my case) without use an external file.

Thanks!

Hi Amigans,
I need a fast help to resolve a issue about 8 bit (256 colors) images.
The following snippet code works ok with 24 bit images but fails to load 8 bit ones. I don't need to load 15/16 bit pictures.
The image is displayed but with less colors.
I grabbed code from Thomas examples

int32
LoadPic (struct ILBMInfo *ilbm, uint8 *filename)
{
int32 Error;
uint32 Width, Height, Depth;
Object *dto;

Error = TRUE;
Width = ilbm->Bmhd.w;
Height = ilbm->Bmhd.h;
Depth = ilbm->Bmhd.nPlanes;

if ((Depth == MIN_DEPTH) || (Depth == MAX_DEPTH))
{
if((dto = NewDTObject(filename,
DTA_SourceType, DTST_FILE,
DTA_GroupID, GID_PICTURE,
PDTA_Screen,ilbm->scr,
PDTA_UseFriendBitMap,TRUE,
PDTA_DestMode, PMODE_V43,
TAG_END)))
{
SetDTAttrs(dto,NULL,NULL,
GA_Left, 0,
GA_Top, 0,
GA_Width, Width,
GA_Height, Height,
ICA_TARGET, ICTARGET_IDCMP,
TAG_END);

AddDTObject(ilbm->win,NULL,dto,-1);
RefreshDTObjects(dto,ilbm->win,NULL,NULL);
RemoveDTObject(ilbm->win,dto);
DisposeDTObject(dto);
Error = FALSE;
}
}

return Error;
}

There will be a “lite” version of enhancer 2.0 for amigaone/pegasos/classic OS4 users?

I'm looking for a fast help about saving a 24bit bitmap into an ilbm file.
I need to save also a special (non standard) chunk.

Until now I used old "saveilbm" function, present into NEWIFF package, based on iffparse.library.
It's ok for 8 bit screens but on 24bit ones fails, when I go to reload image I got a black screen.
It's tested on OS4 only so maybe it could be ok on OS3.

If someone can give some hit to find a fix for saveilbm function, or suggest another way to do that, it will be much appreciated.

My perfect solution is to have a full 8bit/24bit bitmaps working function like this
SavePic (struct ILBMInfo *ilbm, struct Chunk *ChunkList1, struct Chunk *ChunkList2, uin8 *FileName)

I thought also to switch code to datatypes but I really dont't know hot to write iff special chunks using picture.datatype.

Bravo!

Please can we have an updated version of all adtools and gcc binaries on os4depot?
I know there’s an updated version of sdk (docs and includes) when Hyperion could release it?

Use simple printf and assure to avoid division by zero and all other values are as expected.

Anyway it could be an endian issue ..are you sure << operator have to shift values on left and not instead on right for big endian platforms?

These is a gcc compiler option about how to manage chars datatypes.
Maybe on windows defaults are different from others platforms.
As suggested you can declare var as signed char and look at debug printf output just to verify.

@amigakit

About replacing system files with others with same name I have no doubt it needs to be avoided for next future.
Not for legal/copyright reasons but simply for the best user experience and OS integrity/stability.
Really there is no reason to overwrite system files when you have infinite choices to name your new programs/apps.

Someone could feel this practice even as politically not correct vs Hyperion guys.

On some other OS this kind of practice is avoided and system files are always preserved.

Really I don"t kmow why enancher overwrite os4 apps.
With e bit of fantasy you can name enancher clock in "eclock" and so on..

@kas1e

Sure, thanks!
I'll wait for a new native version, I hope even in a fork with SPE support re-enabled.

@Raziel

Even in latest native GCC 8.4.0 -flto gcc option does not work.
I got same isues as you.

Our Amigas are very old and really we need any speed optimization to run recent software, ..any idea how resolve it?

it works very well, tnx Kas1e!

@kas1e

It really should be a best practice for all AmigaLike system programmers.

@Ami603
Well done! Thanks for sharing your code and efforts.

@Capehill

In the source code there are routines for arbitrary precision math.
I use them for deep zooming.
If you are able to translate them on gpu you are the winner