TiledGGD (PE)

[puggsoy]

TiledGGD (PE), which stands for Puggsoy Edit, is a fork of Barubary's TiledGGD program.

I decided to make this after realising that TiledGGD tended to mix up big and little-endian reading order. That is, it would read in little-endian when big-endian was selected, and vice versa. Generally this isn't an issue, it reads graphics fine and whether it's big or little endian is usually of no concern to the user. However when comparing one of my GFXtract scripts to the settings TGGD used to read a file, I noticed the discrepancy. This was a bit of an issue because one of my intentions was if someone figures out a format in TiledGGD they should be able to make a GFXtract script for it. However if they are told that the endianness is big, while it's actually little, this could cause confusion.

puggsoy wtf is an endian

For those who don't know, endianness is the order in which bits, or bytes, are to be read. Big-endian means from the most significant bit/byte to the least significant; little-endian means the other way around. Basically, little-endian is like reading it backwards.
(Note: All hexadecimal numbers are preceded with "0x")

Let me illustrate how it affects image reading. Suppose you have a 24-bit colour represented by 3 bytes which are 0xAE, 0x00, and 0x2C. In big-endian, you'd read this as 0xAE002C which, in RGB order converts to a sort of reddish pink. However, if you read it in little-endian, you'd read the bytes backwards, and it'd be 0x2C00AE. In RGB order this would become more of a blue.
You'll notice, the bytes themselves aren't read backwards, just the order of them. This is because we're reading colours, and as such the endianness simply affects the order of the channels, and not the channels themselves. Little-endian RGB is the exact same as big-endian BGR.

That's how it works for colours. But it also affects pixels. For instance if we're reading in 4bpp, each byte contains 2 pixels, as each pixel is half a byte. Because we're looking at parts of a byte, we need to determine which order to read the parts are read in. This is where endianness comes in again.
Say we have the byte 0x5B. In binary that's 0101 1011. If we read it in big-endian, the first pixel would be 0101 (0x05) and the second would be 1011 (0x0B). In little-endian, it'd be the other way around. So as you can see if you read a 4bpp image in the wrong endian, every pair of pixels would be swapped.

Don't worry if you don't fully understand it; this is just to give you an idea of what the hell I'm talking about.

Anyway, since Barubary hadn't touched it for some time and he hasn't been active on here in a while, I decided to take it upon myself. I forked his repository and made some changes to fix this, and you can download this new version here. It also includes a couple of fixes that Barubary himself made since the last public release (like improving and fixing 4bpc reading) and a stylish new icon.

I mainly did this for the endianness fix, but I might consider adding or improving features later on. I'm not extremely fluent in C# so it'd be a bit of a challenge, but I want to start using it eventually and taking up this project is a good opportunity to do so.
I should point out that this is just a fork and as such the majority of the code is still Barubary's, so he deserves most of the credit. I've just changed some stuff and made it a separate project so as to make it clear that this isn't an "official" version of TiledGGD.

Enjoy! Feel free to complain, comment, or ask questions here.