If you’re talking about doing this via exporting in the w3d format, then use the Photoshop plugins mentioned and use those textures in your modelling program. Although there is no gaurantee that the exporter wont convert the format, it does so strange things at the best of times and of course you’ll need to remember to set the render format in sw3d as the loaded w3d will revert to a default value which may not be what you need for the texture.

If you want to do this by using bitmap members, then the Intel sw3d downsampling routines are pretty awful for anything with a gradient going from 32 to 16 bit, in fact it doesn't even look like they bother to dither it. So its better to provide a 16 bit bitmap if the texture is going to be 16bits. However you don’t really need an external tool to do this, although you might get slightly better results in a few specific cases. Director already has its own down sampling ability via the ‘Transform bitmap’ command ( modify menu ), but even better it can also be done via imaging lingo and the copy pixels command.

Using the copy pixel command has the added benefit that you can supply your project with 32 bit bitmaps and downsample them depending on memory requirements or user preference. That way you don’t lose the ability for having high quality bit depths. One important quirk to note is that to get good quality 16 bit images via copy pixels is to use the undocumented #dither instruction with a value of 1969. This forces copy pixels to use the slower but better quality method, the same one that the ‘Transform bitmap’ uses from the menu.

dstImage.copypixels(srcImage, destrect, srcrect, [#dither1969])

I seriously doubt you’ll ever get rgba4444 to work as a source bitmap, as Director doesn’t support this as a native format and so it can’t store the data. I think it would end up either converted to 565 or just end up corrupted. Your stuck with letting sw3d sample to this format.

I was intrigued by the Photoshop plugins mentioned, so I tried the 555 plugin (565 didn’t work) and it produced excellent 16 bit bitmaps, but only in a few cases, in those that I tested, did it actually produce something that was noticeably better than Director. Of course this will vary depending upon the content of the bitmaps you are converting.

I wrote a test program to compare the various methods of resulting quality of the textures. My conclusion (albeit based on a very small sample of 4 bitmaps) was that for 16 bit textures the most efficient approaching is to import them as 32 bit into Director (allowing for runtime decision over 32 or 16 bit usage), use copypixels to convert them to 16 bit, transfer them to textures in sw3d and set the render format to rgba5550.

The worse thing to do (as you’ve discovered) was to send a 32 bit bitmap and let the Intel engine convert it to 16bit. Using 16 bit bitmaps created via the Photoshop plugin only produced better results in 1 case (a horizontal gradient from white to purple). Whilst converting in Director in nearly all cases produced acceptable results that couldn’t be bettered by the Photoshop plugin.

As I said, these conclusions are only based on a small sample, it may be that your specific bitmaps will require going the photoshop route, or it may be that using Directors copy pixels gives good enough quality. You’ll only find out by testing your actual assets.

PM me your email address if you want a copy of the test movie source, to try on your own bitmaps.

Also you may want to consider joining dir3d-l or dirgames-l mailing lists, friendly and helpful community that focuses focus purely on Director and SW3D.

take a look here, we had a longer discussion about that a couple of month ago:

http://pocketmatrix.com/forums/viewtopic.php?t=11611


I've posted some code that dithers to 565 and 4444 using some optimized dither-tables. All other bitdepths are possible as well. These have some advantages over error diffusion algorithms when used as textures.

Regards,
Nils

hey noisecrime, hey anonymous poster.
thanks a lot for your help! i will check this and write again when i have some results or more troubles :)

I agree with Charles, if this is for 3d, it could look more ugly with dither.
than a drop in resolution for lower spec cards.

Nils, code looks interesting, when will you post a plugin for it :)

I don't use dynamic lighting but lightmaps - so this is no problem. The problem is the mipmapping cause for shockwave i can't create the mipmaps myself but only with the built-in algorithm (as far as i know)

btw the somewhat expensive Optpix imagestudio (yet one of the best for reducing to palletised images)will also dither to 15bit. The latest version for xbox/pc may also support 16bit, I've not tested it before though.

Quote:Original post by mikiex
Nils, code looks interesting, when will you post a plugin for it :)

The last time I tried to compile an Photoshop-plugin I wasted two days just to build the examples. Making a plugin that really works, with its own gui will even take more time. Also I hate it to edit these strange apple resource files by hand.

It wasn't a nice coding experience, so I don't think I'll ever try a photoshop filer just for fun anytime soon. Maybe things have changed, but the free photoshop sdk has vanished a couple of years ago.

Gimp looks easier to deal with, but I dislike Gimp from a workflow point of view.

If someone can recommend a *simple* plugin framework I'll drop my code in it and add a GUI.



There are still some things than can be improved. Did anyone ever noticed, that ditherd images look brighter than their undithered versions? The dithering we do does not take gamma into account. No big deal if you go down to 565, but dithering to 4444 it becomes very aparent. This is not only a "feature" of my tables, it's the same with any other dithering.


Anyways, the code is easy to call, it should be no big deal to add it to the artwork pipeline somehow. When I was in the industry, we never made this since we've used DXT, but I hand-dithered all the title images for playstation 1 games.

For games that use a lot of 565 images it might be worth just to add it. Infact there must be some code to convert from 888 to 565 anyways, and the code i've posted is a drop in replacement.

Regards,
Nils

(one day I'll register as a user...)

Nils there are a few photoshop plugin frameworks,
filter factory
filtermeister
Im sure there is an opensource one somewhere

Maybe Paint.net would be good to write a plugin for
it uses C#
It already has support for dxt and 32/24/16bit dds files
not sure it dithers... might be worth looking at.