The QB Times
Issue: 1
Contents:
Introduction
Welcome to the first issue of The QB Times. I'll try to make this magazine as
informative as possible with articles on all kinds of things like scripting,
on how to use different file formats in QBasic, assembly and all other kinds of things.
Also I'll do site reviews in The QB Times. Another item is projects; here I'll tell on updates from other programmer's projects and new
projects. In shorts I'll tell about the news from the QB world. I also do First Impressions
on upcoming projects and last but not least I've some people writing articles
for me! So, that's all for the introduction this time... Have fun with this issue!!
-Nightwolf
Projects
In this section there will be updates on QBasic programmers projects,
or new projects.
- Tek's RPG, Indigo Moon, is being recoded. Tek told us that
he has shops and spell casting done. The battle engine is going
to be next and then he'll add midi music.
- Tsugumo is working on a new project! It's called ThiefRPG.
- Viper and Marcade are working on a chat program called NemChat
it's made in VB 5.0; version 2 is out and available for download
on the Nemesis Software
page. Version 3 is still in the works and is delayed due to a bug!
- Marcade and Tomahawk are working on a new RPG! It doesn't have a new
yet. But the early screenshot I saw looked good. It ran at 300 FPS
at a PII 400, but it'll probably run on about 100 FPS on a normal computer.
Tomahawk originally started the game, but soon Marcade took over the
programming. Tomahawk is doing the graphics now. It will have SoundBlaster
music (either QMidi or BWSB), a good storyline and astonishing graphics.
The QB Times will keep you informed!
- BlackBird is working on a QB IDE for Windows, I saw an early screenshot
and it's really looking good! Check out BlackBird's Site for more info.
- Also BlackBird is working on a 3D object creator, I've seen a very beta version. Check my First Impressions
below.
- Dark Knight Software, the makers of DarkAges II, has released a demo of the engine. The way
the mouse is used to walk around is really good and original.
- Angelo Motolla & Petter Holmberg are working on a 3D game in QB; it's called Project RT.
I saw some early screenshots and it looked very good! It's also very fast.
- Danny Gump, creator of The Mystical Journey and Dash, told us that
he is going to recode his RPG, The Mystical Journey. He is going to redo
the battles and the engine and he'll be using the Dash 3D subs to
add 3D effects to the battles.
- Yoda and Caylo are working on Pokemon 2: Xenophobic Continuum. Here is a description of the project
which Yoda has written:
Pokemon 2: Xenophobic Continuum, once it is completed will be an advanced tile
game, with high adventure, obscure puzzles to solve, and many strange places to
explore. The raw power of the game engine and the limitless possibilities of
gameplay, along with the sparkling wonder of the graphics, will leave any
gameplayer wondering if this game was really programmed in simple QuickBasic. By
using an innovative technique, Pokemon 2: Xenophobic Continuum has virtually no
limits to the amount of tiles that can be used, giving the game a more appealing
look and feel. With powerful NPC scripting, the people you meet will seem as
alive as must of your friends or family. The player interface is highly
configurable, to allow the game to be played without the interface being in the
way. And with on the fly configurability, the player can set the way the game
plays, to best meet the speed of there computer. Unfortunately, Pokemon 2 is
still under development, with the development team working
hard to bring you this unique game. As of now, the game engine is 20%
complete, but you can still check the progress made on the game so far by
downloading the Pre-Alpha Demo release, which be available shortly at
www.quickbasic.com This very early demo shows the powerful NPC capabilities of
the Pokemon 2 engine. This Demo release also features a surprise appearance by
the venerable Jedi Master Yoda.
Site Review
Here I'll do site reviews. After this issue it'll be taken over by Viper.
Future Software |
Future Software is one of the mayor QB sites out there. When you enter
Future software you come to a page that ask you to bookmark it and then
says that all QBasic programmers can enter... Well since I'm a QB programmer
I entered. The first thing I noticed is the great layout! There is a nice
looking navigation bar on the left of the page, two search engines in the bottom and
the navigation for the files page is on top in a pulldown window, this is really good!
On to the page, Future Software has more than 400 files, a really neat QB sites search engine, a message board, site reviews and
some information about them. Ok, that's about the introduction now read the scores! |
. |
General Appearance: | 80/100 | A well thought out layout, also the Files pull-down menu is really nice. The MsgBoard & Guestbook are all local CGI-Script, heavily modified by Future Software. |
Images: | 95/100 | Just great looking images!! |
Sound: | N/A | No sound |
Programs/Links: | 90/100 | Lots of files and a good search engine with many sites!! |
QBasic: | 95/100 | All about QBasic! |
Unique: | 75/100 | Well the search engine is pretty unique but that's all... |
Total: | 87/100 | A good site to bookmark and come back often! |
Nemesis Software |
Nemesis Software is a fairly new page, it has a really good
layout; the page title is in a top frame, there's a body frame with some borders around it,
and a bottom frame with a menu. Whenever a topic you select from the menu has categories
a little menu frame pops up at the top of the body frame which keeps the page clearly structures.
There is a banner exchange, some links, awards page, about 60 files, some Q&A question, and their
programs and information about Nemesis Software |
General Appearance: | 87/100 | A very good layout, very clear and easy to navigate. There are some JavaScripts on Nemesis Software all written by themself. |
Images: | 80/100 | Just 3 words: Simple but nice! |
Sound: | N/A | No Sound |
Programs/Links: | 77/100 | Not so much programs and only a few links, but there is a search engine with more links. |
QBasic: | 82/100 | There are lots of things about QBasic but also lots of things not about QBasic. |
Unique: | 80/100 | The Banner Exchange and the Search Engine are pretty unique. |
Total: | 80/100 | A good looking page with not too much programs and links but with some unique features. |
Shorts
NES Emulators in QBasic!
No, I'm not kidding! There are two NES emulators written in QBasic
now! The first is called: uNESsential and the second if called DRR-Nes.
DRR-NES now emulates some games. But not that many... uNESsential emulates also
very little games.
More people moving to .quickbasic.com
Many QBasic sites are moving to a new .quickbasic.com address. This includes
NeoZones, QBasic The Magazine, Enchanted Creations and Alternatelogic.
If you want your own .quickbasic.com address go to Darkelf Productions
Qlympics STILL in Preliminary Rounds
As of now the Qlympics are still in Preliminary Rounds. It's almost two
months since the Preliminary Rounds have started. When will the real voting
on the Qlympics begin? The QB Times will keep you informed
First Impression
3Des Designer
3Des Designer is a 3D object creator. It has a real nice interface and you
can have lots and lots of planes in your object. It comes with a very neat
help system which is almost like a HTML page! It also has a renderer where
you can view your object rotating in 3D with realtime shadowing!
You can make objects by placing planes in the workarea. Then you can
shape up the plane. You can edit in 3 views: top view, front view and
side view. You need to fool around a bit but when you get the hang of
it it's really cool!
The version avaible on the internet is version 0.42B. The version I reviewed
was version 0.43B. I really liked the interface of 3DES Designer, it's very
clear. The pre-made objects made by BlackBird are also very nice to look at.
I think if this program continues it could be one of the best QB programs ever
made!
Project RT
Project RT, one of the most anticipated projects of the year so far.
And we are the first to bring you an official playtest ! Many rumours
have been spread about the engine being incrdibly fast, some even
saying that the engine got 60 FPS on a 133 !!! well i can now tell you
that each and every one of these rumours are true ! the turbo charged
ASM engine flys on my 300 at a speed which is almost unplayable !
The incredible engine supports texture mapped walls and 256 objects on
the screen at any one time. At the moment Peter is waiting for angelo's
door routines so the project can continue, but as Angelo's net
connection is down, RT has been put on hold for the next couple of days.
Just to clear up a couple of wild rumours, someone said that you played
cuby and coby in a doom style wetspot 3, this is very not true. Peter
has said that Angelo and he have not discussed anything of the sort !
For all the latest news read The QB Times
The author of this article is Greg McAusland ( Maz )
Hex Tutorial
Warning: This is meant for advanced QB users or advanced C/C++ users
wanting to expand their knowledge and make their own libraries.
QB beginners beware; this would be a frighting scare!
Level One: One and only
People how worked with HEX numbers before don't have to read
this. Basically as 19day says, run away run away! =) Actually
you might find this a bit or two interesting (just keep it under
32-bit please =)
We'll start with showing how about digits and stuff of the sort,
Base 1: Base 2: Base 8: Base 10:
0 01 01234567 0123456789
OK there you have is some different numbering systems. As you
can see Base 1, has only one possibility, it is useless and wont
be used. Base 2 has 2, from where you get 'bi', therefor
getting the word binary. Base 8 has 8,from where you get 'oct',
therefor giving you octal. And obviously comes good old base 10
(the one you should use in your head.) from where you get 'dec',
therefor giving you decimal.
Now you might already know all that, but why I'm here is to
show you how to count in HEXADECIMAL. It's a Base 16 numbering
system.
Base 16:
0 1 2 3 4 5 6 7 8 9 A B C D E F
----------------------------------------------
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
There you have it, now you know what all those As Bs and Cs are!
You might be asking how to count double hexadigits. Well it's
simple, let's take 11 as an example.
(First digit*16)+(second digit)
Which gives us 17. Simple? Sure is, a similar concept applies
to quad hexadigits.
(First digit*4096)+(Second digit*256)+(Third digit*16)+Fourth digit
Or you could just use calculator to give you the answer, but I'm sure
it's too hard to press Start, Programs, Accessories, Calculator ... no
no no ... What's the world coming to??? So back to the real world lets
take 2222 as an example, you get 8738! Simple right? Try making
your own functions if you want, although it will be useless, there's always HEX$.
Now that over, you could go back to whatever you were reading and finish
this tutorial! =)
The author can be contacted at: abionnnn@geocities.com
Writing your own scripting language
Introduction
Well, this article is about creating a scripting language for your game.
But what exactly is a scripting language? A scripting language is that
you type in commands in, for example, a text-file and the program reads
the text-file and knows what to do from the commands it reads from the
text-file. I'll give an example:
OPENBOX
DISPLAYTEXT Hi! This text is written in a box
WAITKEY
CLOSEBOX
END
That are some simple instructions you can make a program respond on.
Like, with OPENBOX it opens a box, then displays the text, waits
for a key to be pressed, closes the box and ends. How do you make
this stuff with QBasic? Well, that's why I'm writing this, to explain that
to you!
A simple scripting language
Ok, first we'll start with the basics like calling a PRINT command from
an external file. Ok, lets say we want to call the command to PRINT a text:
DISPLAYTEXT. Create a new file in Notepad and write this in it:
CLEARSCREEN
DISPLAYTEXT Wow! This is my first scripting language!!
DISPLAYTEXT Press any key to end...
WAITFORKEY
DISPLAYTEXT You pressed a key and now the program ends!
ENDSCRIPT
DISPLAYTEXT This action will NOT be executed because there
DISPLAYTEXT is an ENDSCRIPT command before it!
Save it as script.dat. So now we have some commands in an external file.
But QBasic can't do anything with that so we need to make a program
that reads the script-file and ports it so QBasic can understand it.
A good way is to read the script-file line by line, then check if the line contains
commands and what they are, if there are any expressions after the command
store them in a temporarily variable and then execute the command. For example
to let the program execute the commands we just used you could use this code:
OPEN "script.dat" FOR INPUT AS #1
DO
INPUT #1, ReadLine$
ReadLine$ = LTRIM$(RTRIM$(ReadLine$)
IF LEFT$(ReadLine$, 11) = "DISPLAYTEXT" THEN
Temp1$ = RIGHT$(ReadLine$, LEN(ReadLine$) - 12)
PRINT Temp1$
END IF
IF LEFT$(ReadLine$, 7) = "WAITKEY" THEN
WHILE INKEY$ = "": WEND
END IF
IF LEFT$(ReadLine$, 9) = "ENDSCRIPT" THEN
EXIT DO
END IF
LOOP UNTIL EOF(1)
CLOSE #1
I'll discuss the code line by line now:
OPEN "script.dat" FOR INPUT AS #1
Opens our scripting file 'script.dat' for reading as file #1
DO
Start the Do...Loop event that runs until the file ends
INPUT #1, ReadLine$
Reads a single line from the file.
ReadLine$ = LTRIM$(RTRIM$(ReadLine$)
Removes all the spaces from the left and right of the line.
IF LEFT$(ReadLine$, 11) = "DISPLAYTEXT" THEN
If the first 11 characters from the line we just read form the word
DISPLAYTEXT the DISPLAYTEXT command is run.
Temp1$ = RIGHT$(ReadLine$, LEN(ReadLine$) - 12)
The DISPLAYTEXT command contains one expression so we just read the
right part of the line we took minus twelve character (the DISPLAYTEXT
command + the space).
PRINT Temp1$
We PRINT the expression we just took.
END IF
End the IF...THEN command
IF LEFT$(ReadLine$, 7) = "WAITKEY" THEN
If the first 7 characters from the line we read are WAITKEY we run it.
WHILE INKEY$ = "": WEND
We wait until a key is pressed
END IF
End the IF...THEN command
IF LEFT$(ReadLine$, 9) = "ENDSCRIPT" THEN
If the first 9 characters from the line we read are ENDSCRIPT we run the command.
EXIT DO
We exit the DO...LOOP event.
END IF
End the IF...THEN command
LOOP UNTIL EOF(1)
Loop back to the DO
CLOSE #1
We close the file.
Now you have your first (small) scripting language! Now onto the harder
things!
Adding comments
Well, this isn't exactly hard but I still wanted to include it. I'll
now explain on how to add QBasic like comments (the little ' thing).
Add a line with a command somewhere in the 'script.dat' file before
the ENDSCRIPT command.
Ok, now add this 2 lines somewhere in the do loop:
IF LEFT$(ReadLine$,1) = "'" THEN
END IF
This checks if the first command is a ' and if it is, it just does nothing
because a comment does nothing. Good, now you can have comments in your scripts!
Next time
Next time I'll talk about variables and IF...THEN commands. Maybe also
about DO...LOOPs and FOR...NEXTs. Until then, enjoy the rest of the issue!
ASM in QBasic
Hello, and welcome to my first article in this small serie. As you know
the future of QBasic/QuickBasic relies on the extensive use of ASM. But
the problem is that the QBasic community doesn't have enough qualified
programmers to "drive" this complicated machine. Well, I want to change all
that today. = ) Before you start reading this I must warn you, this is
pretty heavy stuff to start on, if you're only starting on QBasic now is
the time to back out. Don't say I didn't warn you ; ) And for ASM pros,
don't read this either, because I'll end up insulting your intelligence
and you'll end up hating me. The first thing you need to get to start
ASMing is an assembler, a debugger, and a guide. You probably have the
last one (your reading it right now), but if you need to get the other
two, hop down to http://www.quickbasic.com/ and get yourself "The ATK V2.01"
(If ChUcK put it up there, if he didn't email me and I'll put it up there,
in the mean time download the atk v1.0). Got everything? Good. Here we go:
Lesson no.1 The 4 basic registers
First I'd like to start with a brief explaination of variables in ASM.
ASM is very diffrent from QB and high-level languages, as it doesn't use
variable names. (well assemblers do in their way, but at a pure level
there is no variable naming system) Of course, you can store data in the
computers memory, but it wont be "tagged" with a variable name like i% or
num1.
When fooling around with asm, you get many preset (variables) to
temporarly hold critical data. The first four registers we will learn
today are:
AX 16-bit register
BX 16-bit register
CX 16-bit register
DX 16-bit register
Well you see AX, BX, CX and DX are all really integers (can have a value
between -32766 to 32767) inside your CPU. You're probably thinking
"4 integers! How am I ment to work with that many variables!"
You see that's the art of ASM (ofcourse there are more than 4 registers
but I'll introduce them later) you must challenge your self programming
in it! If you don't want to be challenged and you just want to use other
people's librarys, please stop now and spare yourself some precious time, ASM is not for everybody.
Lesson no.2 Some very basic commands
Before starting this section, read the HEX tutorial if you have no
previous knowledge of using hexadecimal.
In order to give a register a value, you must "move" the value into
the register. It's simpler than you think, here is an example:
MOV AX,1
that command tells the CPU to assign register AX a value of &H1.
So in other words ax% = &H1. Here's another example:
MOV CX,32
That command tells the CPU to assign register CX a value of &H32.
that mean cx% = &H32.
You can also assign values from one register to another like so:
MOV BX,DX
This give BX the value of DX. As you can see it's easier than you
probably thought, Moving a value from one register to another, or
assigning a value to a register takes a bit of time, but when I say
a bit of time I mean 2 clocks* on a 80286 (really old processor) or
1 clock on a 486/Pentium.
To add a value to register you use the simple "add" code like so:
ADD AX,4
This increases the value of AX by &H4. You can also add another
register to an other register like you would when "mov"ing. Heres
an example code :
MOV AX,3
MOV DX,AX
ADD DX,4
ADD AX,DX
What does the value of AX end up? Simple, &H7! Look at the code
carefully if you don't agree with my calculations.
Well that's it for this artical, in part two we'll be discussing
some more productive methods of using ASM.
* A Clock cycical is used to mesure time taken by the processor to process a command, to find the nanosecond taken you use this simple command :
(1000Mhz/(n Mhz))=X nanoseconds
Where n is the Mhz speed of the computer.
The author of this article can be contacted at: abionnnn@geocities.com
Ramblings of a Crazed RPG Programmer: Advanced Quest Design
Greetings Everyone! For those of you who have not managed to read something of mine or bump into me in a QB
chatroom, I'm fairly laid back and informal. So, without any noticable transition, let me tell you about
a problem that many first-time RPG programmers run into. Simply put, they have the engine, they have the art,
the person walks and talks, now how do you force him to conduct a series of actions and thus perform a quest?
I suppose in its simplest form a quest follows these steps:
1. Attain quest - usually by talking to a non-player character (NPC)
2. Perform quest - do the action commanded by the NPC
3. Accept reward - get something in return for completing the quest
To give an example of the above steps as they should appear in your game commands, here is what happens:
Store a variable in your code called BEARQUEST. Set it's value to 0.
You talk to the village elder (an NPC) who's code is partitioned in this manner:
If BEARQUEST =0 then say a$
If BEARQUEST =1 then say b$
If BEARQUEST =2 then say c$
If BEARQUEST =3 then say d$
Since your BEARQUEST variable is 0 at the moment, he says a$ which could be this.
"A bear is eating all the children. If you slay him, I will reward you with 500 gold coins."
Once the text is said, have the code change BEARQUEST to 1.
If you now talk to the elder, he will say b$, which could be "Please hurry in your quest."
At this point the player wanders all around the game until the bear is found. Once killed change
BEARQUEST to 2. Now return to the village elder who now says c$, "You've saved us! Here is 500 gold coins!"
Now to complete the quest, change BEARQUEST to 3 so that from now on, everytime you talk to the elder he will
say d$, "Thank you for saving the children. Good luck in all your future adventures."
Congratulations if you could follow that, it's all there is to making a quest.
Now you're probably thinking, "That's not hard at all! I thought this was advanced quest design!" Don't worry,
I'm not finished yet. The above design was more or less what was used in Dark Ages I. Its brilliance is in
its simplicity (and that it works), but its drawbacks are impracticality, informal structure, and wasted space.
While programming Dark Ages II, I discovered something better structured, external, and more malleable is
necessary for what is going to be a much larger and more complex program. Using the basic concepts of the above
example and integrating better structured coding such as scripting, I believe I have come up with a great
quest system.
In order for this to make sense, you need to be familiar with scripting. I can't give you a good impression of it
here, but it's basically a few lines of code that get their data from external files (usually .txt) and perform
the actions based on the data read. The advantages are almost essential in programming because they save a lot
of code space, structure your program, and organize what would otherwise be an uncontrollable amount of variables.
In my strategy, quest coding requires three things: speech scripting, object scripting, and a universal variable
dimension. The universal variable dimension (UVD) is a simple integer dimension from 1 to whatever, where each
number represents a variable and could have a value from 0 to whatever. Now here comes the surprise, this strategy
is advanced, yet amazingly simple. My speech script contains the following necessities, but yours could be
modified to your needs. It contains the variables required, the text that is spoken, and the variables that are
changed. The text scripting code would be read whenever a player attempts to talk to someone.
Let's look at some pseudo code of my script:
*"1","0"
*"1","1"
*"Help me, I have a horrible disease and need a magic cure potion!"
*"1","1"
*"1","2"
*"Thank you for saving my life. Take this magic item as thanks."
*"1","3"
*"2","1"
*"1","3"
*"I'll never forget how you saved my life."
Here's how it works. Variable 1 from your UVD currently has a value of 0. According to the above script, if
it has a value of 0 or 1, the text would read, "Help me, I have a...etc." and then change variable 1 to have
a value of 1 (obviously if it was 1 already, changing it to 1 would mean keeping it the same). If it had a value
of 2, it would read the corresponding text, change it to 3, then change varialbe 2 (perhaps a magic sword variable)
to have a value of 1. After that, every time the text is read, it would find variable 1, value 3 and read that
corresponding text, never making any more changes.
"Hold up! Where did variable 1, value 2 come from?" Ahh, good question! Here's where object scripting comes in.
Object scripting is in many ways similar to text scripting. The basics that I have integrated are type of object,
variables required, text to be read, and variables changed when activated.
Let's look at some object pseudo code:
*"1"
*"1","1"
*"You have found a magic cure potion."
*"1","2"
Unlike text scripting, object scripting needs to be read twice in the game. The first time it is read is when
the map loads. You have to write a script that will search your file for the objects that will show up on the
map, then a separate script for what happens when you manipulate those objects while playing the game. In the
case of the above code, the first "1" represents that the object is something that you pick up if the UVD variable
1 has a value of 1 (as shown in the second line of code above). If you had a value of "2" for the first line, it
could be an object that you activate, but do not pick up, like a lever or switch. In this manner, if you load the
map before you have been given the quest to find the magic cure potion, then your UVD variable 1 would have a
value of 0 and the potion would not appear on the map. But if you have been given the quest, then your UVD
variable 1 would have a value of 1 and the potion would appear. The third line of code is what appears signifying
you have picked up the potion and the fourth line gives variable 1 a value of 2. Now if you redraw your map and
check your object script, it will no longer draw the object because your UVD variable 1 has a value other than 1.
If you've been following all this then you will notice that variable 1, value 2 is the key to finishing the quest
you started in the scripting code. You can now return to the NPC who sent you on the quest and get your reward.
Obviously this is a very basic example of advanced quest programming. Your scripts may contain up to 20 lines,
and manage up to 10 variables as some of mine do in DA2. It just depends on how complex of an engine you desire.
But hopefully you've picked up what a quest is in an RPG computer game. Simply put, a quest is just the
manipulation of people and objects in the game. You could even go so far as to create your own program to manage
your NPC and object scripts while you write them.
The author of this article is: Michael Hoopmann aka DarkAges
In the Spotlight
That's right, I have my own article here every time the QB Times comes out.. =) Well, here i'm
going to discuss a site, each time the QBT comes out a different site, the site for this issue
of the QBT is: (P.S. Want your site here? Mail me at viper2@cyberdude.com)
The IFace Warehouse
The I-Face Warehouse is a site about graphics, web-design, etc. They provide you with a huge
collection of interfaces you can freely use on your site! (like Future Software did) They also
have tons of website templates, all top-notch design! Now, see how many points they scored:
Topic: | Mark: | Description: |
Design: | 7.3 | Could have been better, if their menu was
in a side-frame, while the content was in
the main-frame.. Also, i would have used
another font, like Verdana, and not the
standard one.. |
Compatibility: | 7.0 | This site works just fine with with a
resolution of 800x600, and higher, but not
when you're viewing the site with a
resolution of 640x480.. |
Content: | 9.5 | This site is really filled with lots of
good, useable information and cool interfaces,
banners, website-templates, etc... |
Updating: | 9.0 | This guy updates his site a lot, that's all
I can say here.. |
Overall: | 8.2 |
|
The author of this article is Viper who can be contacted at: viper2@cyberdude.com
File Formats: BMP
Note: This document is for advanced programmers! You need a good
understanding of binary files and the different kinds of variables!
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 alternative22 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:
Member | Description |
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:
Member | Description |
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:
Member | Description |
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:
Member | Description |
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
pixels.
When Windows draws a cursor, it uses the AND and XOR masks to combine the
cursor 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. Window 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 the AND masks that create a
cursor (measuring 8 pixels by 8 pixels) in the form of an arrow:
Following are the bit-mask values necessary to produce black, white,
inverted, and transparent results:
Pixel result | AND mask | XOR mask |
Black | 0 | 0 |
White | 0 | 1 |
Transparent | 1 | 0 |
Inverted1 | 1 |
Windows Cursor Selection
If a cursor-resource file contains more than one cursor image, Windows
determines the best match for a particular display by examining the width and
height of the cursor images.
BITMAPFILEHEADER (3.0)
typedef struct tagBITMAPFILEHEADER { /* bmfh */
UINT bfType;
DWORD bfSize;
UINT bfReserved1;
UINT bfReserved2;
DWORD bfOffBits;
} BITMAPFILEHEADER;
The BITMAPFILEHEADER structure contains information about the type, size, and
layout of a device-independent bitmap (DIB) file.
Member | Description |
bfType | Specifies the type of file. This member must be BM. |
bfSize | Specifies the size of the file, in bytes. |
bfReserved1 | Reserved; must be set to zero. |
bfReserved2 | Reserved; must be set to zero. |
bfOffBits | Specifies the byte offset from the BITMAPFILEHEADER structure
to the actual bitmap data in the file. |
Comments
A BITMAPINFO or BITMAPCOREINFO structure immediately follows the
BITMAPFILEHEADER structure in the DIB file.
See Also
BITMAPCOREINFO, BITMAPINFO
BITMAPINFO (3.0)
typedef struct tagBITMAPINFO { /* bmi */
BITMAPINFOHEADER bmiHeader;
RGBQUAD bmiColors[1];
} BITMAPINFO;
The BITMAPINFO structure fully defines the dimensions and color information
for a Windows 3.0 or later device-independent bitmap (DIB).
Member | Description |
bmiHeader | Specifies a BITMAPINFOHEADER structure that contains
information about the dimensions and color format of a DIB. |
bmiColors | Specifies an array of RGBQUAD structures that define the
colors in the bitmap. |
Comments
A Windows 3.0 or later DIB consists of two distinct parts: a BITMAPINFO
structure, which describes the dimensions and colors of the bitmap, and an
array of bytes defining the pixels of the bitmap. The bits in the array are
packed together, but each scan line must be zero-padded to end on a LONG
boundary. Segment boundaries, however, can appear anywhere in the bitmap. The
origin of the bitmap is the lower-left corner.
The biBitCount member of the BITMAPINFOHEADER structure determines the number
of bits which define each pixel and the maximum number of colors in the
bitmap. This member may be set to any of the following values:
Value | Meaning |
1 | The bitmap is monochrome, and the bmciColors member must contain 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
bmciColors table. If the bit is set, the pixel has the color of the second
entry in the table. |
4 | The bitmap has a maximum of 16 colors, and the bmciColors member
contains 16 entries. Each pixel in the bitmap is represented by a four-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 | The bitmap has a maximum of 256 colors, and the bmciColors member
contains 256 entries. In this case, each byte in the array represents a
single pixel. |
24 | The bitmap has a maximum of 2^24 colors. The bmciColors member is
NULL, and each 3-byte sequence in the bitmap array represents the relative
intensities of red, green, and blue, respectively, of 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.
The colors in the bmiColors table should appear in order of importance.
Alternatively, for functions that use DIBs, the bmiColors member can be an
array of 16-bit unsigned integers that specify an index into the currently
realized logical palette instead of explicit RGB values. In this case, an
application using the bitmap must call DIB functions with the wUsage
parameter set to DIB_PAL_COLORS.
Note: The bmiColors member should not contain palette indexes if the bitmap
is to be stored in a file or transferred to another application. Unless the
application uses the bitmap exclusively and under its complete control, the
bitmap color table should contain explicit RGB values.
See Also
BITMAPINFOHEADER, RGBQUAD
BITMAPINFOHEADER (3.0)
typedef struct tagBITMAPINFOHEADER { /* bmih */
DWORD biSize;
LONG biWidth;
LONG biHeight;
WORD biPlanes;
WORD biBitCount;
DWORD biCompression;
DWORD biSizeImage;
LONG biXPelsPerMeter;
LONG biYPelsPerMeter;
DWORD biClrUsed;
DWORD biClrImportant;
} BITMAPINFOHEADER;
The BITMAPINFOHEADER structure contains information about the dimensions and
color format of a Windows 3.0 or later device-independent bitmap (DIB).
Member | Description |
biSize | Specifies the number of bytes required by the
BITMAPINFOHEADER structure. |
biWidth | Specifies the width of the bitmap, in pixels.
biHeightSpecifies the height of the bitmap, in pixels. |
biPlanes | Specifies the number of planes for the target device. This
member must be set to 1. |
biBitCount | Specifies the number of bits per pixel. This value must be 1,
4, 8, or 24. |
biCompression | Specifies the type of compression for a compressed bitmap. It
can be one of the following values: |
Member | Description |
BI_RGB | Specifies that the bitmap is not compressed. |
BI_RLE8 | Specifies a run-length encoded format for bitmaps with 8 bits
per pixel. The compression format is a 2-byte format consisting of a count
byte followed by a byte containing a color index. For more information, see
the following Comments section. |
BI_RLE4 | Specifies a run-length encoded format for bitmaps with 4 bits
per pixel. The compression format is a 2-byte format consisting of a count
byte followed by two word-length color indexes. For more information, see
the following Comments section. |
biSizeImage | Specifies the size, in bytes, of the image. It is valid to
set this member to zero if the bitmap is in the BI_RGB format. |
biXPelsPerMeter | Specifies the horizontal resolution, in pixels per meter, of
the target device for the bitmap. An application can use this value to select
a bitmap from a resource group that best matches the characteristics of the
current device. |
biYPelsPerMeter | Specifies the vertical resolution, in pixels per meter, of
the target device for the bitmap. |
biClrUsed | Specifies the number of color indexes in the color table
actually used by the bitmap. If this value is zero, the bitmap uses the
maximum number of colors corresponding to the value of the biBitCount member.
For more information on the maximum sizes of the color table, see the
description of the BITMAPINFO structure earlier in this topic.
If the biClrUsed member is nonzero, it specifies the actual number of colors
that the graphics engine or device driver will access if the biBitCount
member is less than 24. If biBitCount is set to 24, biClrUsed specifies the
size of the reference color table used to optimize performance of Windows
color palettes. If the bitmap is a packed bitmap (that is, a bitmap in which
the bitmap array immediately follows the BITMAPINFO header and which is
referenced by a single pointer), the biClrUsed member must be set to zero or
to the actual size of the color table. |
biClrImportant | Specifies the number of color indexes that are considered
important for displaying the bitmap. If this value is zero, all colors are
important |
|
Comments
The BITMAPINFO structure combines the BITMAPINFOHEADER structure and a color
table to provide a complete definition of the dimensions and colors of a
Windows 3.0 or later DIB. For more information about specifying a Windows 3.0
DIB, see the description of the BITMAPINFO structure.
An application should use the information stored in the biSize member to
locate the color table in a BITMAPINFO structure as follows:
pColor = ((LPSTR) pBitmapInfo + (WORD) (pBitmapInfo->bmiHeader.biSize))
Windows supports formats for compressing bitmaps that define their colors
with 8 bits per pixel and with 4 bits per pixel. Compression reduces the disk
and memory storage required for the bitmap. The following paragraphs describe
these formats.
BI_RLE8
When the biCompression member is set to BI_RLE8, the bitmap is compressed
using a run-length encoding format for an 8-bit bitmap. This format may be
compressed in either of two modes: encoded and absolute. Both modes can occur
anywhere throughout a single bitmap.
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. In addition, the first byte of the pair can be set to zero to indicate
an escape that denotes an end of line, end of bitmap, or a delta. The
interpretation of the escape depends on the value of the second byte of the
pair. The following list shows the meaning of the second byte:
Value | 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 offset of the next pixel from the
current position. |
Absolute mode is signaled by the first byte set to zero and the second byte
set to a value between 0x03 and 0xFF. In absolute mode, the second byte
represents the number of bytes that follow, each of which contains the color
index of a single pixel. When the second byte is set to 2 or less, the escape
has the same meaning as in encoded mode. In absolute mode, each run must be
aligned on a word boundary. The following example shows the hexadecimal
values of an 8-bit compressed bitmap:
03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01
02 78 00 00 09 1E 00 01
This bitmap would expand as follows (two-digit values represent a color index
for a single pixel):
04 04 04
06 06 06 06 06
45 56 67
78 78
move current position 5 right and 1 down
78 78
end of line
1E 1E 1E 1E 1E 1E 1E 1E 1E
end of RLE bitmap
BI_RLE4
When the biCompression member is set to BI_RLE4, the bitmap is compressed
using a run-length encoding (RLE) format for a 4-bit bitmap, which also uses
encoded and absolute modes. In encoded mode, 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 four bits) and one in its low-order
nibble. The first of the pixels 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. 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.
In absolute mode, each run must be aligned on a word boundary. The
end-of-line, end-of-bitmap, and delta escapes also apply to BI_RLE4.
The following example shows the hexadecimal values of a 4-bit compressed
bitmap:
03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01
04 78 00 00 09 1E 00 01
This bitmap would expand as follows (single-digit values represent a color
index for a single pixel):
0 4 0
0 6 0 6 0
4 5 5 6 6 7
7 8 7 8
move current position 5 right and 1 down
7 8 7 8
end of line
1 E 1 E 1 E 1 E 1
end of RLE bitmap
See Also
BITMAPINFO
RGBQUAD (3.0)
typedef struct tagRGBQUAD { /* rgbq */
BYTE rgbBlue;
BYTE rgbGreen;
BYTE rgbRed;
BYTE rgbReserved;
} RGBQUAD;
The RGBQUAD structure describes a color consisting of relative intensities of
red, green, and blue. The bmiColors member of the BITMAPINFO structure
consists of an array of RGBQUAD structures.
Member | Description |
rgbBlue | Specifies the intensity of blue in the color. |
rgbGreen | Specifies the intensity of green in the color. |
rgbRed | Specifies the intensity of red in the color. |
rgbReserved | Not used; must be set to zero. |
See Also
BITMAPINFO
RGB (2.x)
COLORREF RGB(cRed, cGreen, cBlue)
BYTE cRed; /* red component of color */
BYTE cGreen; /* green component of color */
BYTE cBlue; /* blue component of color */
The RGB macro selects an RGB color based on the parameters supplied and the
color capabilities of the output device.
Parameter | Description |
cRed | Specifies the intensity of the red color field. |
cGreen | Specifies the intensity of the green color field. |
cBlue | Specifies the intensity of the blue color field. |
Returns
The return value specifies the resultant RGB color.
Comments
The intensity for each argument can range from 0 through 255. If all three
intensities are specified as zero, the result is black. If all three
intensities are specified as 255, the result is white.
Comments
The RGB macro is defined in WINDOWS.H as follows:
#define RGB(r,g,b) ((COLORREF)(((BYTE)(r)|((WORD)(g)<<8))| \
(((DWORD)(BYTE)(b))<<16)))
See Also
GetBValue, GetGValue, GetRValue, PALETTEINDEX, PALETTERGB
BITMAPCOREINFO (3.0)
typedef struct tagBITMAPCOREINFO { /* bmci */
BITMAPCOREHEADER bmciHeader;
RGBTRIPLE bmciColors[1];
} BITMAPCOREINFO;
The BITMAPCOREINFO structure fully defines the dimensions and color
information for a device-independent bitmap (DIB). Windows applications
should use the BITMAPINFO structure instead of BITMAPCOREINFO whenever
possible.
Member | Description |
bmciHeader | Specifies a BITMAPCOREHEADER structure that contains
information about the dimensions and color format of a DIB. |
bmciColors | Specifies an array of RGBTRIPLE structures that define the
colors in the bitmap. |
Comments
The BITMAPCOREINFO structure describes the dimensions and colors of a bitmap.
It is followed immediately in memory by an array of bytes which define the
pixels of the bitmap. The bits in the array are packed together, but each
scan line must be zero-padded to end on a LONG boundary. Segment boundaries,
however, can appear anywhere in the bitmap. The origin of the bitmap is the
lower-left corner.
The bcBitCount member of the BITMAPCOREHEADER structure determines the number
of bits that define each pixel and the maximum number of colors in the
bitmap. This member may be set to any of the following values:
Value | Meaning |
1 | The bitmap is monochrome, and the bmciColors member must contain 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
bmciColors table. If the bit is set, the pixel has the color of the second
entry in the table. |
4 | The bitmap has a maximum of 16 colors, and the bmciColors member
contains 16 entries. Each pixel in the bitmap is represented by a four-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 | The bitmap has a maximum of 256 colors, and the bmciColors member
contains 256 entries. In this case, each byte in the array represents a
single pixel. |
24 | The bitmap has a maximum of 2^24 colors. The bmciColors member is
NULL, and each 3-byte sequence in the bitmap array represents the relative
intensities of red, green, and blue, respectively, of a pixel. |
The colors in the bmciColors table should appear in order of importance.
Alternatively, for functions that use DIBs, the bmciColors member can be an
array of 16-bit unsigned integers that specify an index into the currently
realized logical palette instead of explicit RGB values. In this case, an
application using the bitmap must call DIB functions with the wUsage
parameter set to DIB_PAL_COLORS.
Note: The bmciColors member should not contain palette indexes if the
bitmap is to be stored in a file or transferred to another application.
Unless the application uses the bitmap exclusively and under its complete
control, the bitmap color table should contain explicit RGB values.
See Also
BITMAPINFO, BITMAPCOREHEADER, RGBTRIPLE
P>
BITMAPCOREHEADER (3.0)
typedef struct tagBITMAPCOREHEADER { /* bmch */
DWORD bcSize;
short bcWidth;
short bcHeight;
WORD bcPlanes;
WORD bcBitCount;
} BITMAPCOREHEADER;
The BITMAPCOREHEADER structure contains information about the dimensions and
color format of a device-independent bitmap (DIB). Windows applications
should use the BITMAPINFOHEADER structure instead of BITMAPCOREHEADER
whenever possible.
Member | Description |
bcSize | Specifies the number of bytes required by the
BITMAPCOREHEADER structure. |
bcWidth | Specifies the width of the bitmap, in pixels.
bcHeightSpecifies the height of the bitmap, in pixels. |
bcPlanes | Specifies the number of planes for the target device. This
member must be set to 1. |
bcBitCount | Specifies the number of bits per pixel. This value must be 1,
4, 8, or 24. |
Comments
The BITMAPCOREINFO structure combines the BITMAPCOREHEADER structure and a
color table to provide a complete definition of the dimensions and colors of
a DIB. See the description of the BITMAPCOREINFO structure for more
information about specifying a DIB.
An application should use the information stored in the bcSize member to
locate the color table in a BITMAPCOREINFO structure with a method such as
the following:
lpColor = ((LPSTR) pBitmapCoreInfo + (UINT) (pBitmapCoreInfo->bcSize))
See Also
BITMAPCOREINFO, BITMAPINFOHEADER, BITMAPINFOHEADER
RGBTRIPLE (3.0)
typedef struct tagRGBTRIPLE { /* rgbt */
BYTE rgbtBlue;
BYTE rgbtGreen;
BYTE rgbtRed;
} RGBTRIPLE;
The RGBTRIPLE structure describes a color consisting of relative intensities
of red, green, and blue. The bmciColors member of the BITMAPCOREINFO
structure consists of an array of RGBTRIPLE structures. Windows applications
should use the BITMAPINFO structure instead of BITMAPCOREINFO whenever
possible. The BITMAPINFO structure uses an RGBQUAD structure instead of the
RGBTRIPLE structure.
Member | Description |
rgbtBlue | Specifies the intensity of blue in the color. |
rgbtGreen | Specifies the intensity of green in the color. |
rgbtRed | Specifies the intensity of red in the color. |
See Also
BITMAPCOREINFO, BITMAPINFO, RGBQUAD
Closing Words
Well, that's it for the first issue of The QB Times. I hope you enjoyed
reading it and that you found use of any of the articles in this issue.
The next issue is schedueld for somewhere the next 3 or 4 weeks. Again
I hope you enjoyed this issue and I hope to see you again next issue!
-Nightwolf
Credits
Editor: | Regular Writers: | Submissions: |
Nightwolf | Masamune_Q Abionnnn Nightwolf Viper DarkAges | Yoda |
© Copyright Nightwolf Productions 1999