PureBasic Forums - English

Thanks for the mesh example. About RGB, yes it can't be used in a constant expression for now.

Fred wrote:Thanks for the mesh example. About RGB, yes it can't be used in a constant expression for now.

I badly expressed myself. What I wanted to say it is that the red and blue are reversed.

To have vertex blue , Color must be = 255
and RGB(0,0,255) give 16711680
[EDIT]
Ok i Can write RGB(B,G,R) , but it's weird

About MenuItem
I've some problems with menus... tracing EventMenu() I've noted some MenuItem IDs that are not been used in my program...

The bug is that MenuItemID must be a Word (2 bytes) variable. If I use some values over 32767 it changes the returned ID.

Why cannot it be a Long variable?

JOAQUIN

Comtois wrote:I badly expressed myself. What I wanted to say it is that the red and blue are reversed.

To have vertex blue , Color must be = 255
and RGB(0,0,255) give 16711680

PB has always used Blue as the most-significant-byte(?) in RGB procedures... which as far as I know is not the standard way...

i hereby vote for changing it make it rgb

i know bgr is the windows way...

or perhaps we should have BGR as well as RGB?

This is basicaly the flaw of having two different bit orders.

Big Endian known also known as Motorola byte order and in internet networking as Network Byte Order, Amiga/Atari/Mac (Motorola 680x0 cpu's), PowerPC and Xbox 360 as well as Playstation 3's cpu I suspect and so on.

Little Endian also known as Intel byte order.
used in Intel and AMD based cpu's and compatible cpu's.

If RGB values are turned into a integer value, it ends up stored in RGBx order on Big Endian cpu's,
or xBGR on Little Endian cpu's.
If stored in a 32bit long that is. (the x being the unused byte)
It's even more of a headache in cases where you got RGBA
(A being alpha).
In addition a OS may work with different byte order for certain things like RGB. (so that RGB is always stored in RGB order)

I always hated Intel for messing up the way numbers are stored.
Short history lesson (from my mangled memory).

In the beginning 8bit existed and all was good (mostly at least),
numbers was only 1 byte large. Then 16bit came, and Intel did the weird reverse byte order to make sure that compatibility with 8bit was possible.
When 32bit arrived this got a bit more confusing.

Motorola on the other hand, worked with 32bit from the ground up.
A wise move in my eyes as a 8bit or 16bit or 32bit system is not really the same thing.

Obviously strings are totaly unaffected by this.
Provided they are ascii/latin-1 or (and possibly UTF 8, sure hope so),
Unicode-16 or Unicode-24 or Unicode-32 obviously suffer from the byte order issue.

I really wish Intel and Motorola had agreed on a standard back then,
or one of them folded. Byte orders still give me a pain.
Luckily with x86 Linux systems being so widespread and the new x86 Mac's, and Windows being so dominant, Little Endian is the most common.
However internet networking still use the (in my eyes correct) Big Endian.
So we still got a mess. Then there is all those portables etc.

Basicaly computing is still split in two, Big Endian and Little Endian,
just like PAL and NTSC tv standards,
HD-DVD and Blu-Ray.

*sigh*

Anyway, search the forums for littl endian or big endian or swap or endian swap

I did a routine some time back, as have others. there should be at least be one nice asm procedure to easily "swap" the endian order of a long.
If you got issues with RGB endian, use the endian swap and you'll save yourself a lot of confusion

I believe OpenGL expect Big Endian RGBA rather thah Little Endian ABGR
or is that BGRA ? *screams*

PS! Fred's a genious for deciding on UTF-8 being "native" standard for PB,
just double checked and since it's a byte sequence it is fully endian neutral.
*gives Fred a cookie*