Best technology to draw large indexed textures

[BahamutZERO]

Greetings,

I'm helping a Windows programmer port his game to Mac OS X. The entire engine is cross-platform and written in C++. It outputs indexed textures (paletted), with a palette that can change often since palette animation is used. It's an isometric engine, so no 3D is involved at all.

The game is an RTS, and as such there is both a game an a map editor. Therefore, in the case of the editor, the engine will be drawing to some kind of document window with scrollbars which may be live resized by the user, like any other document window.

Right now, we have an embryonic editor port working using HIView and Quartz to draw. The drawing is done by creating a CGColorSpace for the current palette and creating a new CGImage for every new frame, or when the palette has changed. We rely on Carbon and the render thread to notify the HIView it needs to refresh itself. When the view's bounds change, the engine is notified of a bounds change, at which point a new CGImage is created.

In mild terms, this is god-awfully slow. It works, but takes 75+ % CPU time on a dual processor 1 GHz G4 desktop, and this is no fancy engine with 1K particles flying around.

Thus the question -- what is the best API or technology to use to handle the editor's UI, and incidentally the game itself.

Thank you.

[DoG]

Indexed images are somewhat deprecated in OS X. You might want to look at the older QuickDraw APIs for the drawing, as those are from the days of color indexing.

Also, I imagine you don't have to create a new CGImage every time you refresh the view, that's what color indexing is for, after all.

[kelvin]

OpenGL and Quartz (in cocoa) handle indexed images just fine. You just have to dig through the docs a bit. OpenGL is probably your easiest path.

[arekkusu]

OpenGL does not support an indexed internal format (unless you are using nvidia hardware and an OS version older than 10.3.4.) It will convert the indexed image into a native texture format during upload, which is a bunch of CPU-side work. So, while using OpenGL is probably the fastest way to get bits from your app to the screen, you're still probably better off doing your own colorization.

MacMAME, for example, does exactly this to colorize the 8 bit graphics some emulated games output.

[BahamutZERO]

OpenGL does not support an indexed internal format (unless you are using nvidia hardware and an OS version older than 10.3.4.) It will convert the indexed image into a native texture format during upload, which is a bunch of CPU-side work. So, while using OpenGL is probably the fastest way to get bits from your app to the screen, you're still probably better off doing your own colorization.

MacMAME, for example, does exactly this to colorize the 8 bit graphics some emulated games output.

So in essence, what might be the fastest way is to write some code to convert each indexed frame into a full blown RGBA frame, then go for Quartz or OpenGL to output?

Is there some code example somewhere for doing this? Would AltiVec be useful in any?

[arekkusu]

The essence is simply:

for (i=0; i<numberOfPixels; i++) *output++ = CLUT[*input++];


MacMAME in fact uses altivec for its blitters, but the win there is when doing 15->32 bit conversion, or scaling, or rotation. I don't think you will get much benefit from altivec in this case since you're memory bandwidth bound-- there isn't enough computation here to optimize.

After you've colorized the output, if you decide to use OpenGL, see the Texture Range sample (http://developer.apple.com/samplecode/TextureRange/TextureRange.html) for the fastest way to get the data to VRAM.

There's bunch of hardware-dependent limits implied when you use GL, though, so depending on how large your images are, it might be easier to stick with CoreGraphics.

[lpetrich]

Converting indexed to direct color in software is the solution I used in Aleph One, http://source.bungie.org - my setup can create no less than ten textures for each sprite:

Eight of them are for the eight color tables that the engine can choose from
The ninth is an infravision image, which is a grayscale image that gets a hue at rendering time
The tenth is a silhouette image, which is a grayscale image used for invisibility and static effects.

Thus, a green Pfhor, a purple Pfhor, an orange Pfhor, and a blue Pfhor all get separate textures.