Byte 0/1/2/3 (Hot Keys and Hot Buttons)

[Jamie Fox]

This is quite a hard problem to explain, so I'll try an example.

Let's say that there is a hot key slot free at offset 0x3210. This is a 32-bit area, so therefore contains 4 bytes. What I'm unsure of is which byte is 'byte 0' and which is 'byte 3'. To put it another way, are they numbered from right to left or left to right?

To take an arbitrary hex value of 0x12AB34CD. Which is byte 0? 0x12 or 0xCD? Also, if I was to write 0x12AB34CD to offset 0x3210, what would be at offset 0x3213? Would that be 0x12 or 0xCD?

This question isn't really specific to FSUIPC I don't think, but having a very limited background when it comes to programming I don't really know where to find the answer to this.

Thanks in advance.

[Pete Dowson]

Let's say that there is a hot key slot free at offset 0x3210. This is a 32-bit area, so therefore contains 4 bytes. What I'm unsure of is which byte is 'byte 0' and which is 'byte 3'. To put it another way, are they numbered from right to left or left to right?

Not so much numbering. Byte 0 just means the 1st byte, the one at relative address 0. And so on. If you were using an array of bytes

BYTE bHotKey[4];

then byte 0 is bHotKey[0], .... byte 3 is bHotKey[3].

To take an arbitrary hex value of 0x12AB34CD. Which is byte 0? 0x12 or 0xCD? Also, if I was to write 0x12AB34CD to offset 0x3210, what would be at offset 0x3213? Would that be 0x12 or 0xCD?

Ah, if you manipulate it as a 32-bit word, instead of 4 separately addressable bytes, then all you need to know is that in Intel processors (and their compatible non-Intel relations), the "least significant" comes first and the "most significant" comes last. this is termed "Lo-Hi" format. Motorola processors (68000) are Hi-Lo instead. Not sure about the others.

So, your 32-bit value 0x12AB34CD is actually stored in memory in 4 successive bytes as

0xCD, 0x34, 0xAB, 0x12

making 0xCD byte 00x12 byte 3.

Incidentally, this "numbering" method is also used for bit numbers. so "bit 0" is the Least Significant bit (value 1), and so on.

Regards,

Pete

[Jamie Fox]

For some reason it hadn't crossed my mind to manipulate the 32-bit offsets as an array of four BYTEs, rather than a single DWORD. It's clearly much easier to keep track of what's going using individual BYTE types.

So, going by the way that an Intel processor would handle things, it's actually 'written down' the opposite way as to how you'd write it in human-readable (or even C++ readable) form.

Right, so byte 0 is 0x3210, byte 1 0x3211, etc. This makes sense. If I was to manipulate this as a single DWORD, the least significant part is byte 0 bit 0, which would go on the right (as written). I think I have my head round this now.

I've had all kinds of trouble this morning trying to get a joystick hot button to work, although mainly due to my inability to type the data in the right order!

That reminds of me of the other question, this time specific to hot buttons and joysticks. The SDK says that 'Joysticks are number... from 0. Game Controllers numbers from 1.' I only have one joystick connected (a CH products USB yoke), so would that be joystick 0 or 1? Similarly, are the joystick buttons numbered from 0 or 1?

[Pete Dowson]

That reminds of me of the other question, this time specific to hot buttons and joysticks. The SDK says that 'Joysticks are number... from 0. Game Controllers numbers from 1.' I only have one joystick connected (a CH products USB yoke), so would that be joystick 0 or 1? Similarly, are the joystick buttons numbered from 0 or 1?

Best way to identify them is to got to the FSUIPC Buttons page, and use it to pretend to program the buttons. When you press a button, the Joystick number and Button number will show on that page.

Pete

[Jamie Fox]

Thanks very much Pete. All the problems I was experiencing were due to my own mistakes in some of the programming. It all seems to work fine now.

What happens if I provide an incorrectly-sized variable to FSUIPC. For example, if I was to call FSUIPC_Write(0x1234, 1,...) but write it to a DWORD. Will FSUIPC just take the lowest (least significant) byte? Similarly, what if I try to read four bytes to a BYTE? Presumably FSUIPC, knowing only of a pointer, will try to write to a memory address allocated to something else, probably causing a crash?

[Pete Dowson]

What happens if I provide an incorrectly-sized variable to FSUIPC. For example, if I was to call FSUIPC_Write(0x1234, 1,...) but write it to a DWORD. Will FSUIPC just take the lowest (least significant) byte? Similarly, what if I try to read four bytes to a BYTE? Presumably FSUIPC, knowing only of a pointer, will try to write to a memory address allocated to something else, probably causing a crash?

Writing 1 byte from a row of bytes will only write the first byte, of course, as you surmised.

Reading N bytes into any area in your program where you've only reserved N-1 or less bytes for the data will overwrite whatever follows. If the data area is on the Heap is could result in errors or crashes later, with heap links destroyed. If the data is declared globally or as "static" then it will again overwrite whatever follows it, which may be difficult to determine (look at a ".Map" file if your compiler provides one). If the data area is dynamic (i.e. declared locally in a procedure or subsection of code), then it is on the stack, and the extra bytes will overwrite other values and even possibly the return address for the procedure, so causing a crash later, when the procedure exits.

All these things would be the same if you read more data from any source, for instance a file, into an area not big enough. None of it is specific to FSUIPC.

Regards,

Pete

[Jamie Fox]

Thanks for all your help. It makes a lot more sense now.