>The reason the extruded square pattern undergoes those slightly odd shifts in hue under 16-bit play is
>because I re-indexed the TL originals to the To pallet with Color GIF, and the plug-in was pulling whatever >colors worked best from Hades CLUT regardless of "ramp."

I don't think this one is your (or C-gif's) fault, I'm pretty sure it's all due to the OS' 16-bit drawing routines. I already re-indexed these textures when reworking them a bit for this update, so they are in the appropriate CLUT already. Low saturation colors always seem to show a bit of hue-shifting in 16-bit - as far as I can tell it's because the drawing routine doesn't give any special attention to hue values, it simply finds the next closest RGB value in the 16-bit range and uses that. (eg. R120, G120, B140 and R130, G120, B130 might seem quite close to the drawing routine, but to the human eye there's going to be a detectable change in hue - not an accurate example I know, but illustrates the point. That's why optimized 16-bit artwork is a tricky one to do - go compare the M2 'Simulacrum' screens for a really good example, and if you can work out how they managed to generate the 'dither' for the 16-bit one I'd be interested to hear any ideas.)

I may play with alternate colors later, but it is livable with, and as I've just pointed out myself, you'll have similar problems with any other low-saturation colors anyway...:p

This is a good place for you two to discuss practical design issues: where the art is going, how it looks and plays within the game engine, look at existing examples (eg. M1, M2, Marathon Infinity, 3rd party texture art) for comparison; get a good two-way dialogue going. You ought to have a stack of notes on the subject by now anyway - Guide the lad, though the important thing is not to sound like you're lecturing (it's more difficult in email where you tend to exchange whole written paragraphs each time rather than talking directly in sentences). A texture set that looks like an LSD trip might look kinda funky and novel at first, but it's not much use for mapmaking in practice (I'm sure there are still some old M1 shapes patches of this sort around if you look on the HA - might be useful to look at).

If you look at some of Randy Reddig's textures, you'll notice how they tend to be made up of several basic patterns cut into pieces and composited together. You might try geometric (curved -style) templates for the cut-out templates, filled with the more abstract patterns.

BTW, remember that color-to-color blends rarely work well once you index - eg. blending red into green looks like shit. You might get a mix of similar colors (eg. a couple of brownish colors in rust streaks) to work sometimes, but mostly you go from color to black as a blend. If you want different colors next to each other you use a hard edge. Pencil tool and selection tools with anti-alias unchecked are useful. This is definitely something you'll need to keep an eye on in [First person]'s art. The big trick with Marathon art, which I've had to learn over time, [Second person] seems to have forgotten, and [First person] probably hasn't yet figured out for himself is to draw and color art whilst _bearing_in_mind_ how it's going to be output [256 color standard CLUT] and viewed [in Marathon engine - sector-based lighting, no MIP-mapping, and fixed 128x128 texture size which should look good whether on both small or large surfaces].

Think about it: precise details of how 16-bit mode _actually_ works, it works out around 16/3 = 5, 5 bits per color channel 2^5=32 levels of color. In practice what happens is that the 16-bit display doesn't just limit itself to the one hue (that's why you get ugly color shifts passing across semi-lit textures), so you see more "levels", but not all of the same hue or saturation. That's the best I've figured it out as, anyway.

Look at the starscape LS texture sometime. There's a good reason I only used 32 grays in it, even though I could have used more - if I had used more then it would have looked better in millions, but worse in 1000s as some of those grays would have appeared as (other) colors. Jesse Simko had a really gorgeous smooth yellow-greeny sky LS texture in MM that looked wonderful in millions, but banded and ugly as hell in 1000s. My solution was to save a copy as a 16-bit PICT, then open that in Photoshop, index to create a CLUT that only contained colors visible in 16bit mode, then used that CLUT to index with dither the original image. Result was an LS that wasn't quite as silky-smooth as the original RGB version, but a thousand times better in 16bit. This is something to bear in mind when doing 16bit chapter screens. (Though really crafty folks may figure how to make an 8-bit chapter screen that is also 16-bit "compliant" - assuming a suitably limited range of colors used in first place - and thereby half the number of chapter screens required in a scenario.)

[HAS writing to a scenario maker and their crew] Good. BTW, I've already given you notes on making up Photoshop swatches, and you should have a handy-dandy Photoshop Scratch-sized PICT also containing the T2 colors. (I prefer using scratch palette, as it's much more compact [15" monitor], and I can copy ramps out of it when making customized Photoshop CLUTs for indexing art [more useful for sprites, though I also use it for indexing individual parts of textures separately].)

Make sure all artists are set up with a T2 Photoshop CLUT suitable for indexing their art with, a copy of the Anvil Masterclass Plus (especially for anyone doing sequence editing - [a person] already ran into the Frames-bug, and I'd expect others to easily do the same), the RR notes and any others you've collected from me. Anyone exporting Photoshop CLUTs from anvil to index stuff in Photoshop should also check the AMP (if you index an image in Photoshop with an Anvil generated CLUT and save as a PICT, the saved PICT goes weird colors - it's all detailed in the AMP).

Ask them to supply any samples they may send to you in indexed form, optionally they can include full-color form too - but it's important that they are indexing stuff as they go, to ensure they are appreciating the limits that are imposed on what they can do in full color and still expect to index well. (Otherwise you may get tons of beautiful RGB samples, but that turn out to index down to shit later on.)

Oh yeah, and sizes - get em to work at 100% (any rendered 3D stuff is easier done without any anti-aliasing - makes little difference to end quality, but saves _much_ time not having to touch up borders). And, eg. for a human sized figure a bitmap of 120-150 pixels high is fine. You want to use roughly the same scale factor for similarly sized monsters so that the amount of detail in each is roughly similar. Nothing looks worse than a low-res figure stood next to a high-res one, plus high-res sprites will mean massive file bloat. Stuff like juggies, of course, which are only seen from further away (or in a major panic) get away with using the same sort of bitmap size (eg. 150 pixel high) with a much greater scale factor. You shouldn't need to go much above this for anything really.

Pixel height X scale factor = actual size in game (where 1024 units = 1WU), but I'm sure you knew that already. Still, it's important to consider before rendering any sprite art to a particular size - you really want to work out the desired size in game, and the preferred scale factor (ie. look at the average existing scale factor in other collections), and then work out exactly what size you want to render your sprites at. It does make a difference when you see it in the game.

Can't think of anything else for now. (Editor's Note: Sadly this last sentence is indicative of when the sutures that hold Hamishes head together start to pop and slip. Other signs include: the eyes looking around rapidly in two entirely different directions much like a chameleon and his tongue protruding from one or the other of his nostrils. - gls 10/31/2000)

[Editor's Note: For those of you familiar with usenet posts, that is what this is. For those of you unfamiliar with usenet posts, that is still what this is. OK maybe someone here isn't familiar with it. Here are the basics: A message is posted to a user group. When someone responds to the message he will generally quote what the person said, then type in his response. A quote is denoted by the ">" sign at the beginning of a line. The original post will have the most ">" signs the most recent post none. Get it? - gls 11/02/2000]

In article <364E8402.5DED@Inky_P_Dorkypooter.net>,
[Poster X] wrote:
> > 2. Use custom colors in one or more collections so your art can use any CLUT
> > it likes, and break 256 color mode in the process.
>
> untrue (at least on my machine)

Heh. Well, it's true, and it's untrue. Mostly it's "quirky", and I'm still unable to figure why it can and can't be made to work. My most recent version of the Masterclass (retitled HAS' EditNotes [dumb idea, now I've confused everyone:]) kinda touched on the subject a bit, but I'm reluctant to suggest folks jump straight in when I still can't figure what the hell's going on.

eg. My current (personal) project: a small TC with completely new CLUT (7 ramps of 32 colors each). This works perfectly in 256 (in fact, I made it 256-only as 1000s looked crap by comparison and millions is such a power-hog), but this is really because I replaced all the original colors (therefore I still have < 256 colors total). For a while I was totally scunnered by black areas turning weird colors in 256; figured a solution, tried it, and it worked (see EditNotes for more info). Then again, I tried messing with it the other day and found my blacks "fix" no longer had any effect, and something else was now calling the shots instead. So I'm confused.

I also just did some work on someone else's shapes file as a favor for them (a 1000s colors min. TC - totally 256 unsafe originally). Because it uses different custom CLUTs for all collections (no ramps; just optimized CLUTs for the original full - color art), it must have several hundreds of colors in it - and no way can M2 display all of those in 256 mode. However, following [Poster X]'s suggestion of using CM as a possible way of avoiding the usual troubles, I eventually got the thing 256-safe (if not beautiful - we are talking psycho colors here, as M2 just grabs a CLUT offhand and tries to display everything else with it). So, at least there's no risk of a hard crash, which was the whole point of the exercise (though whether adding future collections will break it again I don't know).

What is perhaps interesting about this example though is that it refused to work (many, many hard crashes for my Mac here :p) until I set up the landscape collection just-so. (BTW, the custom colors ones were stripped out to save space and I used the Standard ones in their place, putting custom CLUTs into these as was the case for textures, scenery, interface, etc, etc, etc.) Although the LS had only 60 colors in its CLUT (after it was optimized for 1000s display it was much smaller), I had to include the remainder of the original CLUT after I'd pasted over the first 60 colors with the new colors. (Note that when I tried first shortening the CLUT to 60 colors, and then changing the leftover colors to black, that I got hard crashes in both cases.)

What is perhaps interesting is that when I ran M2 with the eventually non-crashing shapes file in 256 colors, I found that M2 was using the same LS CLUT for its display (I took a screen shot, then checked out its CLUT in Photoshop for comparison). Why was M2 using this CLUT in particular for display? Is this something predefined in the engine, an arbitrary choice, or what? I have no idea.

So I'm still mystified as to what the whole mechanism is. About the only thing I do know for sure is that a 256 colors display can only display 256 colors max. But how colors are being remapped to a < 256 colors CLUT, and how that CLUT is chosen, and why it should work in certain circumstances but not others...

Anyway, to pick [Poster X]' mind a bit more...:)

> I've been able to successfully implement custom colors *in addition to
> (not in replacement of)* the marathon CLUT and have it work perfectly in
> 256 colors,

Presumably you don't see more than 256 colors on screen at any one time. How are the extra colors displayed (if at all, or are they remapped to something else), and if they do show then what happens when you try to view areas where > 256 colors are present?

> as long as no one CLUT has more than 256 entries in it,

Exceeding 256 colors would be an interesting trick. Except that CLUT Modifier had a bug in it that added an extra (unwanted) color to the end of exported CLUTs. Fortunately, Charles finally managed to fix this one - BTW, I'd seriously recommend anyone using earlier versions of CLUT Modifier update at once to the current version.

> and the ramps are the standard Marathon length (they don't have to be, but
> you'll get some really wacky shading effects in 256 colors if you don't).
> (note though, that I've not tried much mucking to see exactly what the
> limits are)

All I know is that sometimes it's safe, and sometimes it crashes as expected. I've not tried doing it for beauty's sake (since, like I say, you simply can't display > 256 colors in 256 display, so something, somewhere must have to give), but I reckon that anyone who does do non-256 colors conversions should try to make the thing crash-proof purely for the sake of politeness.

> the only noticeable side effect is that once in a blue moon (in 256 mode)
> Marathon will use one of those extra colors instead of black to draw the
> screen background

Heh, this is the problem that was tripping me up. I spent a day and eventually found M2 was using the first black (no. 20 in the CLUT or something, i think) in the textures collection as a 'global black' (anything with 0% lighting). I swapped around my CLUTs till I had a black in this position again, and no further problems. In fact, I was so pleased at this 'find' I mentioned it in the latest AMP; unfortunately I was doing some further experimenting as learning experience the other day and found M2 was now ignoring this color and plumping for the one at the end of the first (32 step) ramp in my Interface collection (soon as I tried changing this, there went my blacks again!).

I now have a theory that M2 is deliberately trying to confuse me to death. I can't think of any other explanation. And guess I'll need to revise the AMP (yet) again now. :P

> (usually the last one in some CLUT (probably the interface one),
> which is why it's good practice to make the last entry in every CLUT black)....

See? It's trying to confuse you to death too!:)

> It's not hard to get good results if you're a
> > competent artist (and if yer not, then no number of extra colors'll make you
> > one<g> ; )
>
> this is true... sometimes those extra slots help though...

If/when it works. And assuming you're blessed with the good fortune for it to still look presentable in 256 colors. Y'know, I think I'll be glad when all games force one to be 3D card, 16-bit minimum - at least we won't have to live with any damned CLUTs anymore! :)

> > Note that Marathon Infinity ramps are pure-color-to-black - there are no Tints
> > (color+white) available.
>
> not usually... but you can add them.. but see above

Again, me too: see above.:) I spent 2 days just trying to make a part-done (7 collections so far) Shapes file for a 1000s+ TC 256-safe purely for robustness' sake. I could have had an entire sprite collection done in less time... <waaaaaahhh> I swear I'm getting too old for this sort of insanity.;p

> [Poster X]

[barely sane:]
has

[Editors Note: This is from an exchange that occured at the newsgroup alt.games.marathon in 1999 - gls 11/04/2000]

> I've been learning myself Photoshop, and I've discovered that it is *much*
> easier to do sprites and stuff with this than with, say, ClarisDraw.
> However, there is one problem: How do I get Photoshop to use the M00 CLUT
> and nothing else?

?

> I've made an M00 swatch, and that was one of the kludgiest procedures I've
> ever been through: Open M00 in ResEdit. Take a screen shot of the CLUT.
> Edit away everything but the CLUT. Open in Photoshop. Reduce to 256
> colors. Bingo. I've got all the hues right. However, the shading is all
> wrong. Most of the color ramps have colors that are much brighter than
> they have any business being.

Did you take your screen shot in either 256 or millions of colors? Don't use 1000s - you don't get accurate colors. And if in 256, make sure the screen is displaying in the M-colors, and not just the system CLUT (depends what you're looking at at the time as to how the Mac displays it). And when indexing the thing, make sure you use Exact colors otherwise you'll mess up completely.

Really, if you're not working with Photoshop using a millions of colors display, you really, really want to be. Buy more VRAM or something if so.

There are much, much easier ways of making a suitable swatch, however. Cutting up a screen shot as described above is my favorite, for reasons I'll get to later.

Other methods:

Once you've indexed your cropped PICT, save your CLUT to disk via the 'Color Table...' menu option. You can then use that CLUT for indexing future artwork, and you can also import it into the Photoshop swatch palette using the 'Load Swatches...' option (look under the pull-down menu when you click on the ">" arrow in the Swatch palette).

What you won't get this way is all your colors in a nice order, however. The next way of grabbing the M-CLUT is to export one from your shapes file in Anvil using the Export CLUT to Photoshop option. However, none of the CLUTs contain every M- color (because once you've added the blacks to the end of every ramp there isn't space for em all). So I don't like this method much, as it means futzing around with your exported CLUT if you want to add the missing colors.

No, my favorite method now is to open a map up in Forge, switch to visual mode and take a screen shot. You can then open said screen shot in Photoshop (since it's from Forge, it's already indexed) and save the CLUT directly. This has all the colors except the transparency ones - for this reason you should add the transparency color to the end of the thing. Look for the end of the last ramp and the find the first pure black entry - click on this to bring up the color wheel and set it to pure blue. Save the thing to disk, and look after it - it's worth its weight in gold (well, okay, so that's rubbish - it doesn't weigh anything being a computer file n all - but it's bloody useful anyway:). You can import this CLUT to your swatch palette and, more importantly, you can safely use it for indexing all your Anvil-bound artwork. [There are notes on the problems with CLUTs/Anvil/Photoshop in my Editnotes on the HA - make sure you go and get these notes an read em; they'll make your life soooo much less painful.]

Personally, I don't bother dumping the colors into the swatch palette at all - it's big n bulky, and it's near just as quick to sample them off the indexed PICT with the pipette tool (press Option key to turn any drawing tool to pipette). Y'see, there's one more trick I really like to do, so here it is...

One of the problems of indexing e.g. sprite art is that your full CLUT usually contains many more colors than your collection contains. Now, either you can export the specific CLUT for that collection from Anvil (but this can cause problems as Anvil-generated CLUTs and Photoshop don't get along very well - go read Editnotes for full details), or you can do it my way:

From the indexed PICT, I'll select (using the marquee tool, and Shift-key to make multiple selections) only the ramp(s)/colors I want to index the artwork to. I paste these into separate documents, index, and save the CLUTs. I can then use these custom CLUTs to index the artwork as I see fit. One trick I use to get best results is quite slow (but it's still waaaay faster than touching up the indexed art by hand later) is to use the lasso tool (no anti-aliasing! - this is important) and/or Quick-Mask (again, aliased edges only) to select all those areas of the artwork which I want to appear in a single color only. I copy and paste them into a temporary document where I index them using a custom CLUT containing just that single ramp. I can then paste them back into the original document, and do the same for the next color. Once done, the whole artwork is indexed using the full CLUT and then pasted into Anvil.

BTW, if you think that sounds like a lot of work, then it can be - the trick is to use it where it's needed most (eg. for monsters which change colors according to rank), and all the non-critical bits can be indexed with just a single CLUT containing several ramps. Remember too that for well-differentiated ramps (eg. red and green) you're unlikely to get any color mixing when indexing those all together; whilst with similar ramps (eg brown and orange) you probably will get mixing, although this may not be of concern if it doesn't look untidy, and these particular ramps don't change to indicate rank (which is usually when it really starts to look ugly). A bit of practice, and you'll soon figure out the most efficient way of working. And all that said, well, you don't get something for nothing - the best-looking artwork always takes time. I use this technique frequently, and the results are always smoother than a baby's bot. Lurvely.

BTW, something important I should mention: index your artwork without dither, if possible. This really cuts down on the amount of ugly color mixing. If you must use dither, then you really want to follow the method outlined above and index each color ramp separately (this does look really rather smooth when done, BTW, and is useful where you get lots of hard banding when you don't use dither). Something else too: draw using colors close to the ones in the M'thon palette. Avoid tints especially (that's a pure color lightened with white), as these aren't represented in the Marathon Infinity CLUT at all and are a disaster to index. The M'thon CLUT consists of colors and shades only (shade is color + black). Tints and Shades are technical (art-geek) terms, but get a grasp of em and you can impress all your graphic designer friends in conversation as you demonstrate your prodigious knowledge of their subject.

As an example, you should try tracking down the Wheels demo (I believe you'll find a suitable link on the Archive Links page). The clown art was done this way - the entire collection only took me 2 days to do from start to finish, and it was a joy in the end not to have to do any touch up of the indexed art. Note how I also got really clean dithering on the suit - it breaks up the banding that would have been obvious had I indexed without dither, but because I indexed that entire area separately using only the blue ramp I got absolutely no unwanted colors present. It was sound payoff for time invested, and very probably was quicker than had I done a quick-n-dirty index and had to touch up the resulting mess after.

> When I import my sprites to Anvil, the result is often some really ugly
> dithering.

See above. ALWAYS index your art in Photoshop/etc. with the Marathon Infinity CLUT BEFORE you paste art into Anvil. Anvil sucks rocks at converting full-color art to Marathon Infinity colors. Actually, Photoshop isn't perfect either, but it's not bad (there are other tools out there which may be better [assuming you have them and know how to use them], but I never have and still manage to get by ok:).

> ClarisDraw is much better at this: I import the M00 CLUT directly and
> either work in 256 colors, or I work in thousands and then reduce to 256.
> Either way, the result is usually satisfactory, and no strange things
> happen when the sprites are pasted into the shapes file.

To be honest, I never work in 1000s colors. It lacks the color accuracy of millions. As for working in 256, well in Photoshop you don't have access to many of the drawing tools, layers, or filters. Which is where all the best work is done. Work in millions, index down to Marathon Infinity colors at the end is the best way, IMHO. Of course, the trick is learning how to do that indexing stage well.

ClarisWorks is cheese if you really want to do good art - really, you do want to use a Real-Man's Application like Photoshop (though color-It is reportedly also pretty good, and a damn sight cheaper too). The key is knowing how to use the app itself in the first place (folks using Photoshop for M-art have generally already learnt how to use Photoshop - this is not perhaps the best place to learn otherwise:), and then figure out how to make it produce stuff that M-thon is actually going to like. It's like knowing how to create on-screen RGB art, and then having to learn how to design for Print on top - you gotta learn all about CMYK colors, trapping, overprinting, and all that other guff. But once you've learnt what is and isn't practical, then you know how to produce the best results within those limitations.

Don't worry, it took me a couple months to learn from scratch how to handle color-tables and all the rest - man, you shoulda seen some of my early attempts for a laugh. Got it totally knocked on the head now tho'. : ) Now I just gotta learn design for print before mah boss figures out I actually don't know what th' hell I'm doing after all.<g>

Peace and Great Art.

has