harold

Ah yes you have one less column in your screenshot on page 1, but 15 rows in the actual plug-in I never really noticed Anyhow, adding 7 to 196 is not as easy as adding B to C0 (which is the same symbol) By the way, there can be symbols in the 1 - 32 range.. but not at 0 (or if it Does exists, it will never get rendered) Ok here's the idea (I hacked the DLL and obviously I won't spread it unless you allow me to) Well it's not exactly finished (the input field to choose the symbol should be hexadecimal as well to make sense) but it's easy to see the idea.

Hm I didn't know that.. also makes sense But I still find it somewhat inconvenient, probably because I'm not used to the Alt+num combo's at all, except for the µ because Alt+M doesn't work in all games but I still want to talk about µTorrent sometimes.. But about about 16 columns? Wouldn't that fit even better than 14 (??) columns? could it be made variable? that's probably a lot more work than making it fixed though.. but it would suit everyone

The error was that ScanWidth was not the same as Width, so pixels were copied to placeholder bytes. Right? You should probably be able to block-copy it row by row..

I know it's a bit late, but I have a suggestion. It would be much easier to use if there were 16 columns and they were numbered 0 to F. That way you wouldn't have to add anything, since the lowest 4 bits of the row number would always be 0, so there would be no carry. It's not that adding is hard, but not-adding is infinitely easier - you'd just concatenate the row address and the column offset. Alternatively, for people who think hexadecimal is hard, you could use 10 columns and do the same in base 10.

Or just use the effect template also found in this section of the forum?

I fixed some speed issues, this should save.. well.. a couple of milliseconds. The most time-consuming thing was getting pixels from the source surface, which I "solved" by sampling some pixels that are used more than once only once instead of each time it's used. Of course I should really use unsafe code, but that will come later.. Nothing else has changed, but the speed fixes could in theory have given rise to new bugs - please let me know if you find any.

The assemblyinfo has a version (the default, 1.0.0.0) Thread title edited.

To the title of the plugin window..?

Thanks for the tip Done and edited original post to reflect the changes.

MODERATORS NOTE: this plugin has been superseded by a newer version: https://forums.getpaint.net/topic/111602-normalmapplus-codelab-implementation/ Very simple plugin that probably already exists. Uses the Sobel Filter from AMD's Render Monkey's normal map example to calculate the first order derivatives of the image. Light angle is adjustable. This plugin will probably only help you if you're a 3D artist and you have a height map that, for some reason, you want to transform to a normal map. I imagine that situation will be rare.. NormalMap1.1.zip Version history: 1.0 - 2nd Jan 09: initial version, may include the ugly icon. 1.1 - 2nd Jan 09: various speed improvements. ps: I'm not an artist myself, in fact I'm so very not an artist that I didn't even give my plugin a proper icon. If you're an artist and you make a nice icon that you feel goes well with this plugin, please send it to me so that I can include it. edit: and I release this thing to the Public Domain. edit: Support terminated. You can still download it, at your own peril. This plugin is officially dead.

How about XP x64? Vote "other"?

Doesn't make it any less strange though

This may be a bug or intentional, but it's strange no matter what. Steps to reproduce: 1) create a new image, make sure it is too large for your memory but not too large for PDN (say, 65535x65535) 2) click OK on the error message 3) there is no step 3. By now, you will have no picture (ok), the drawing tools are disabled (ok), but you can't move or close the tool windows (why not?) Of course this is an edge-case, so I'll understand if no one cares about it.

You could write a file type plugin, that would be nice

Yes, you're right, but this post might calm the more paranoid users who are afraid you're performing some kind of magic that spies on private information etc And not all paranoid people know how to use WireShark..

they asked on the blog as to the "so" well, nothing, it's just proof that you are right :wink:

I've seen lots of people ask where the stats come from and the answer was always something like "the updater requests a text file decorated with the OS version and language" Which is exactly what it does. I fired up WireShark (previously known as Ethereal) and captured what it did. It does this: If your OS is windows XP x64 and you're using English, the request url will look like: http://www.getpaint.net/updates/version ... x64.en.txt (hover over to see full link) I rather suspect it's build up like: http://www.getpaint.net/updates/versions.[windows version number].[bitness of OS (32/64)].[language].txt The txt file itself is not very interesting, it contains things like download urls the version number and the required .NET runtime version number. Go have a look. I was surprised it wasn't XML though (seeing as XML is used in PDN files.. and XML is easy to parse) So it didn't use magic after all ps: what happens to the stats if you edit the url and put in random stuff?

But let's not ignore the possibility of coding them in C++/CLR or MSIL or VB.NET and possibly other .NET languages.. (would IronPython work? F#?) I'm not saying you're wrong though, it's just for completeness

Working with VS isn't so bad when it's for C# (basically it just works) If you're programming C++ then it's a whole different story, but eventually one gets used to it But just follow Simon's advice - it's the easiest way to do it

Usually not.. usually, the texture will already be in the GPU's dedicated ram during rendering (if it exists and is big enough) the texture will not be transformed: the vertices* will be transformed (or not, depending on the vertex shader, when it exists), and a pixel shader (or fragment shader, the GL equivalent) will sample from the texture (which is probably where the GPU's texture samplers come in) The number of pixels send to the screen per second only depends on the size of the viewport and FPS *: someone may decide to transform per-pixel instead, but I've never heard of anyone who did

1) less memory is needed to store them (leading to less paging etc) 2) less GPU bandwidth is used on textures (leading to faster transfers of vertices etc) 3) better locality of reference in the pixelshader when using the texture (since it's smaller) so better use of GPU texture caches there are probably more reasons For 1 less mipmap, the ram usage for that texture is approximately divided by 4

no.. http://directory.fsf.org/project/svg2png/ but maybe librsvg is better, not sure http://ftp.gnome.org/pub/GNOME/sources/librsvg/

One could just use svg2png and load the png right

What's wrong with: Bitmap newsizedbitmap = new Bitmap(oldbitmap, new Size(int x, int y); or something like it and then ofcourse save it with the right filetype.. or did I miss something?

He also said he copied the dll's to the correct folder, to do that they would have to be unpacked in some way (otherwise there is no dll) Maybe he means decompiling the dlls? You can get a good .NET decompiler here: http://www.aisto.com/roeder/dotnet/Down ... =Reflector