游程编码源代码

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了游程编码源代码相关的知识,希望对你有一定的参考价值。

求游程编码的 纯C 语言代码,VC的和C++的不要,快呀。急

必有后赏,我的积分全给他了
游程编码是用于数据压缩的一算法,

请各位兄弟看清本帖的内容及要求再回复,与此无干的东西就不要发上来了吧

这个...........楼上的诸位说的都是什么啊。今天刚好看到这个问题,把你的E-mail给我把,我有纯c的源码(RLC)。

算了,直接贴关键部分吧。这个有一点C++成分,很容易改的。
bool CompressRunLength(BYTE *pSrc, int nSrcLen, BYTE *&pDes, int &nDesLen, int nBitsPerSample, void* nRuns, int nRunCount, int nRunSize);
bool DecompressRunLength(BYTE *pSrc, int nSrcLen, BYTE *&pDes, int &nDesLen);

#define GetDWORD(buf,bit,mask) ((*(DWORD*)(((BYTE*)buf)+((bit)>>3)))>>((bit)&7)&(mask))
#define GetWORD(buf,bit,mask) ((*(WORD*)(((BYTE*)buf)+((bit)>>3)))>>((bit)&7)&(mask))

int GetBitCount(int n)

int nBitCount = 0;
while(n)
n >>= 1, nBitCount++;
return nBitCount;


int BinarySearch(void* pValue, int nVlaueSize, void* pArray, int nCount)

int nIndex, nResult, nStart = 0, nEnd = nCount-1;
while(nStart <= nEnd)

nIndex = (nEnd+nStart)/2;
if((nResult = memcmp((BYTE*)pArray+nIndex*nVlaueSize, pValue, nVlaueSize)) == 0)
return nIndex;
if(nResult > 0)
nEnd = nIndex-1;
else
nStart = nIndex+1;

return -1;


bool CompressRunLength(BYTE *pSrc, int nSrcLen, BYTE *&pDes, int &nDesLen, int nBitsPerSample, void* nRuns, int nRunCount, int nRunSize)

pDes = (BYTE*)malloc(nSrcLen*2);
memset(pDes, 0, nSrcLen*2);

nDesLen = sizeof(DWORD);
*(DWORD*)pDes = nSrcLen; // save source length
*(pDes+nDesLen++) = nBitsPerSample; // save bits per sample
*(pDes+nDesLen++) = nRunCount; // save runs count
*(pDes+nDesLen++) = nRunSize; // save run bytes
memcpy(pDes+nDesLen, nRuns, nRunCount*nRunSize); // save runs
nDesLen += nRunCount*nRunSize;
nDesLen <<= 3; // bytes to bits
if(nRunCount == 0)
nRunCount = 256, nRunSize = 1, nRuns = NULL;

int nBitsPerTypeIndex = GetBitCount(nRunCount-1);
int nMaxRunLength = (1 << nBitsPerSample)-1, nRunLength, nRunIndex, nByte = 0;
// loop in the source buffer
while(nByte < nSrcLen)
if((nRuns && (nRunIndex = BinarySearch(pSrc+nByte, nRunSize, nRuns, nRunCount)) != -1 &&
memcmp(pSrc+nByte+nRunSize, (BYTE*)nRuns+nRunIndex*nRunSize, nRunSize) == 0) ||
(!nRuns && (nRunIndex = *(pSrc+nByte)) == *(pSrc+nByte+1)))
// set bit to 1 to indicate type found
*(pDes+(nDesLen>>3)) |= 1 << (nDesLen&7);
*(DWORD*)(pDes+(++nDesLen>>3)) |= nRunIndex << (nDesLen&7);
nDesLen += nBitsPerTypeIndex;
// skip the two repeated runs
nByte += nRunSize*2;
// get run length - 2 (without the two repeated runs)
nRunLength = 0;
while(nRunLength < nMaxRunLength && nByte < nSrcLen &&
((nRuns && memcmp(pSrc+nByte, (BYTE*)nRuns+nRunIndex*nRunSize, nRunSize) == 0) || (!nRuns && (BYTE)nRunIndex == *(pSrc+nByte))))
nRunLength++, nByte += nRunSize;
// save run length and increment destination length by bits per sample
*(DWORD*)(pDes+(nDesLen>>3)) |= nRunLength << (nDesLen&7);
nDesLen += nBitsPerSample;

else // copy one byte
*(WORD*)(pDes+(++nDesLen>>3)) |= *(pSrc+nByte++) << (nDesLen&7), nDesLen += 8;
nDesLen = (nDesLen+7)/8; // bits to bytes
pDes = (BYTE*)realloc(pDes, nDesLen);

return true;


bool DecompressRunLength(BYTE *pSrc, int nSrcLen, BYTE *&pDes, int &nDesLen)

if(nSrcLen == 0)
return true;

// allocate destination buffer
nDesLen = *(DWORD*)pSrc;
pDes = (BYTE*)malloc(nDesLen);
memset(pDes, 0, nDesLen);

// copy compression information
int nSrcIndex = sizeof(DWORD);
int nBitsPerSample = *(pSrc+nSrcIndex++);
int nRunCount = *(pSrc+nSrcIndex++);
int nRunSize = *(pSrc+nSrcIndex++);
void* nRuns = pSrc+nSrcIndex;
nSrcIndex += nRunSize*nRunCount;
nSrcIndex <<= 3; // bytes to bits
if(nRunCount == 0)
nRunCount = 256, nRunSize = 1, nRuns = NULL;

int nBitsPerTypeIndex = GetBitCount(nRunCount-1);
int nMaxTypeIndex = (1 << nBitsPerTypeIndex)-1;
int nMaxRunLength = (1 << nBitsPerSample)-1;
int nDesIndex = 0, nRunLength, nRunIndex, nRun, nByte;

nSrcLen <<= 3; // bytes to bits
while(nSrcIndex < nSrcLen-8)
if((*(pSrc+(nSrcIndex>>3)) >> (nSrcIndex++&7)) & 1)

nRunIndex = GetDWORD(pSrc, nSrcIndex, nMaxTypeIndex), nSrcIndex += nBitsPerTypeIndex;
nRunLength = GetDWORD(pSrc, nSrcIndex, nMaxRunLength)+2, nSrcIndex += nBitsPerSample;
for(nRun = 0; nRun < nRunLength; nRun++)
for(nByte = 0; nByte < nRunSize; nByte++, nDesIndex += 8)
*(WORD*)(pDes+(nDesIndex>>3)) |= nRuns ? GetWORD(nRuns+nRunSize*nRunIndex, nByte<<3, 0xff) : (BYTE)nRunIndex;

else // copy one byte
*(WORD*)(pDes+(nDesIndex>>3)) |= GetWORD(pSrc, nSrcIndex, 0xff), nDesIndex += 8, nSrcIndex += 8;

return true;
参考技术A Graphics File Formats

This topic describes the graphics-file formats used by the Microsoft Windows
operating system. Graphics files include bitmap files, icon-resource files,
and cursor-resource files.

Bitmap-File Formats

Windows bitmap files are stored in a device-independent bitmap (DIB) format
that allows Windows to display the bitmap on any type of display device. The
term "device independent" means that the bitmap specifies pixel color in a
form independent of the method used by a display to represent color. The
default filename extension of a Windows DIB file is .BMP.

Bitmap-File Structures

Each bitmap file contains a bitmap-file header, a bitmap-information header,
a color table, and an array of bytes that defines the bitmap bits. The file
has the following form:

BITMAPFILEHEADER bmfh;
BITMAPINFOHEADER bmih;
RGBQUAD aColors[];
BYTE aBitmapBits[];

The bitmap-file header contains information about the type, size, and layout
of a device-independent bitmap file. The header is defined as a
BITMAPFILEHEADER structure.

The bitmap-information header, defined as a BITMAPINFOHEADER structure,
specifies the dimensions, compression type, and color format for the bitmap.

The color table, defined as an array of RGBQUAD structures, contains as many
elements as there are colors in the bitmap. The color table is not present
for bitmaps with 24 color bits because each pixel is represented by 24-bit
red-green-blue (RGB) values in the actual bitmap data area. The colors in the
table should appear in order of importance. This helps a display driver
render a bitmap on a device that cannot display as many colors as there are
in the bitmap. If the DIB is in Windows version 3.0 or later format, the
driver can use the biClrImportant member of the BITMAPINFOHEADER structure to
determine which colors are important.

The BITMAPINFO structure can be used to represent a combined
bitmap-information header and color table. The bitmap bits, immediately
following the color table, consist of an array of BYTE values representing
consecutive rows, or "scan lines," of the bitmap. Each scan line consists of
consecutive bytes representing the pixels in the scan line, in left-to-right
order. The number of bytes representing a scan line depends on the color
format and the width, in pixels, of the bitmap. If necessary, a scan line
must be zero-padded to end on a 32-bit boundary. However, segment boundaries
can appear anywhere in the bitmap. The scan lines in the bitmap are stored
from bottom up. This means that the first byte in the array represents the
pixels in the lower-left corner of the bitmap and the last byte represents
the pixels in the upper-right corner.

The biBitCount member of the BITMAPINFOHEADER structure determines the number
of bits that define each pixel and the maximum number of colors in the
bitmap. These members can have any of the following values:

Value Meaning

1 Bitmap is monochrome and the color table contains two entries. Each
bit in the bitmap array represents a pixel. If the bit is clear, the pixel is
displayed with the color of the first entry in the color table. If the bit is
set, the pixel has the color of the second entry in the table.

4 Bitmap has a maximum of 16 colors. Each pixel in the bitmap is
represented by a 4-bit index into the color table. For example, if the first
byte in the bitmap is 0x1F, the byte represents two pixels. The first pixel
contains the color in the second table entry, and the second pixel contains
the color in the sixteenth table entry.

8 Bitmap has a maximum of 256 colors. Each pixel in the bitmap is
represented by a 1-byte index into the color table. For example, if the first
byte in the bitmap is 0x1F, the first pixel has the color of the
thirty-second table entry.

24 Bitmap has a maximum of 2^24 colors. The bmiColors (or bmciColors)
member is NULL, and each 3-byte sequence in the bitmap array represents the
relative intensities of red, green, and blue, respectively, for a pixel.

The biClrUsed member of the BITMAPINFOHEADER structure specifies the number
of color indexes in the color table actually used by the bitmap. If the
biClrUsed member is set to zero, the bitmap uses the maximum number of colors
corresponding to the value of the biBitCount member. An alternative form of
bitmap file uses the BITMAPCOREINFO, BITMAPCOREHEADER, and RGBTRIPLE
structures.

Bitmap Compression

Windows versions 3.0 and later support run-length encoded (RLE) formats for
compressing bitmaps that use 4 bits per pixel and 8 bits per pixel.
Compression reduces the disk and memory storage required for a bitmap.

Compression of 8-Bits-per-Pixel Bitmaps

When the biCompression member of the BITMAPINFOHEADER structure is set to
BI_RLE8, the DIB is compressed using a run-length encoded format for a
256-color bitmap. This format uses two modes: encoded mode and absolute mode.
Both modes can occur anywhere throughout a single bitmap.

Encoded Mode

A unit of information in encoded mode consists of two bytes. The first byte
specifies the number of consecutive pixels to be drawn using the color index
contained in the second byte. The first byte of the pair can be set to zero
to indicate an escape that denotes the end of a line, the end of the bitmap,
or a delta. The interpretation of the escape depends on the value of the
second byte of the pair, which must be in the range 0x00 through 0x02.
Following are the meanings of the escape values that can be used in the
second byte:

Second byte Meaning

0 End of line.
1 End of bitmap.
2 Delta. The two bytes following the escape contain unsigned values
indicating the horizontal and vertical offsets of the next pixel from the
current position.

Absolute Mode

Absolute mode is signaled by the first byte in the pair being set to zero and
the second byte to a value between 0x03 and 0xFF. The second byte represents
the number of bytes that follow, each of which contains the color index of a
single pixel. Each run must be aligned on a word boundary. Following is an
example of an 8-bit RLE bitmap (the two-digit hexadecimal values in the
second column represent a color index for a single pixel):

Compressed data Expanded data

03 04 04 04 04
05 06 06 06 06 06 06
00 03 45 56 67 00 45 56 67
02 78 78 78
00 02 05 01 Move 5 right and 1 down
02 78 78 78
00 00 End of line
09 1E 1E 1E 1E 1E 1E 1E 1E 1E 1E
00 01 End of RLE bitmap

Compression of 4-Bits-per-Pixel Bitmaps

When the biCompression member of the BITMAPINFOHEADER structure is set to
BI_RLE4, the DIB is compressed using a run-length encoded format for a
16-color bitmap. This format uses two modes: encoded mode and absolute mode.

Encoded Mode

A unit of information in encoded mode consists of two bytes. The first byte
of the pair contains the number of pixels to be drawn using the color indexes
in the second byte.

The second byte contains two color indexes, one in its high-order nibble
(that is, its low-order 4 bits) and one in its low-order nibble.

The first pixel is drawn using the color specified by the high-order nibble,
the second is drawn using the color in the low-order nibble, the third is
drawn with the color in the high-order nibble, and so on, until all the
pixels specified by the first byte have been drawn.

The first byte of the pair can be set to zero to indicate an escape that
denotes the end of a line, the end of the bitmap, or a delta. The
interpretation of the escape depends on the value of the second byte of the
pair. In encoded mode, the second byte has a value in the range 0x00 through
0x02. The meaning of these values is the same as for a DIB with 8 bits per
pixel.

Absolute Mode

In absolute mode, the first byte contains zero, the second byte contains the
number of color indexes that follow, and subsequent bytes contain color
indexes in their high- and low-order nibbles, one color index for each pixel.
Each run must be aligned on a word boundary.

Following is an example of a 4-bit RLE bitmap (the one-digit hexadecimal
values in the second column represent a color index for a single pixel):

Compressed data Expanded data

03 04 0 4 0
05 06 0 6 0 6 0
00 06 45 56 67 00 4 5 5 6 6 7
04 78 7 8 7 8
00 02 05 01 Move 5 right and 1 down
04 78 7 8 7 8
00 00 End of line
09 1E 1 E 1 E 1 E 1 E 1
00 01 End of RLE bitmap

Bitmap Example

The following example is a text dump of a 16-color bitmap (4 bits per pixel):

Win3DIBFile
BitmapFileHeader
Type 19778
Size 3118
Reserved1 0
Reserved2 0
OffsetBits 118
BitmapInfoHeader
Size 40
Width 80
Height 75
Planes 1
BitCount 4
Compression 0
SizeImage 3000

XPelsPerMeter 0
YPelsPerMeter 0
ColorsUsed 16
ColorsImportant 16
Win3ColorTable
Blue Green Red Unused
[00000000] 84 252 84 0
[00000001] 252 252 84 0
[00000002] 84 84 252 0
[00000003] 252 84 252 0
[00000004] 84 252 252 0
[00000005] 252 252 252 0
[00000006] 0 0 0 0
[00000007] 168 0 0 0
[00000008] 0 168 0 0
[00000009] 168 168 0 0
[0000000A] 0 0 168 0
[0000000B] 168 0 168 0
[0000000C] 0 168 168 0
[0000000D] 168 168 168 0
[0000000E] 84 84 84 0
[0000000F] 252 84 84 0
Image
.
. Bitmap data
.

Icon-Resource File Format

An icon-resource file contains image data for icons used by Windows
applications. The file consists of an icon directory identifying the number
and types of icon images in the file, plus one or more icon images. The
default filename extension for an icon-resource file is .ICO.

Icon Directory

Each icon-resource file starts with an icon directory. The icon directory,
defined as an ICONDIR structure, specifies the number of icons in the
resource and the dimensions and color format of each icon image. The ICONDIR
structure has the following form:

typedef struct ICONDIR
WORD idReserved;
WORD idType;
WORD idCount;
ICONDIRENTRY idEntries[1];
ICONHEADER;

Following are the members in the ICONDIR structure:

idReserved Reserved; must be zero.
idType Specifies the resource type. This member is set to 1.
idCount Specifies the number of entries in the directory.
idEntries Specifies an array of ICONDIRENTRY structures containing
information about individual icons. The idCount member specifies the number
of structures in the array.

The ICONDIRENTRY structure specifies the dimensions and color format for an
icon. The structure has the following form:

struct IconDirectoryEntry
BYTE bWidth;
BYTE bHeight;
BYTE bColorCount;
BYTE bReserved;
WORD wPlanes;
WORD wBitCount;
DWORD dwBytesInRes;
DWORD dwImageOffset;
;

Following are the members in the ICONDIRENTRY structure:

bWidth Specifies the width of the icon, in pixels. Acceptable values
are 16, 32, and 64.

bHeight Specifies the height of the icon, in pixels. Acceptable
values are 16, 32, and 64.

bColorCount Specifies the number of colors in the icon. Acceptable values
are 2, 8, and 16.

bReserved Reserved; must be zero.
wPlanes Specifies the number of color planes in the icon bitmap.
wBitCount Specifies the number of bits in the icon bitmap.
dwBytesInRes Specifies the size of the resource, in bytes.
dwImageOffset Specifies the offset, in bytes, from the beginning of the
file to the icon image.

Icon Image

Each icon-resource file contains one icon image for each image identified in
the icon directory. An icon image consists of an icon-image header, a color
table, an XOR mask, and an AND mask. The icon image has the following form:

BITMAPINFOHEADER icHeader;
RGBQUAD icColors[];
BYTE icXOR[];
BYTE icAND[];

The icon-image header, defined as a BITMAPINFOHEADER structure, specifies the
dimensions and color format of the icon bitmap. Only the biSize through
biBitCount members and the biSizeImage member are used. All other members
(such as biCompression and biClrImportant) must be set to zero.

The color table, defined as an array of RGBQUAD structures, specifies the
colors used in the XOR mask. As with the color table in a bitmap file, the
biBitCount member in the icon-image header determines the number of elements
in the array. For more information about the color table, see Section 1.1,
"Bitmap-File Formats."

The XOR mask, immediately following the color table, is an array of BYTE
values representing consecutive rows of a bitmap. The bitmap defines the
basic shape and color of the icon image. As with the bitmap bits in a bitmap
file, the bitmap data in an icon-resource file is organized in scan lines,
with each byte representing one or more pixels, as defined by the color
format. For more information about these bitmap bits, see Section 1.1,
"Bitmap-File Formats."

The AND mask, immediately following the XOR mask, is an array of BYTE values,
representing a monochrome bitmap with the same width and height as the XOR
mask. The array is organized in scan lines, with each byte representing 8
pixels.

When Windows draws an icon, it uses the AND and XOR masks to combine the icon
image with the pixels already on the display surface. Windows first applies
the AND mask by using a bitwise AND operation; this preserves or removes
existing pixel color. Windows then applies the XOR mask by using a bitwise
XOR operation. This sets the final color for each pixel.

The following illustration shows the XOR and AND masks that create a
monochrome icon (measuring 8 pixels by 8 pixels) in the form of an uppercase
K:

Windows Icon Selection

Windows detects the resolution of the current display and matches it against
the width and height specified for each version of the icon image. If Windows
determines that there is an exact match between an icon image and the current
device, it uses the matching image. Otherwise, it selects the closest match
and stretches the image to the proper size.

If an icon-resource file contains more than one image for a particular
resolution, Windows uses the icon image that most closely matches the color
capabilities of the current display. If no image matches the device
capabilities exactly, Windows selects the image that has the greatest number
of colors without exceeding the number of display colors. If all images
exceed the color capabilities of the current display, Windows uses the icon
image with the least number of colors.

Cursor-Resource File Format

A cursor-resource file contains image data for cursors used by Windows
applications. The file consists of a cursor directory identifying the number
and types of cursor images in the file, plus one or more cursor images. The
default filename extension for a cursor-resource file is .CUR.

Cursor Directory

Each cursor-resource file starts with a cursor directory. The cursor
directory, defined as a CURSORDIR structure, specifies the number of cursors
in the file and the dimensions and color format of each cursor image. The
CURSORDIR structure has the following form:

typedef struct _CURSORDIR
WORD cdReserved;
WORD cdType;
WORD cdCount;
CURSORDIRENTRY cdEntries[];
CURSORDIR;

Following are the members in the CURSORDIR structure:

cdReserved Reserved; must be zero.
cdType Specifies the resource type. This member must be set to 2.
cdCount Specifies the number of cursors in the file.
cdEntries Specifies an array of CURSORDIRENTRY structures containing
information about individual cursors. The cdCount member specifies the number
of structures in the array.

A CURSORDIRENTRY structure specifies the dimensions and color format of a
cursor image. The structure has the following form:

typedef struct _CURSORDIRENTRY
BYTE bWidth;
BYTE bHeight;
BYTE bColorCount;
BYTE bReserved;
WORD wXHotspot;
WORD wYHotspot;
DWORD lBytesInRes;
DWORD dwImageOffset;
CURSORDIRENTRY;

Following are the members in the CURSORDIRENTRY structure:

bWidth Specifies the width of the cursor, in pixels.
bHeight Specifies the height of the cursor, in pixels.
bColorCount Reserved; must be zero.
bReserved Reserved; must be zero.
wXHotspot Specifies the x-coordinate, in pixels, of the hot spot.
wYHotspot Specifies the y-coordinate, in pixels, of the hot spot.
lBytesInRes Specifies the size of the resource, in bytes.
dwImageOffset Specifies the offset, in bytes, from the start of the file to
the cursor image.

Cursor Image

Each cursor-resource file contains one cursor image for each image identified
in the cursor directory. A cursor image consists of a cursor-image header, a
color table, an XOR mask, and an AND mask. The cursor image has the following
form:

BITMAPINFOHEADER crHeader;
RGBQUAD crColors[];
BYTE crXOR[];
BYTE crAND[];

The cursor hot spot is a single pixel in the cursor bitmap that Windows uses
to track the cursor. The crXHotspot and crYHotspot members specify the x- and
y-coordinates of the cursor hot spot. These coordinates are 16-bit integers.

The cursor-image header, defined as a BITMAPINFOHEADER structure, specifies
the dimensions and color format of the cursor bitmap. Only the biSize through
biBitCount members and the biSizeImage member are used. The biHeight member
specifies the combined height of the XOR and AND masks for the cursor. This
value is twice the height of the XOR mask. The biPlanes and biBitCount
members must be 1. All other members (such as biCompression and
biClrImportant) must be set to zero.

The color table, defined as an array of RGBQUAD structures, specifies the
colors used in the XOR mask. For a cursor image, the table contains exactly
two structures, since the biBitCount member in the cursor-image header is
always 1.

The XOR mask, immediately following the color table, is an array of BYTE
values representing consecutive rows of a bitmap. The bitmap defines the
basic shape and color of the cursor image. As with the bitmap bits in a
bitmap file, the bitmap data in a cursor-resource file is organized in scan
lines, with each byte representing one or more pixels, as defined by the
color format. For more information about these bitmap bits, see Section 1.1,
"Bitmap-File Formats."

The AND mask, immediately following the XOR mask, is an array of BYTE values
representing a monochrome bitmap with the same width and height as the XOR
mask. The array is organized in scan lines, with each byte representing 8

参考资料:http://www.china-askpro.com/download/bmp.zip

参考技术B 这个是吃豆子的游戏!(用c语言编写的啊)
#include<stdio.h>
#include<dos.h>
#include<graphics.h>
#include<stdlib.h>
#define UP 0x48
#define DOWN 0x50
#define LEFT 0x4b
#define RIGHT 0x4d
#define SPACE 0x39
#define ENTER 0x1c
#define ESC 0x1
#define SW 60
#define SL 20
#define Gsize 20
#define S 0
#define X 1
#define Z 2
#define Y 3

typedef struct SN
int x;
int y;
int direction;
struct SN *next;
SNAKE;

SNAKE *tail;
int rank=0;
int grilled[21][16]=0;
unsigned size,size1;
void *buffer,*buffer1;

void interrupt (*oldtime)();
void interrupt newtime();
void install(void interrupt (*haddr)());

int timer=0;

int getkey()

union REGS rg;
rg.h.ah=0;
int86(0x16,&rg,&rg);
return rg.h.ah;


SNAKE *initmainwindow()

int i,j,k;
SNAKE *p,*w;
for(i=0;i<20;i++)

grilled[0]=1;
grilled[15]=1;

for(j=0;j<16;j++)

grilled[0][j]=1;
grilled[20][j]=1;

rectangle(SW+20,SL+20,SW+300,SL+400);
rectangle(SW+19,SL+19,SW+299,SL+399);
rectangle(SW+Gsize*6,SL+Gsize*6,SW+Gsize*6+20,SL+Gsize*6+20);
bar(SW+Gsize*6+2,SL+Gsize*6+2,SW+Gsize*6+18,SL+Gsize*6+18);
size=imagesize(SW+Gsize*6,SL+Gsize*6,SW+Gsize*6+20,SL+Gsize*6+20);
buffer=malloc(size);
getimage(SW+Gsize*6,SL+Gsize*6,SW+Gsize*6+20,SL+Gsize*6+20,buffer);

for(k=1;k<3;k++)

putimage(SW+Gsize*6,SL+Gsize*(6+k),buffer,XOR_PUT);
grilled[6+k][6]=1;


w=NULL;
for(k=2;k>=0;k--)

p=(SNAKE *)malloc(sizeof(SNAKE));
p->x=6;p->y=6+k;
p->direction=S;
p->next=w;
w=p;

rectangle(SW+Gsize*2,SL+Gsize*4,SW+Gsize*2+15,SL+Gsize*4+15);
rectangle(SW+Gsize*2+2,SL+Gsize*4+2,SW+Gsize*2+13,SL+Gsize*4+13);
grilled[4][2]=2;

size1=imagesize(SW+Gsize*2,SL+Gsize*4,SW+Gsize*2+15,SL+Gsize*4+15);
buffer1=malloc(size1);
getimage(SW+Gsize*2,SL+Gsize*4,SW+Gsize*2+15,SL+Gsize*4+15,buffer1);

return w;


int main()

int driver=VGA,mode=VGAHI;
char key;
tail=NULL;
initgraph(&driver,&mode,"");
randomize();
tail=initmainwindow();
oldtime=getvect(0x1c);
while(1)

key=getkey();
switch(key)

case UP :
tail->direction=S;break;
case DOWN:
tail->direction=X;break;
case LEFT:
tail->direction=Z;break;
case RIGHT:
tail->direction=Y;break;

case ESC: closegraph();exit(1);
case SPACE :install(oldtime);break;
case ENTER :install(newtime);break;




void interrupt newtime()

int xx=1,yy=1;
char s[4];
SNAKE *p,*pend,*pp;
p=(SNAKE *)malloc(sizeof(SNAKE));
p->next=NULL;
if(timer++==3)

timer=0;
switch(tail->direction)

case S: if(grilled[tail->y-1][tail->x]==1) exit(1);
p->x=tail->x;p->y=tail->y-1;p->direction=tail->direction;p->next=NULL;
break;
case X: if(grilled[tail->y+1][tail->x]==1) exit(1);
p->x=tail->x;p->y=tail->y+1;p->direction=tail->direction;p->next=NULL;
break;
case Z: if(grilled[tail->y][tail->x-1]==1) exit(1);
p->x=tail->x-1;p->y=tail->y;p->direction=tail->direction;p->next=NULL;
break;
case Y: if(grilled[tail->y][tail->x+1]==1) exit(1);
p->x=tail->x+1;p->y=tail->y;p->direction=tail->direction;p->next=NULL;
break;


if(grilled[p->y][p->x]==2)

putimage(SW+Gsize*(p->x),SL+Gsize*(p->y),buffer1,XOR_PUT);
putimage(SW+Gsize*(p->x),SL+Gsize*(p->y),buffer,XOR_PUT);
grilled[p->y][p->x]=1;
p->next=tail;
tail=p;
rank++;
bar(375,390,400,420);
sprintf(s,"%d",rank);
setcolor(GREEN);
outtextxy(380,400,s);
do
xx=random(14)+1;yy=random(19)+1;
while((grilled[yy][xx]==1)||grilled[yy][xx]==2);
grilled[yy][xx]=2;
putimage(SW+Gsize*xx,SL+Gsize*yy,buffer1,XOR_PUT);


else

putimage(SW+Gsize*(p->x),SL+Gsize*(p->y),buffer,XOR_PUT);
grilled[p->y][p->x]=1;
p->next=tail;
tail=p;
pend=tail;
while(pend->next) pp=pend;pend=pend->next;
putimage(SW+Gsize*(pend->x),SL+Gsize*(pend->y),buffer,XOR_PUT);
grilled[pend->y][pend->x]=0;
pp->next=NULL;





void install(void interrupt (*hadder)())

disable();
setvect(0x1c,hadder);
enable();
参考技术C 这个...........楼上的诸位说的都是什么啊。今天刚好看到这个问题,把你的E-mail给我把,我有纯c的源码(RLC)。
算了,直接贴关键部分吧。这个有一点C++成分,很容易改的。
bool
CompressRunLength(BYTE
*pSrc,
int
nSrcLen,
BYTE
*&pDes,
int
&nDesLen,
int
nBitsPerSample,
void*
nRuns,
int
nRunCount,
int
nRunSize);
bool
DecompressRunLength(BYTE
*pSrc,
int
nSrcLen,
BYTE
*&pDes,
int
&nDesLen);
#define
GetDWORD(buf,bit,mask)
((*(DWORD*)(((BYTE*)buf)+((bit)>>3)))>>((bit)&7)&(mask))
#define
GetWORD(buf,bit,mask)
((*(WORD*)(((BYTE*)buf)+((bit)>>3)))>>((bit)&7)&(mask))
int
GetBitCount(int
n)

int
nBitCount
=
0;
while(n)
n
>>=
1,
nBitCount++;
return
nBitCount;

int
BinarySearch(void*
pValue,
int
nVlaueSize,
void*
pArray,
int
nCount)

int
nIndex,
nResult,
nStart
=
0,
nEnd
=
nCount-1;
while(nStart
<=
nEnd)

nIndex
=
(nEnd+nStart)/2;
if((nResult
=
memcmp((BYTE*)pArray+nIndex*nVlaueSize,
pValue,
nVlaueSize))
==
0)
return
nIndex;
if(nResult
>
0)
nEnd
=
nIndex-1;
else
nStart
=
nIndex+1;

return
-1;

bool
CompressRunLength(BYTE
*pSrc,
int
nSrcLen,
BYTE
*&pDes,
int
&nDesLen,
int
nBitsPerSample,
void*
nRuns,
int
nRunCount,
int
nRunSize)

pDes
=
(BYTE*)malloc(nSrcLen*2);
memset(pDes,
0,
nSrcLen*2);
nDesLen
=
sizeof(DWORD);
*(DWORD*)pDes
=
nSrcLen;
//
save
source
length
*(pDes+nDesLen++)
=
nBitsPerSample;
//
save
bits
per
sample
*(pDes+nDesLen++)
=
nRunCount;
//
save
runs
count
*(pDes+nDesLen++)
=
nRunSize;
//
save
run
bytes
memcpy(pDes+nDesLen,
nRuns,
nRunCount*nRunSize);
//
save
runs
nDesLen
+=
nRunCount*nRunSize;
nDesLen
<<=
3;
//
bytes
to
bits
if(nRunCount
==
0)
nRunCount
=
256,
nRunSize
=
1,
nRuns
=
NULL;
int
nBitsPerTypeIndex
=
GetBitCount(nRunCount-1);
int
nMaxRunLength
=
(1
<<
nBitsPerSample)-1,
nRunLength,
nRunIndex,
nByte
=
0;
//
loop
in
the
source
buffer
while(nByte
<
nSrcLen)
if((nRuns
&&
(nRunIndex
=
BinarySearch(pSrc+nByte,
nRunSize,
nRuns,
nRunCount))
!=
-1
&&
memcmp(pSrc+nByte+nRunSize,
(BYTE*)nRuns+nRunIndex*nRunSize,
nRunSize)
==
0)
||
(!nRuns
&&
(nRunIndex
=
*(pSrc+nByte))
==
*(pSrc+nByte+1)))

//
set
bit
to
1
to
indicate
type
found
*(pDes+(nDesLen>>3))
|=
1
<<
(nDesLen&7);
*(DWORD*)(pDes+(++nDesLen>>3))
|=
nRunIndex
<<
(nDesLen&7);
nDesLen
+=
nBitsPerTypeIndex;
//
skip
the
two
repeated
runs
nByte
+=
nRunSize*2;
//
get
run
length
-
2
(without
the
two
repeated
runs)
nRunLength
=
0;
while(nRunLength
<
nMaxRunLength
&&
nByte
<
nSrcLen
&&
((nRuns
&&
memcmp(pSrc+nByte,
(BYTE*)nRuns+nRunIndex*nRunSize,
nRunSize)
==
0)
||
(!nRuns
&&
(BYTE)nRunIndex
==
*(pSrc+nByte))))
nRunLength++,
nByte
+=
nRunSize;
//
save
run
length
and
increment
destination
length
by
bits
per
sample
*(DWORD*)(pDes+(nDesLen>>3))
|=
nRunLength
<<
(nDesLen&7);
nDesLen
+=
nBitsPerSample;

else
//
copy
one
byte
*(WORD*)(pDes+(++nDesLen>>3))
|=
*(pSrc+nByte++)
<<
(nDesLen&7),
nDesLen
+=
8;
nDesLen
=
(nDesLen+7)/8;
//
bits
to
bytes
pDes
=
(BYTE*)realloc(pDes,
nDesLen);
return
true;

bool
DecompressRunLength(BYTE
*pSrc,
int
nSrcLen,
BYTE
*&pDes,
int
&nDesLen)

if(nSrcLen
==
0)
return
true;
//
allocate
destination
buffer
nDesLen
=
*(DWORD*)pSrc;
pDes
=
(BYTE*)malloc(nDesLen);
memset(pDes,
0,
nDesLen);
//
copy
compression
information
int
nSrcIndex
=
sizeof(DWORD);
int
nBitsPerSample
=
*(pSrc+nSrcIndex++);
int
nRunCount
=
*(pSrc+nSrcIndex++);
int
nRunSize
=
*(pSrc+nSrcIndex++);
void*
nRuns
=
pSrc+nSrcIndex;
nSrcIndex
+=
nRunSize*nRunCount;
nSrcIndex
<<=
3;
//
bytes
to
bits
if(nRunCount
==
0)
nRunCount
=
256,
nRunSize
=
1,
nRuns
=
NULL;
int
nBitsPerTypeIndex
=
GetBitCount(nRunCount-1);
int
nMaxTypeIndex
=
(1
<<
nBitsPerTypeIndex)-1;
int
nMaxRunLength
=
(1
<<
nBitsPerSample)-1;
int
nDesIndex
=
0,
nRunLength,
nRunIndex,
nRun,
nByte;
nSrcLen
<<=
3;
//
bytes
to
bits
while(nSrcIndex
<
nSrcLen-8)
if((*(pSrc+(nSrcIndex>>3))
>>
(nSrcIndex++&7))
&
1)

nRunIndex
=
GetDWORD(pSrc,
nSrcIndex,
nMaxTypeIndex),
nSrcIndex
+=
nBitsPerTypeIndex;
nRunLength
=
GetDWORD(pSrc,
nSrcIndex,
nMaxRunLength)+2,
nSrcIndex
+=
nBitsPerSample;
for(nRun
=
0;
nRun
<
nRunLength;
nRun++)
for(nByte
=
0;
nByte
<
nRunSize;
nByte++,
nDesIndex
+=
8)
*(WORD*)(pDes+(nDesIndex>>3))
|=
nRuns
?
GetWORD(nRuns+nRunSize*nRunIndex,
nByte<<3,
0xff)
:
(BYTE)nRunIndex;

else
//
copy
one
byte
*(WORD*)(pDes+(nDesIndex>>3))
|=
GetWORD(pSrc,
nSrcIndex,
0xff),
nDesIndex
+=
8,
nSrcIndex
+=
8;
return
true;
参考技术D #include<stdio.h>
#include<dos.h>
#include<graphics.h>
#include<stdlib.h>
#define UP 0x48
#define DOWN 0x50
#define LEFT 0x4b
#define RIGHT 0x4d
#define SPACE 0x39
#define ENTER 0x1c
#define ESC 0x1
#define SW 60
#define SL 20
#define Gsize 20
#define S 0
#define X 1
#define Z 2
#define Y 3

typedef struct SN
int x;
int y;
int direction;
struct SN *next;
SNAKE;

SNAKE *tail;
int rank=0;
int grilled[21][16]=0;
unsigned size,size1;
void *buffer,*buffer1;

void interrupt (*oldtime)();
void interrupt newtime();
void install(void interrupt (*haddr)());

int timer=0;

int getkey()

union REGS rg;
rg.h.ah=0;
int86(0x16,&rg,&rg);
return rg.h.ah;


SNAKE *initmainwindow()

int i,j,k;
SNAKE *p,*w;
for(i=0;i<20;i++)

grilled[0]=1;
grilled[15]=1;

for(j=0;j<16;j++)

grilled[0][j]=1;
grilled[20][j]=1;

rectangle(SW+20,SL+20,SW+300,SL+400);
rectangle(SW+19,SL+19,SW+299,SL+399);
rectangle(SW+Gsize*6,SL+Gsize*6,SW+Gsize*6+20,SL+Gsize*6+20);
bar(SW+Gsize*6+2,SL+Gsize*6+2,SW+Gsize*6+18,SL+Gsize*6+18);
size=imagesize(SW+Gsize*6,SL+Gsize*6,SW+Gsize*6+20,SL+Gsize*6+20);
buffer=malloc(size);
getimage(SW+Gsize*6,SL+Gsize*6,SW+Gsize*6+20,SL+Gsize*6+20,buffer);

for(k=1;k<3;k++)

putimage(SW+Gsize*6,SL+Gsize*(6+k),buffer,XOR_PUT);
grilled[6+k][6]=1;


w=NULL;
for(k=2;k>=0;k--)

p=(SNAKE *)malloc(sizeof(SNAKE));
p->x=6;p->y=6+k;
p->direction=S;
p->next=w;
w=p;

rectangle(SW+Gsize*2,SL+Gsize*4,SW+Gsize*2+15,SL+Gsize*4+15);
rectangle(SW+Gsize*2+2,SL+Gsize*4+2,SW+Gsize*2+13,SL+Gsize*4+13);
grilled[4][2]=2;

size1=imagesize(SW+Gsize*2,SL+Gsize*4,SW+Gsize*2+15,SL+Gsize*4+15);
buffer1=malloc(size1);
getimage(SW+Gsize*2,SL+Gsize*4,SW+Gsize*2+15,SL+Gsize*4+15,buffer1);

return w;


int main()

int driver=VGA,mode=VGAHI;
char key;
tail=NULL;
initgraph(&driver,&mode,"");
randomize();
tail=initmainwindow();
oldtime=getvect(0x1c);
while(1)

key=getkey();
switch(key)

case UP :
tail->direction=S;break;
case DOWN:
tail->direction=X;break;
case LEFT:
tail->direction=Z;break;
case RIGHT:
tail->direction=Y;break;

case ESC: closegraph();exit(1);
case SPACE :install(oldtime);break;
case ENTER :install(newtime);break;




void interrupt newtime()

int xx=1,yy=1;
char s[4];
SNAKE *p,*pend,*pp;
p=(SNAKE *)malloc(sizeof(SNAKE));
p->next=NULL;
if(timer++==3)

timer=0;
switch(tail->direction)

case S: if(grilled[tail->y-1][tail->x]==1) exit(1);
p->x=tail->x;p->y=tail->y-1;p->direction=tail->direction;p->next=NULL;
break;
case X: if(grilled[tail->y+1][tail->x]==1) exit(1);
p->x=tail->x;p->y=tail->y+1;p->direction=tail->direction;p->next=NULL;
break;
case Z: if(grilled[tail->y][tail->x-1]==1) exit(1);
p->x=tail->x-1;p->y=tail->y;p->direction=tail->direction;p->next=NULL;
break;
case Y: if(grilled[tail->y][tail->x+1]==1) exit(1);
p->x=tail->x+1;p->y=tail->y;p->direction=tail->direction;p->next=NULL;
break;


if(grilled[p->y][p->x]==2)

putimage(SW+Gsize*(p->x),SL+Gsize*(p->y),buffer1,XOR_PUT);
putimage(SW+Gsize*(p->x),SL+Gsize*(p->y),buffer,XOR_PUT);
grilled[p->y][p->x]=1;
p->next=tail;
tail=p;
rank++;
bar(375,390,400,420);
sprintf(s,"%d",rank);
setcolor(GREEN);
outtextxy(380,400,s);
do
xx=random(14)+1;yy=random(19)+1;
while((grilled[yy][xx]==1)||grilled[yy][xx]==2);
grilled[yy][xx]=2;
putimage(SW+Gsize*xx,SL+Gsize*yy,buffer1,XOR_PUT);


else

putimage(SW+Gsize*(p->x),SL+Gsize*(p->y),buffer,XOR_PUT);
grilled[p->y][p->x]=1;
p->next=tail;
tail=p;
pend=tail;
while(pend->next) pp=pend;pend=pend->next;
putimage(SW+Gsize*(pend->x),SL+Gsize*(pend->y),buffer,XOR_PUT);
grilled[pend->y][pend->x]=0;
pp->next=NULL;





void install(void interrupt (*hadder)())

disable();
setvect(0x1c,hadder);
enable();

算法题:RLE压缩算法(游程编码)的Java实现

RLE全称run-length encoding,又称为游程编码,或者长度编码变动长度编码法run coding)。例如,我们输入字符串"qwweeerrrrttttt",经过压缩之后的输出结果应该为"1q2w3e4r5t"。
以下分别使用Java递归和尾递归的方式来实现。

  • 递归方式实现
    public static String RLECompress(String source) 
        if (source.length() <= 1) return source;

        int runLength = 1;
        while (runLength < source.length() && source.charAt(0) == source.charAt(runLength)) 
            runLength++;
        

        return runLength + source.substring(0, 1) + RLECompress(source.substring(runLength));
    
  • 尾递归方式实现
    public static String RLECompressWithTail(String source, String result) 
        if (source.length() <= 0) return result;

        int runLength = 1;
        while (runLength < source.length() && source.charAt(0) == source.charAt(runLength)) 
            runLength++;
        
        result += runLength + source.substring(0, 1);
        return  RLECompressWithTail(source.substring(runLength), result);
    

参考
//http://www.6tie.net/p/908340.html

以上是关于游程编码源代码的主要内容,如果未能解决你的问题,请参考以下文章

二值信息隐藏(分块和游程编码实现)

游程编码问题

算法科普:有趣的游程编码

模式游程编码

算法题:RLE压缩算法(游程编码)的Java实现

算法题:RLE压缩算法(游程编码)的Java实现