Sorry your browser is not supported!

i'm just testing the actual code out right now just to make sure it works insync with the Quake2 Palette...

in the mean time everyone have a gander over the format data i've put together. It is based closely upon the ZSofts actual PR one, however i've tried to make a few points across more easily hopefully to release some confusion over the format.
Feel free to develop your own, i'm just developing this for the MD2 importer which right now imports mesh, and i'm working on decoding the character names to setup a global skin count for each model - so out of the 32 made for it you can choose them with a number


PCX format is a simple RLE format created for use within the PC Paintbrush program.
This importer gives DarkBasic the support to import them with the intent to either use
within a game engine or to simply export them as an alternative format.
By no means is the FMTau importer perfect, and it is covered by the FreeSource™
Agreement - which means as long as you share the code or don't make a profit in
any form from what you rebuild you are allowed to use this code as a base.

If this isn't enough for some of you here is the PCX format header made simple for
DarkBasic use:

PCX Header 128 bytes
Byte Description Value Comment
0 Manufacturer 1-Byte *Byte 10 = ZSoft, See Below
1 Version 1-Byte *Byte See Below
2 Encoding 1-Byte *Byte 1 = Run Length Encoding (if you don't get this print an error!!)
3 BitPerPixel 1-Byte *Byte Bits to Represent a Pixel per Colour Plane - 1,2,4 or 8
4 Image Size 8-Byte *Word Image Dimensions Ymin,Xmin,Ymax,Xmax
12 Horizontal DPI 2-Byte *Word Horizontal Resolution DPI of PCX
14 Vertical DPI 2-Byte *Word Verticle Resolution DPI of PCX
16 Colour Map 48-Byte *Byte -- CGA Colour Palette See Below --
64 Reserved 1-Byte *Byte Default - 0
65 Planes 1-Byte *Byte Colour & Effect Planes
66 BytesPerLine 2-Byte *Word Bytes Per Scanline Plane, See Below !!MUST DIVIDE EVENLY BY 2!!
68 Palette Info 2-Byte *Word 1 - Black&White or Colour
2 - GreyScale
70 Horizontal Screen 2-Byte *Word Horizontal Screen Size in Pixels
72 Vertical Screen 2-Byte *Word Vertical Screen Size in Pixels
74 Unused 54-Byte *Free Makes up the 128byte Header

Manufacturer -
Now if the Manufacturer is 10, the means it is an official ZSoft format ...
however there are a few alteration versions out there, and if it is different
then the use of the Planes, Colours and Unused sectors maybe different.
It may not even be an RLE format anymore - so i'd check thier changes if different!

Version -
0 = Version 2.5 of PC Paintbrush
CGA
EGA
Greyscale
Monochrome
2 = Version 2.8 w/palette information
CGA
EGA
Greyscale
Monochrome
VGA - Palette included
3 = Version 2.8 w/o palette information
same as above except no palette is present, it is
a given that it is a global one used for a set of these
or standard palette
4 = PC Paintbrush for Windows(Plus for Windows uses Ver 5)
CGA
EGA
Greyscale
Monochrome
VGA - Palette included
5 = Version 3.0 and > of PC Paintbrush
EGA
Greyscale
Monochrome
VGA - Palette included
24Bit - No palette

Run Length Encoding -
For this the order in which the data is coded is
Scanline 0 : BytesPerLine * Plane 0 (Red)
BytesPerLine * Plane 1 (Green)
BytesPerLine * Plane 2 (Blue)
Scanline 1 : BytesPerLine * Plane 0 (Red)
BytesPerLine * Plane 1 (Green)
BytesPerLine * Plane 2 (Blue)
the Array required to set this up would be
dim PCXDATA(scanline,byteperpixel,planes)

think of the ScanLine as the Horizontal and the BytesPerLine as Vertical...
however as noted earlier BytesPerLine must be an even Number (don't ask me why i didn't dev this!)
so what if you're picture is an uneven number?
this means some bytes are unused data, if you want the actual picutres X,Y
you need to take the Xmax-Xmin ... we then add 1 (this is to offset the for...next playback)

Now onto the actual Pixel Plane Byte - these have been encoded to compress larger
counts of colour like so...
if the first two bits are 1, then the other 6 of the byte are 0
we check this with bitshifting like so

for line = 0 to TotalLines - 1
for pixel = 0 to TotalPixels - 1
for colour = 0 to TotalColours - 1
if Byte >> 1 = 1 and Byte >> 2 = 1
boolByte = 0
else
boolByte = 1
endif
if boolByte = 1 then writeByte = Byte
PCXDATA(line,pixel,colour) = writeByte
next colour
next pixel
next line

after this comes colour paletting...
it should be noted that for those formats with paletting abilities, they only actually palette
16,256,24bit colours
so what we do is first we check the BitsPerPixel

if BitsPerPixel =

stupid thing... nm about that just download the readme instead would be FAR easier

http://members.lycos.co.uk/timesaga/darkbasic/pcxread.txt

lol those code things are really for smaller bursts of text eh

oki... well version 1.0.0.a is kinda ready :?
i need to get a bug out, and its a biggie

now when you write to a memblock for an image, a pixel is a 2-Byte value which is a *word right?
or do i have to bitshift my value over 2 *Byte values?

i'll bb in lil while to check, but is kinda a pain in the ass - cause i keep getting a "server exception" when i try the "make image from memblock" command ... which tends to mean the data is setup wrong

might also be that it is in a function, but i hope not cause its taken hours to setup as is.

A PCX loader? I wrote one of those ages ago in DBV1 - it's on my personal site at http://www.darkforge.co.uk and worked quite nicely. This was back when we weren't able to load anything other than BMPs of course, today it's not needed so much

Nice format though.. simple, elegant. I used the graphics file format bible the "Encyclopedia of Graphics File Formats 2nd Edition" (O'Reilly Press) to get the header info from.

Cheers,

Rich

yeah i've kinda hit a snag with the memblocks not wanting to co-operate
pcx still isn't supported - and as i'd like my md2 importer's textures to well be imported rather than telling you what they should be, figured it was probably best to make a loader.
Once i'm done i'll add it to the image.lib.dba i have which currently has exporters to jpg,tga(w/alpha),dds and bmp

i've been over the math for the RGB command a thousand times, and i still can't remember howto get the values i need from bitshifting
been at this for several hours now, getting a lil frustrating

Not sure if this will help with the math or not, but it might do! Take a look? It's from my code that took a pixel colour off-screen and stuffed it into a memblock:



Cheers,

Rich

hmm... any chance of the actual math behind it?
just i'm trying to make this DarkBasic Enhanced compatible

See i remember from a good while ago that the memblocks used the 16bit High Colour 5-6-5 format but how i can achieve this has me a little baffled.
I'll keep going over what you just gave me, perhaps i'll think of something - annoying thing about this is that i've already got the thing exporting as PCX, JPG, Bitmap lol - just using these memblocks word of colour is annoying, value must be 0-65535 and i haven't a clue howto work that out ... sofar my net searchs have come up blank