Quote:

broadblues As I just demonstrated you discard 1 point of range you maximum colour is now 254, and the point again just because AGA didn't have it doesn't mean other system were or will be limited.

Not if you simply discard the unused 24 least significant bits, which is probably what the OS does. Why divide by 0x01010101 at all? Furthermore, AGA palette entries are set in pairs of 12 bit values. If you have 00RrGgBb, you have to write 0RGB and 0rgb separately. It makes absolutely no sense to divide by 0x01010101 at all.

@Thorham

Quote:

Not if you simply discard the unused 24 least significant bits, which is probably what the OS does. Why divide by 0x01010101 at all? Furthermore, AGA palette entries are set in pairs of 12 bit values. If you have 00RrGgBb, you have to write 0RGB and 0rgb separately. It makes absolutely no sense to divide by 0x01010101 at all.

"Probably", "maybe" , "I'd think that", idiots like you and Hypex are the reason it so hard to port and maintain compatabilty for old software, you assume you know what the OS is doing, you may even have peeked at the code and know what it *was* doing, but you *must not* do that you code to the specified API, which specifies that the maximum is 0xFFFFFFFF and the minimum 0x00000000 the only way to satisfy that is to multiply by 0x01010101 (how the OS deals with that internally will be hardware specific and none of your concern).

Last edited by broadblues on 12-Jul-2014 at 06:43 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

I'm an idiot? Haha lol no. You're just completely wrong here, and have obviously NOT read the relevant part of the autodocs which says this:

Quote:

NOTES Lower order bits of the palette specification will be discarded, depending on the color palette resolution of the target graphics device. Use 0xffffffff for the full value, 0x7fffffff for 50%, etc. You can find out the palette range for your screen by querying the graphics data base.

This comes straight from the autodocs: http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0328.html

According to you, for that 50% value it should be 0x7f7f7f7f. The autodocs say something else entirely.

Before you call someone an idiot, you better make sure that you know what you're talking about, which you obviously don't.

Last edited by Thorham on 12-Jul-2014 at 07:07 PM.
Last edited by Thorham on 12-Jul-2014 at 07:07 PM.

@Thorham

Before you claim not to be an idiot you better learn some mathemtics as 0x7f is not 50% of 0xff (there is no true 50% point in a descrete 0 - 255 scale).

But 0x7f7f7f7f is exactly the same proportion of 0xffffffff as 0x7f is of 0xff.


If you are converting from 256 (8bit) to the 32bit format the only accurate formula is the one I just described.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

I know damn well that 0x7f isn't 50% of 0xff, and I never claimed that it is. I mean, really? Do you actually think I don't know that 255 / 2 = 127.5? How insulting. Then again, what am I supposed to expect from someone who calls people idiots and claims people said things they didn't say just so that they can appear right and the other wrong (which no one will buy anyway, because no one is that stupid).

In case you forgot: I'm talking about what the autodocs say about SetRgb32(), which is what this is about. You claim eight bit color channel values have to be multiplied by 0x01010101, while the autodecs make absolutely no mention of this.

You also claim that we don't know what the OS does, while the autodocs say that the lower bits are discarded depending on the device used.

Obviously the device used will be something with a palette mode (that's what SetRgb32() is for after all), and obviously such mode is going to use eight bits per color channel.

Really, you're calling people idiots and being dishonest. Think about that.

@Thorham

Sorry shouldn't call you an idiot, uncalled for, I'm trying explain an important point about the API and was getting frustrated at my inabilty of convince of my (important) point.

Quote:

I know damn well that 0x7f isn't 50% of 0xff, and I never claimed that it is. I mean, really?

Yes you did, by implication of the folllwoing statement:

Quote:

According to you, for that 50% value it should be 0x7f7f7f7f. The autodocs say something else entirely.

Now I clearly don't think that when you think through the seemingly obvious maths that you wouldn't realise your mistake, because clearly 255 / 2 is 127.5 but actually that particular mistale is an exceptionaly common source of colour conversion bugs (usually indirectly by multiply a normalise colour value by 256 instaed of 255 and other similar things.).

Quote:

In case you forgot: I'm talking about what the autodocs say about SetRgb32(), which is what this is about. You claim eight bit color channel values have to be multiplied by 0x01010101, while the autodecs make absolutely no mention of this.

They say nothing about 8bit channels at all, only that the max value is 0xFFFFFFFF and the minimum 0x00000000. Mathemetics says that how you convert from one to the other. If you colour values were in normalise floating point ( ie 0.0 - 1.0 you would multiply 0xFFFFFFFF but they don't tell you that either.)

Check the C Source output from DPaint ot PPaint (PPaint for certain) if you think I'm making this up myself.

Quote:

You also claim that we don't know what the OS does, while the autodocs say that the lower bits are discarded depending on the device used.

It doesn't say how many bits are discarded though. MIght be less. Some future device may use more. If you don't set the colur correctly it will be wrong.

Quote:

Obviously the device used will be something with a palette mode (that's what SetRgb32() is for after all), and obviously such mode is going to use eight bits per color channel.

Not obviously at all, You don't know what device your software is on, the OS deals with that, you just asking for the closest colour to teh one you defined, which may not be from an 8bit per channel source, and may not end up on a 8 bit per channel screen. Also palettes my be used on true colour screens.

Quote:

Really, you're calling people idiots and being dishonest. Think about that.

Dishonest? I gave an accurate description of how your supposed to use this function. Dishonesty would be to allow the misunderstanding to pass, and broken software to be written.

I apologise again for the idiot bit.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

Quote:

broadblues wrote: Sorry shouldn't call you an idiot

Thanks 8^)

Quote:

broadblues wrote: Yes you did, by implication of the folllwoing statement: Quote: According to you, for that 50% value it should be 0x7f7f7f7f. The autodocs say something else entirely.

No, I wasn't, because I was stating what the autodocs have to say about this. The autodocs state you should use 0x7fffffff for half value, and not 0x7f7f7f7f. Makes you wonder why they actually bothered with the whole 32 bit thing at all.

Quote:

broadblues wrote: Not obviously at all, You don't know what device your software is on, the OS deals with that

Software that sets eight bits per channel is going to open a screen with an eight bits per channel palette. It's up to the OS to handle this properly.

For eight bits per channel palette based screens, none of this matters at all. It also doesn't matter for OCS/ESC graphics on AGA, for example, because you just use SetRgb4().

Quote:

broadblues wrote: Dishonest?

It sounded like you where twisting my words, sorry about that.

Quote:

broadblues wrote: I gave an accurate description of how your supposed to use this function

No you didn't, because the autodocs say something else. Everyone who reads the autodocs is going to shift their eight bit value three bytes to the left, and fill the remaining bytes with 0xffffff.

Anyway, this problem is only relevant if you're going to actually use graphics modes that have more than eight bits per channel and are palette based, and use eight bits per channel graphics on those modes. I'm quite sure it's safe to say that that's not ever going to happen.

Also, how many graphics cards are out there that have palette modes with more than eight bits per color channel? I'm willing to bet that there aren't any. Any palette in such modes is going to be software based.

@Thorham

Quote:

No you didn't, because the autodocs say something else. Everyone who reads the autodocs is going to shift their eight bit value three bytes to the left, and fill the remaining bytes with 0xffffff.

They do not remotely tell you to do that!

Also why would GetRGB32 return 0x01010101 ? or 0x01234567 as described is this note in SetRGB32CM() ?


Prior to V46 the lower nibble of the blue color in the ColorMap
was constructed from the wrong bits of the input ULONG value,
e.g. 0x01234567 -> 0x03 instead of 0x01 (or 0x01010101 returned
by GetRGB32()).


Also from the 3.1 NDK tutorial

There are now ...RGB32() functions to replace the ...RGB4() functions.
These all work in 32-bits per gun, irrespective of the device the
colors are intended for. Devices that cannot handle the color
resolutions will truncate the colors to the most significant n bits.
That is why it is important to duplicate the most significant n bits
throughout the 32-bit resolution. For example, pure white should be
treated as:

R = 0xffffffff, G = 0xffffffff, B = 0xffffffff

and not

R = 0xf0000000, G = 0xf0000000, B = 0xf0000000


From 3.1 NDK exampkles 2

r = (r << 24) | (r << 16) | ( r << 8) | r;
g = (g << 24) | (g << 16) | ( g << 8) | g;
b = (b << 24) | (b << 16) | ( b << 8) | b;


That's logicaly equivalent to multiplying by 0x01010101 BTW

I could probably find more but it takes such a long time to search the DEV CD!

Last edited by broadblues on 12-Jul-2014 at 11:26 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

Quote:

broadblues wrote: They do not remotely tell you to do that!

They do:

Quote:

Use 0xffffffff for the full value, 0x7fffffff for 50%, etc.

Straight from the autodocs (the part I linked to earlier). How else are you supposed to interpret this?

However, the rest of your post makes it clear that we're not using the same docs: http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node0329.html which is from this dev site: http://amigadev.elowar.com/

What you're describing is nowhere to be found in the SetRgb32CM() function description I linked to.

Quote:

broadblues wrote: Also why would GetRGB32 return 0x01010101 ? or 0x01234567 as described is this note in SetRGB32CM() ?

That note isn't in the docs I'm using, as I've shown above. Which documentation are you using?

Last edited by Thorham on 13-Jul-2014 at 06:19 AM.
Last edited by Thorham on 13-Jul-2014 at 06:13 AM.

@Thorham

Quote:

Quote: Quote: broadblues wrote: They do not remotely tell you to do that! They do: Quote: Use 0xffffffff for the full value, 0x7fffffff for 50%, etc. Straight from the autodocs (the part I linked to earlier). How else are you supposed to interpret this?

Exactly as writen, it describes the data type to be supplied as a left justified 32 bt fixed point fraction. Ie a value from 0 to 1 expressed as 0x00000000 to 0xffffffff

It doesn't actually tel you how to convert from a 8bit left justified fixed point fraction (which is what a 8bit colour value efectively is in this context).

Lets test your algorithm

Take 0xFF shift left 24 bits 0xFF000000 fill the remain bits with FF 0xFFFFFFFF

Well that works,

Now 0x7F shift left 24 bits 0x7F000000 fill the remaining bits with FF 0x7FFFFFFF

Oh that the value quoted as 50% but we've already establish (slight painfully) that you understand that 0x7F is not 50% of 0xFF so the result is wrong!

Now 0x00 shift left 24 bits 0x00000000 fill with FF 0x00FFFFFF

hmm but 0x0 shouldcome to 0 surely?

Now lest take "my" algorithm.

Genaralised first we have a number a/b that we want to express as c/d

a * d / b
_________
b * d / b

so c = a * d / b

now specifically d = 0xFFFFFFFF and b = 0xFF so d/b = 0x01010101

thus to convert from an 8bit fraction to an 32 bit one we multiply by 0x01010101

for FF gives 0xFFFFFFFF for 0x7F gives 0x7F7F7F7F for 0x00 gives 0x00000000

all those give the same fraction as the 8bit equivalents.

QED


Quote:

What you're describing is nowhere to be found in the SetRgb32CM() function description I linked to.

It's in a bug note about a bug in Version 46 so probably appeared in the 3.9 NDK

Quote:

Which documentation are you using?

In the first instance the autodocs on my machine (latest beta SDK) second instance the official documentation on the amigaos wiki http://wiki.amigaos.net/wiki/Main_Page, third instance the DEVCD volume 2.1 (legal purchased copy) which 'your' online docs are extracted from. The examples I gave above were from the 3.1 NDK (possibly 3.5) contained on the CD.

There were other examples using that 32 fixed datatype but they related to the colour wheel and you couldn't see the values returned by the HSVtoRGB functions.

Last edited by broadblues on 13-Jul-2014 at 11:41 AM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

Quote:

broadblues wrote: Exactly as writen, it describes the data type to be supplied as a left justified 32 bt fixed point fraction. Ie a value from 0 to 1 expressed as 0x00000000 to 0xffffffff

Yes, but they make it look like they want you to pad three bytes with 0xffffff, because of their full and half value example. That's the reason I thought it didn't matter in practice, otherwise their full and half value example doesn't make sense.

Quote:

broadblues wrote: It's in a bug note about a bug in Version 46 so probably appeared in the 3.9 NDK

Ah, that's why it's not in there. Haven't bothered updating to 3.9, because I use KS3.0, and that on line 3.5 NDK documentation, so I'll have a look at that.

Quote:

broadblues wrote: In the first instance the autodocs on my machine (latest beta SDK) second instance the official documentation on the amigaos wiki http://wiki.amigaos.net/wiki/Main_Page, third instance the DEVCD volume 2.1 (legal purchased copy) which 'your' online docs are extracted from. The examples I gave above were from the 3.1 NDK (possibly 3.5) contained on the CD.

Cool, thanks

Glad to finally get that out of they way

Last edited by Thorham on 13-Jul-2014 at 01:06 PM.

@broadblues

Quote:

Sorry that wan't an optinion it was a statement of fact.

Then what are you apologising for?

Quote:

To convert a 8bit colour number to a 32 bit you *must* multiply by 0x01010101

You're going the wrong way. In the content I am speaking of and to which you quoted I am talking about the OS. The OS will not be multiplying up to convert the 32-bit value to an 8-bit value on the hardware.

Quote:

You have no idea how the OS is processing that number and you can make no assumptions about it

On AGA this will be 8-bits. So that 32-bit value will be downsized to an 8-bit value in any case. But this misses the point. The point I was making is that 8-bit RGB functions would have been fine and satisfied the available hardware while 32-bit RGB functions, whilst built from good intentions, were over the top. Jumping from 4 to 8-bits was a logical choice, jumping from 4 to 32-bits was extreme.

All the Amiga RTG APIs I have seen use 24-bit RGB which easily fits into a long word. Requiring the user to use 32-bit RGB values not only made it harder for the user but added overhead. Most popular image formats including IFF only supported up to 8-bit RGB. And since AmigaOS wasn't running on a fast CPU this made less sense.

Quote:

AGA had 8 bits per colour colur channel did it not?

Yes, and when the 8-bits were set in the palette, they had to be split into a high nibble and low nibble as the values are set in 4-bit triplets like on OCS/ECS.

Quote:

As I just demonstrated you discard 1 point of range you maximum colour is now 254, and the point again just because AGA didn't have it doesn't mean other system were or will be limited.

What does that matter? The OS will be discarding the unused bits, not the user. And what other graphic systems are there that have over 8-bits precision that AmigaOS has access too?

Last edited by Hypex on 13-Jul-2014 at 03:57 PM.

@Hypex

Quote:

All the Amiga RTG APIs I have seen use 24-bit RGB which easily fits into a long word.

Well there is no support for Alpha in the Pen system, anyway the Pen system is does not make sense when you have more then 256 colors, It will not look so good if stick to the old ways.

Some kind of RGBToNativeBitmapPixelFormatTagsWithCherriesOnTop() might have been useful

For example

uint32 pixelfmtcolor;

pixelfmtcolor = RGBToNativeBitmapPixelFormatTagsWithCherriesOnTop(
TAG_please, True,
TAG_ConvertToGrayColors, True,
TAG_R, 255,
TAG_G, 0,
TAG_B, 0,
TAG_InvertColors, True,
TAG_Done
);



Quote:

What does that matter? The OS will be discarding the unused bits, not the user. And what other graphic systems are there that have over 8-bits precision that AmigaOS has access too?

It makes even less sense when you only have a 256 colors palette.

Last edited by NutsAboutAmiga on 13-Jul-2014 at 08:14 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Hypex

Quote:

You're going the wrong way. In the content I am speaking of and to which you quoted I am talking about the OS. The OS will not be multiplying up to convert the 32-bit value to an 8-bit value on the hardware.

Your carefully quoting out of context so as to hide the fact you got it wrong, although I also accidebntal type right rather than left, which admittedly adds confusion, but I am clearly commenting on converting to the 32bit format not from anmd you address both in your original comment.

Original exchange below:
Quote:

Quote: All they did was create a PITA requiring programmers to shift each RGB element 24-bits to the left which the OS then shifted back 24-bits to the right. What was the point of that!? You don't shift 24 bits to the right or you discard resolution you multiply by 0x01010101 so that 0xCE becomes 0xCECECECE.

Now lets ignore the technicalities of the conversion and the definition of the 32bit format, I allready had a somewhat unexpectantly long exchnage on that, which I'm sure you've read and understood.

Thw why is more interesting I think:

Quote:

The point I was making is that 8-bit RGB functions would have been fine and satisfied the available hardware while 32-bit RGB functions, whilst built from good intentions, were over the top. Jumping from 4 to 8-bits was a logical choice, jumping from 4 to 32-bits was extreme.

Maybe but your instantly relimiting the API to an arbitrary small size, when the datatypes are for larger sizes easily withing the scope of existing hardware. Think aboutthe fact that is a short period of time the bits per channel had doubled, would it not be likely it would double again? As it turned out the emphasis moved ot more pixels rather than more colours but we know that with hindsight. Also consider that colour calaculatins in 8bit are much less acurate than those in 32bit, particularly when dealing with HSV to RGB conversion, and your much lived colour wheel uses such a format for this same reason.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

Hm, (thinking to self) any wonder why newbies get frustrated and lost.

AND .... Yeah, right. I got your FM, RIGHT HERE!

_________________
Tinkering with computers.

@Hypex

Quote:

I always wondered how computers (I mean the Amiga) could display silvers on screen. I could never figure it out using RGB sliders. But somehow that worked.

Silver or gold or any shiny metalic colour aren't really colours as such, so you'll never find it with RGB sliders, it's a refelctive surface, so displays the colours from the surrounding image (mixed with a little grey, yellow for gold I suppose), so to "display silver" you have to mimic that reflection with the specular highlights.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Signal

Probably because misguided individuals who haven't read their own FM properly give you advice?

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

Quote:

broadblues wrote: @Signal Probably because misguided individuals who haven't read their own FM properly give you advice?

Advice.

Advice?

OK, that's what we'll call it.

_________________
Tinkering with computers.

@Signal

But seriously if you get stuck with a bit of AOS coding just ask.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@Signal

But if you do ask Brodblues for advice you are likely to get a few facepalm and being called a idiot a few times, for being wrong

Last edited by NutsAboutAmiga on 13-Jul-2014 at 10:51 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS