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

@jabirulo

Ok, thanks!
On current OS4.1fe do I need to buy/install some sort of 3rd party Radeon 2d/3d driver (i.e. a-eon enancher pack) to take full advantage of 9200 agp card? Do you suggest to download something from aminet/os4depot?

I’d like to try it on my Pegasos II and Radeon 9200 256mb but I got an error about no 3D support.
What does I need to run it on my Amiga? Do I have to buy latest enancher pack?

I suggest you to look inside also my fresh released FlashMandelNG source code and look for some speedup tips.

You can use same rendering technique even with 24bit screens and 24bit palettes.
Take a look also to main calc routines to have max speed and elaborate mandel and Julia sets with exponents between 2^1 and 2^11.

Happy programming

@All

Still looking for a gcc 6/7 binaries to download.
I'd like to build for Tabor too.

If possible I'd like to mix them with existing recent adtools downloaded from os4depot.

Maybe there's a bug in latest OS4.1 graphics.library, exactly in WritePixelArray() function, when PIXF_CLUT source pixel format is used in combination with 16bit/24bit/32bit destination rastports.
Instead it works ok on 8bit and 15bit destination rastports.

The source array is defined as follow:
UBYTE *GfxMem;

Anyone else noticed same issue? ..Can someone test it?