|
DirectDraw:
Loading Jpg's and Gif's
By: Jack Hoxley
Written: May 2000
So far (if you're following my
tutorials) you will have only been able to load bitmaps into a directdraw surface.
Directdraw has no built-in support for loading any file type other than .bmp,
this is fine to a certain point, but bitmaps tend to have large file sizes -
something most people want to avoid when distributing their application. There
are other, newer, file compression technologies available at the moment, using
these can have a considerable file-size advantage over bitmap files.
For example, a 640x480 picture
with 65536 colours in it.
Saved as a Bitmap the file size was:...............................900kb
Saved as a highy compressed .Jpg the file size was:..........3.47kb (0.38%
of original size)
Saved as a low-compression .Jpg the file size was:............254kb (28%
of original size)
Saved as a .Gif the file size was:....................................312kb
(35% of original size)
As you can quite clearly see
from the above figures, different file format can drastically reduce the size
of files. One thing to bare in mind, the .Gif file format only allows 256 colours
and the Jpg files have slightly poorer quality (The 3.47kb file was really really
bad quality).
By preference I use low-compression
Jpeg files for my game related graphics, 28% is a still very good; But, I still
use bitmaps where quality is important. One place you'll notice quality is in
transparent images, by rule of thumb, ALWAYS USE BITMAPS for sprites and other
SMALL logos and pictures that need transparencies; by small I mean both dimensions
being below 250. Using Jpg's for fullscreen pictures and background textures
is a good idea - they add lots to a game, but no one's going to be incredibly
bothered by a slight reduction in quality.
Now, onto the code.
This tutorial will show you how to make a simple procedure that automates loading
of Jpegs into surfaces. The method I use is 100% garaunteed to work and is very
very simple - there are other faster ways of doing it, but I find them to be
incredibly complicated. This method is fine for when you load all your pictures
at start-up, but if you're application relies on fast loading and swapping pictures
around this will slow your application down considerably.
Public Function
CreateASurface(DirectdrawObject As DirectDraw7, DDSurface As DirectDrawSurface7,
Width As Long, Height As Long, SourceFile As String) As Boolean
On Error GoTo errhandle:
Dim ddsdF As DDSURFACEDESC2
Dim Surfpic As Picture
ddsdF.lFlags = DDSD_CAPS Or DDSD_HEIGHT Or DDSD_WIDTH
ddsdF.ddsCaps.lCaps = DDSCAPS_OFFSCREENPLAIN And DDSCAPS_VIDEOMEMORY
ddsdF.lWidth = Width
ddsdF.lHeight = Height
Set Surfpic = LoadPicture(SourceFile)
SavePicture Surfpic, App.path & "\TempFile.Bmp"
Set DDSurface = DirectdrawObject.CreateSurfaceFromFile(App.path & "\TempFile.bmp",
ddsdF)
Kill App.path & "\TempFile.Bmp"
Set Surfpic = Nothing
CreateASurface = True
Exit Function
errhandle:
CreateASurface = False
End Function |
|
|
|
As you can see, this is a simple function that
returns true if it succeeded and false if it didn't. The actual
internal code is almost identical to the normal loading of a surface, just with
a converter in front. The function uses a visual basic variable (picture)
to hold the image file, it then saves it to the hard drive as a bitmap - this
bitmap can now be loaded straight into the directdraw surface. As soon as this
is done it will delete the file from the hard drive and empty the surfpic
variable - so that the file isn't still present in memory.
This procedure gets slower as the size of the
file increases, I've found that it still takes under a second to load a 640x480
image - but that figure is based on the hardware that I have (strictly average
- nothing special).
|
