Re: Inline asm?

[Pierre Phaneuf <pp@ludusdesign.com>]

Jeff Read 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.

Of course, I understand your point. But the idea is that if there is
something you want to do that the graphic library you use has a function
for, you're better off to use the library function than go out of your
way to do it in heavily optimized assembler. The trick is to mesh what
is provided by the library and what is implemented in your code
correctly, so that the best effect is obtained with the most opportunity
for taking advantage of future advances in the library.

That's one thing that is nice in open source code (like John Carmack
commented recently): you have something with some library function, you
don't code your own to get over it, you fix the original one and send
the patch to the owner of the code. Then it is fixed for *everyone*.

> 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. :)

That's the way I prefer... :-)

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi