Does anyone know something more about ImageList (I mean more than the
written in the Borland C++Builder 3 help) ???

How does ImageList draw transparent images. I've made an experiment
drawing 200-300 bitmap objects. If they are in a TImageList object and I
use a TImageList method to draw then to a canvas they are drawn really
faster thanm if I use Canvas->Draw ...

I've read something about the transparent masks of a bitmap. Is the
answer something here and if so how can I make this mask of a bitmap ???
the Mask function does something very different.

I want to find out is there a way to achieve faster drawing than the
usual. For instance lots of games already use the native WINDOWS GUI and
drivers - Age Of Empires, Knights & Merchants, Caesar 3.

Thanx for any help.
--
Tsvetozar / Fast Fashion
ICQ# 7653555
http://www.x-kom.com
X-KOM Ltd.
++ 359 / 2 9753329

Tsvetozar / Fast Fashion <tsveto...@bia-bg.com> wrote:

I think it is inconceivable that these games use plain GDI calls for
drawing graphics. It's extremely likely that they use DirectDraw for
drawing, and they use either IDirectDraw::BltFast or their own custom
assembly bltters.

That they use the native GUI tells you nothing about their sprite
technology.

--
Lucian Wischik, Queens' College, Cambridge CB3 9ET. www.wischik.com/lu

HI!

An interesting note:

A 256 color-bitmap takes more time to draw than a 16-bit color or a 24-bit
color bitmap do. :)

Johan Bryssling, Student, University of Kalmar, Sweden.

Tsvetozar / Fast Fashion wrote:

And even more. I've found that 256-color bitmaps if I draw them tranpsparently
they don't draw in their actual palette ...
I had to convert them to 24-bit color.
TImageList draws them correctly but loaded from resource or file and drawing
them with Canvas->Draw(x,y,aBitmap) is quite strange for 256 color bitmap...

--
Tsvetozar / Fast Fashion
ICQ# 7653555
http://www.x-kom.com
X-KOM Ltd.
++ 359 / 2 9753329

Well I can't understand you much but what I've noticed on Knights & Merchants
is that at a sertain point of the game they change the screen resolutioon from
800x600 to 1024x768 and this is probably done with the windows api function(I
forgot what was it, to change windows screen resolution).

Well what I've tested is writing bitmaps into a hidden bitmap and then drawing
it to screen.so if I would like to make a custom bitmap or image blitter do I
have to use my own custom DC ??? This is I can't understand ...

And about those assebly blitters. I know lots of assembly and I have
experiance making programs under DOS accessing the video memory, but this
shouldn't be the way to achieve faster bit blitting under window. I guess I
should use some of the windows api functions to show the final bitmap to the
screen even if I use my custom assebly or C image blitters and sprite concept.

--
Tsvetozar / Fast Fashion
ICQ# 7653555
http://www.x-kom.com
X-KOM Ltd.
++ 359 / 2 9753329

That is unlikely. The API you are thinking of is
ChangeDisplaySettings. But under Win'95 and Win'98, this API call is
unable to change the colour depth. The only way to change colour depth
under Win'95 or '98 is to use DirectDraw::SetDisplayMode.

Custom blitters are normally fastest way of getting sprites to the
screen! There are several options:

1. Use hardware acceleration. This is fastest if all the sprites
happen already to reside in video memory and never change.
2. Use your own assembly blitter.
3. Use IDirectDraw::BltFast. But this doesn't do colour-keying and it
doesn't do clipping, which is unfortunate.
4. Use IDirectDraw::Blt.
5. Use the standard BitBlt with DIBSections.

The reason that custom blitters are the fastest is that everyone's
blitting needs are different: some people want to clip, others don't,
for some sprites it will be more efficient to write a
run-length-encoding thing for transparent areas, for many situations
it will be way fastest to write self-generating machine code specific
to each individual sprite. It is inevitable that general-case code
(eg. BltFast, Blt, BitBlt) will be slower than special-case code.

The reason that hardware accelerated blts aren't as common as they
might be is that they're only fast when everything is in hardware. But
games programmers often want to be able to read or write individual
pixels or use their own custom routines (eg. for particle effects),
and therefore their surface must be in system memory not video memory
(for video memory is terribly slow at this sort of stuff) and
therefore they can't use hardware accelerated blts.

Strictly speaking, the way you'd normally set this to the screen is to
use all this custom blitting to a background surface, and then use
whatever function you want to swap background surface with foreground
surface (eg. IDirectDraw::Flip if you're using DirectDraw, or just a
regular BitBlt if you're using DIBSections).

I'll think over your words. Now I have some more work here. I'll try developping
some primitive model of fast-blitting sprite technology, but one more thing, I've
heard about this DirectX and I can't understand what's its purpose (what does
programatically). Is it some kind of hardware accelerator ???

--
Tsvetozar / Fast Fashion
ICQ# 7653555
http://www.x-kom.com
X-KOM Ltd.
++ 359 / 2 9753329

Tsvetozar / Fast Fashion wrote:

DirectX is another API, an eextension to the Win32 API, that Microsoft
have produced to allow you to use the latest graphics accelerators in
Windows.

MS ship a generic software library that supports all your calls, and
it's up to your card manufacturer to provide an effiicient driver that
implements those features it can in it's hardware.

Basically, there are two 'ends' to the API, the games writers' end (us
:? ) and the video drivers end.  DirectX is effectively the 'middleware'
but by providing a common API, rather like Windows did for printers, you
write your code once to support all graphics accelerators.

AlisdairM

Ok. Thanx for the information about DirectX. I hope I can use it with C++Builder 3.
This will be great.

--
Tsvetozar / Fast Fashion
ICQ# 7653555
http://www.x-kom.com
X-KOM Ltd.
++ 359 / 2 9753329