hello:
i am a very newer .i come here first
i write a pcx progam with in win32asm.i hope know about programer with in winasm and make friend.i am poor
now but i very want write program with in win32asm . i dont why,
best regard your every one
Posted on 2003-04-20 09:14:14 by bgcq007
Err do you mind explaining how to use your work? There is no executable in the file.

What exactly are you loading and saving, and why? :confused:

:NaN:
Posted on 2003-04-20 09:34:43 by NaN
Nice work :)
He's loading and saving bmp,jpg,gif, tif, pcx and png files, as well as scaling , rotating and blah, a file format converter and image editor without libsupport = NICE WORK DUDE :)
I don't care that you are poor.
Most programmers STAY poor !!! :tongue:
Your source may be a bit messy but I think you show talent.
Posted on 2003-04-21 07:17:39 by Homer
i only encode and decode pcx.i want to work about gif,tif and jpg.
i write some common in chinese,later, i will use in english replace.
run the compile ,it will make a img.exe program ,it need ml.exe link.exe.
hope to know some programer ,some friend.
Posted on 2003-04-21 23:50:49 by bgcq007

Nice work :)
He's loading and saving bmp,jpg,gif, tif, pcx and png files, as well as scaling , rotating and blah, a file format converter and image editor without libsupport = NICE WORK DUDE :)
I don't care that you are poor.
Most programmers STAY poor !!! :tongue:
Your source may be a bit messy but I think you show talent.


IF you think his code is messy you don't want to see mine :eek:
Posted on 2003-04-24 15:22:56 by x86asm
can anyone see the attachment in this post?  if not, does anyone have a pcx decoder source that returns a hbitmap?
Posted on 2007-04-09 18:58:54 by localmotion34
The attachments are gone, probably due to auto-pruning.

PCX decoding is pretty simple, shouldn't be hard to write some routine from a copy of the specs. Heck, even I was able to do it ~10 years ago :p
Posted on 2007-04-10 01:27:57 by f0dder
Anything prior to 2005, the attachments are probably missing, but this due to older website/database attacks on the older forum software.
Posted on 2007-04-10 01:53:00 by SpooK
localmotion34, is there any particular reason for you to use PCX? PNG is much better and it's supported by the GDI+, so you get PNG (de)compression with almost no effort -- about 10 lines of code in C++ to get a HBITMAP handle from a PNG/GIF/JPEG/TIFF image.
Posted on 2007-04-10 01:58:29 by ti_mo_n

localmotion34, is there any particular reason for you to use PCX? PNG is much better and it's supported by the GDI+, so you get PNG (de)compression with almost no effort -- about 10 lines of code in C++ to get a HBITMAP handle from a PNG/GIF/JPEG/TIFF image.


I am writing an image decoding package that deals with many, many formats.  i cant stand Freeimage because it takes 14 lines of code to load an image, which is a freeimage bitmap, and then convert it to a hbitmap for use with Windows.  i am writing decoders that load an image from a filename and always return a valid hbitmap. 

the PCX decoder isnt working so well for me.  i was just wodering of ahyone had actual win32 source that returned a hbitmap, and not just displayed it via VGA like all the examples out there already. 
Posted on 2007-04-10 06:32:38 by localmotion34
Do you need to support all the esoteric pcx additions, or just 8bpp palettized versions?
Posted on 2007-04-10 16:59:29 by f0dder
id like to be able to support most versions.  however, its the stupid RLE encoding that is killing me.  i cant seem to accurately decode each scanline and realign it into a bitmap correctly.  all i get is complete garbage for a bitmap. 

i think the variations of each PCX dont rely on differences in RLE encoding, but rather how many planes there are as well as if a palette is included or not.  i just need to get the scanlines decoded properly first.  if anyone can provide an example, im all ears. 
Posted on 2007-04-10 17:29:48 by localmotion34
Well, what I can dig up from my archives is some 100% undocumented crappy ~10 years old 16bit pascal-inline-assembly code, hardcoded for 320x200x8bpp, for your amusement:

procedure unpackpcx(var src,dst); assembler;
asm
  push ds
  cld
  xor cx,cx
  les di,dst
  lds si,src
  mov dx,64000
@mainloop:
  mov cl,ds:
  and cl,0c0h
  cmp cl,0c0h
  jz @compressed
  movsb
  dec dx
  jmp @next
@compressed:
  mov cl,ds:
  and cl,03fh
  sub dx,cx
  inc si
  lodsb
  rep stosb
@next:
  or dx,dx
  jnz @mainloop
@fin:
  pop ds
end;


...I know that this used to work ;). The scheme is pretty simple, anyway:


Scan line 0: RRR...
GGG...
BBB...
III...
Scan line 1: RRR...
GGG...
BBB...
III...
(etc.)

The encoding method is:

  FOR  each  byte,  X,  read from the file
IF the top two bits of X are  1's then
count = 6 lowest bits of X
data = next byte following X
ELSE
count = 1
data = X

(for 8bpp you obviously don't have R,G,B,I planes. The illustration just means that PCX encoding is line-based, and per line has the bitplanes separated and RLE encoded).
Posted on 2007-04-10 17:43:48 by f0dder