Re: Inline asm?

[Jeff Read <bitwize@geocities.com>]

Pierre Phaneuf wrote:

> The problem with this is that you lose most of the library effects. Say
> the library has a function to copy with transparency. You code one
> yourself that is a bit faster, so it pays off nicely and you're happy.
> Later on, you do like me and upgrade your video card to a nice Matrox
> Millenium G200 that has so many acceleration features it makes your head
> spin. Including copying with transparency. And now the library function
> is 400% faster than your painstakingly hand-coded assembler function.
> 
> Was it worth it?
> 
> This is just an example, but you just never know what is in store for
> the next release of the library or the next generation of video cards.
> With AGP and large amounts of video card memory we have now, even for a
> 2D game it makes sense to put most of the pixmaps in the video memory
> and have the video card blitter (most modern cards have them, even the
> cheap ones, and gamers *have* those cards) do the work for you
> incredibly faster than you could have ever done in assembler.

You raise an interesting point. For games which use simple 2D blits with
transparency this may be what you want to do. However, what if you want
to do scaling, rotation, shearing, raycasting, voxel plotting, alpha
blending, dynamic lighting or something else not supported by today's 2D
cards? Very often using the pixmap approach means the pixmaps are locked
away in some unknown portion of video memory; this is assuredly the case
with X11, Win32 GDI and perhaps even DirectX. Maybe KGI or shared memory
pixmaps have some sort of workaround to this, I don't know. Whatever the
case, in order to achieve these video effects with today's 2D you need
to be able to directly modify the contents of the offscreen buffer with
the CPU and then somehow blit that into the video memory, where the CPU
may again be involved. So ASM blitting routines are not completely
useless. :) Occasionally you'll see these tradeoffs being made; for
example, in the game "Jazz Jackrabbit 2" there is a hardware accel
option. Enabling it makes the game blit the graphics faster, but the
tradeoff is that you lose certain effects such as dynamic lighting. The
emulator Snes9x for Linux offers a third approach: It can be configured
to use the Voodoo card for on-screen rendering. Even though it's called
a "3D-only" card, the Voodoo is an excellent choice for complex 2D
rendering effects. Therefore, using it if it's available is another
possibility to consider.

The quake games and Snes9x sort of have the right general approach to
programming the graphics subsystem to a game: the ability to replace
rendering components with something else that would do the job better on
a particular machine, for example, replacing a software renderer with a
hardware blitter via a DLL or some sort of compile- or run-time
configuration. Different strokes for different folks. :)

-- 
----------------------------------------------------------------------
Jeff Read <bitwize@geocities.com>
Unix Code Artist, Anime Fan, Really Cool Guy