Best technology to draw large indexed textures

BahamutZERO
Unregistered
 
Post: #1
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.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #2
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.
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #3
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.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #4
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.
Quote this message in a reply
BahamutZERO
Unregistered
 
Post: #5
arekkusu Wrote: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?
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #6
The essence is simply:
Code:
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 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.
Quote this message in a reply
lpetrich
Unregistered
 
Post: #7
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.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Rewriting a (rather large) codebase in Cocoa Wowbagger 12 4,374 Jun 13, 2008 12:39 AM
Last Post: reubert
  What "technology" would you suggest? WhatMeWorry 6 3,383 Sep 23, 2005 12:58 PM
Last Post: TomorrowPlusX