harold

It seems odd to me that the colour is CBC8B8 though - why not real gray?

What do you want to do?

You may need your windows install CD for that (you can also download it off Microsoft Download, but that dialogue thingy thinks it needs the CD)

Of course But obviously you wouldn't be able to edit it as vector image And exporting it back to svg would be hard/useless

C# is not too slow, it depends on how you use it If you use GetPixel and/or SetPixel, stop doing that immediately. Instead, just lock the bitmap once and use unsafe code to change the pixel data. Don't forget to unlock when you're done. I really doubt that you're doing that now, since it isn't slow at all PDN is pure .NET (except the shell integration and installer, right?)

Or you could try to find out why it won't work Duplicate the layer, take the lowest one, turn it to black, gaussian blur, move it somewhat - that's somewhat like drop shadow.. (a bit)

Change the system policy?

So you want to make your own plugin to solve that? (otherwise this would be the wrong subforum)

you mean like this?

Ok I know this is somewhat old by now, but.. The source is staring you right in the face (so to speak) - it's a .NET assembly, so easily decompilable (with, for example, Lutz' .NET Reflector) The description of this effect reminds me of Bloom a bit..

How many hundreds will you be needing? My guess is that it if it's just a moderately high number, there would be no trouble with memory. Of course it's always nice to use less.. But is it really crucial? I know that game, unless you're going to substantially increase the number of tiles in the computer version there shouldn't be a problem at all, you could even sub-tile the tiles, or have base-tiles (grass, city part, combinations in various shapes) + several detail sprites (clumps of grass etc) on top (basically sub-tiling with a separate background)

For pictures that do not contain large area's of roughly the came colour, the SVG file could end up bigger than the bitmap. IMO there is nothing to gain from converting to SVG anyway, trying to smooth the curves would destroy some detail, depending on the tolerance JPG pictures (and other noisy images) may end up being encoded as width*height squares, gradients are hard to detect, and because you can never guess the correct curve from a raster image it won't be very scalable anyway. Unless perhaps you use a very complex algorithm that takes a lot of time - and it still probably won't look the way you'd vectorize the picture yourself in most cases. An SVG importer may come in handy though.. edit: I just tried that vectormagic thing on a multi-coloured font - complete disaster, but a nice try anyway. It can clearly be seen that it does not use the algorithm you described, the bitmap importer of Inkscape however looks like it does.

Why is that plugin blocked? :?

I just had a quick go at it, don't expect anything great here but it's something..

No offence, but if you had to ask about this, the chance that you'll manage to put PDN inside your own window is pretty small..

You'd have to redirect the window output though.. otherwise it'd just be started..

You'd want to have a PDN window inside your application? Anyway, you could probably do a lot with System.Reflection..

Including real events (instead of a hackish interface trick), delegates, pointers in unsafe code, easy integration with native libraries/programs and the ability to make a thread from any method Which have been there before C#3 too.. That new LINQ stuff is cool though (especially PLINQ)

I would also try Unlocker to unlock some of the complaining files..

(un?)Fortunately human eye's don't actually measure photon intensity as such.. the same intensity isn't even always perceived as the same (depends on surrounding intensity and the intensity your eyes adjusted themselves to etc which is exactly what the problem is with the gradient behind the image) And of course it's not actually possible to divide FF by 2 and store the answer in a normally interpreted byte, which is an obvious result of the carry that occurs when shifting FF to the right by 1 bit (so 80 and 7F are both off by a half) Conclusion: 50% grey doesn't even exist

I think what he means to tell you is that the original file is just thrown away, and replaced by a newly made compressed file that can have Any size - depending on the quality setting and dimensions and on how "compressionable" it is (gradients and big pieces of only 1 colour will be far smaller than a small piece of randomness)

If you have ridiculously much RAM (say, 32GB+? 'cause you need than the actual size for it to be allocatable as 1 piece) you could run into the maximum dimensions though (which is, as far as I've been able to see, 65535x65535, the "new" dialog does not appear to accept any higher values)

The limit is (2^16)-1 in either dimension, which makes for 16GB if you choose it in both directions. So, ushorts for width and height..? probably larger than you'll ever need though :wink: edit: I tested a 8192 by 8192 full-white picture but the PNG exporter threw an "unspecified error", why would that be?

Difference also works for that

I managed to make something that "looks somewhat like it" with Curves+ (Value in, Alpha out) It's by no means an exact match though (it looks far less "bright")