Dean Ashton

  • Content count

  • Joined

  • Last visited

Community Reputation


About Dean Ashton

  • Birthday 01/01/1970

Profile Information

  • Gender
    Not Telling
  • Location
    Cambridge, England

Contact Methods

  • Website URL
  1. is the dds plugin still available and if so where can i find it?

  2. David, The behaviour you're seeing, where explorer shows an icon that matches the image, is the result of either native support for the filetype in Windows, or an additional application called a shell extension. As far as I'm aware, there's no code relating to shell extensions in Paint.NET, so I'm not sure why you say 'Paint.NET can do this'. If you're an experienced programmer, you'll have to read up on writing shell extensions. If you're not, then you'll probably need an external application.. something like Note that I've not tried the program linked above, and do not offer any recommendation for it, nor do I take responsibility if it screws with your PC in a bad way. It's linked so you can see what I'm on about. Hope this helps, Dean
  3. And it appears that's exactly what was causing the problem. I had an old PdnLib reference in my project.. I removed that, and added PaintDotNet.Core, and everything started building again.. Thanks for the rapid response, Rick! Cheers, Dean
  4. Hi, I'm trying to get a new build of my DDS plugin released, but after upgrading to Paint.NET 3.05, I'm unable to build. My DdsFileType (derived from FileType) has an OnSave method defined as such (this is copied from VS.NET 2005's object browser) Building, I have the following error: I made modifications a long while ago when I upgraded to PDN 3.0 (the OnSave method had changed slightly, if I remember correctly), but the move to 3.05 has me confused. I would check the 3.05 source code out.. but it's not available for download. Any ideas? I've re-added all my references to make sure I'm pulling them from the right place.. but I'm now a bit stumped. Cheers, Dean
  5. While I have a readme file in my stuff, I'd rather we (plugin authors) could rely on a minimum level of common sense instead..? Seems much more sensible to me.. especially as plugins are generally written out of the kindness of the developers hearts.. Dean
  6. Had some time to check up in some DDS reference materials this lunchtime, as well as speak to some colleagues. Turns out it's quite valid to have non power-of-two DXT textures with mipmaps (it wasn't valid when I was working on Xbox titles way back.. hence the confusion). So as it happens this was all irrelevant anyway.. You could delete the thread, if you so wished.. Cheers, Dean
  7. Hmm.. that's a real shame. It makes the output somewhat unpredictable.. all you need is a slight size problem, and it would silently stop exporting it. It can make a significant difference to filesize, and to runtime performance when using the texture. At least if I could do this, it would be clear to the user as to what was going on.. I might have to hack a workaround (if I can think of a way of doing it!), as I'm not convinced that any ambiguity like this at the point the image is saved is a good thing.. Dean
  8. I'm in the process of adding mipmap generation to my DDS plugin. To this end, I've added a checkbox to my UI to allow for the generation of mips to be optional. I need to be able to disable this checkbox, but I'm unsure as to how to get the currently-being-saved image's width & height. Reason being that you can only have mipmaps for power-of-two images in the DDS file format... so the option should be disabled for non-power-of-two images. I thought about putting the width/height in my token, but that seemed pretty crappy.. I don't want it serialised. I looked in the existing filetype plugins, but none use the width/height of the image within the save config widget code. Hints appreciated.. Cheers, Dean
  9. Hi, Is it possible to zoom a preview of an image presented within a save dialog? When saving any form of lossy format, it can really really handy to be able to zoom in and see compression artefacts such as macroblocking and/or DXT quantizing artefacts. This is even more useful when working on larger images that contain packed sets of textures, as the current 1:1 display of the image in the preview window means you have to go through a save/load/zoom cycle. If not (and I suspect it's not, 'cos I couldn't see it in the code), could I throw it in the hat as a potential feature request? Cheers, Dean