There's not much point to bumping this. The feature is in limbo till I can figure out how to implement it in DirectX or can get OpenGL properly up to speed. DirectX doesn't appear to offer options on how Present() scales anything; the only way to accomplish this might be to make all transforms use this same interpolation method as well.
Lummox JR wrote:
the only way to accomplish this might be to make all transforms use this same interpolation method as well.

That would not be a bad thing, considering it uses nearest-neighbor interpolation for the edges of the icon anyway, and is especially noticeable when using rotation transforms.
^ Is that the method that's going to be used, assuming this on the list? = )
Just for anyone who's using transforms and not satisfied with how it looks, increase all of your source icons to 2:1 and display them at half that (should look the same) and then try your transforms.
I'm hoping the priority is for the map and not transforms. Although having nearest-neightbor in transforms would be beneficial, I'm much more interested in simply being able to increase the window resolution without filtering.
Any plans for this in the near future?
In response to Fugsnarf
Fugsnarf wrote:
I'm hoping the priority is for the map and not transforms. Although having nearest-neightbor in transforms would be beneficial, I'm much more interested in simply being able to increase the window resolution without filtering.

I see it as way more beneficial to the map than to transforms as well. But as I still don't know how to force DirectX to do this nicely, I have no answer yet on when it could be implemented.
If you are using GDI, there's: SetStretchBltMode HALFTONE.

If you are using old Direct2D apis: ID2D1BitmapBrush::SetInterpolation to D2D1_BITMAP_INTERPOLATION_MODE

I can't be sure of what exact version of GDI/DirectX you guys are building against. All I know is that either appears to be abandonware. If you are using GDI/DirectX, though, these are THE functions you'd be using.

There's some talk of PlgBlt not honoring nearest neighbor, and negative transforms totally screwing readability. Can't speak for those.
Again I have much less interest in supporting this for transforms; the map is where this comes in much more handy.

GDI handles software mode. It already uses the HALFTONE mode for stretching the map, but I know how to use other modes there. (HALFTONE though is for linear interpolation, not nearest neighbor.) As far as PlgBlt which we use for transforms there, it does appear to be strictly nearest-neighbor.

DirectX 9 is used for hardware mode--not Dircet2D. We render sprites to an offscreen surface and then use Present() to scale to the correct size. DirectX is doing the interpolation all on its own and as far as I can tell, there doesn't seem to be a way to control it. If there is, I'd be happy to learn it and implement this kind of thing for the map.
In response to Lummox JR
SetSamplerState only impacts the textures/sprites as far as I know, so it would be transform-only. I have not seen any evidence it impacts Present() at all, even after having done considerable experimentation with it.
I did a google and it kinda looks like something, but I don't actually know anything about this stuff.

I have also observed that linear interpolation is perfomed in this case, and I am not aware of any way to control this directly. However, it can easily be avoided by simply rendering into a rendertarget that is the same size as your window, and then selecting whatever interpolation type (point or linear) that is appropriate. This may mean an additional render pass than what you currently have, but that's essentially what used to be happening on XP anyway.
I don't really know much about DirectX rendering, but I tried to search for answers anyway.

My first suggestion is to set the MultiSampleType member of the pPresentationParameters parameter of the CreateDevice() method to D3DMULTISAMPLE_NONE.

Another suggestion is setting the MultiSample parameter of the CreateRenderTarget() method to D3DMULTISAMPLE_NONE.

This is assuming that either CreateDevice() or CreateRenderTarget() are called at some point, and if so, I would think that this might make a difference.
In response to Multiverse7
Multiverse7 wrote:
I don't really know much about DirectX rendering, but I tried to search for answers anyway.

My first suggestion is to set the MultiSampleType member of the pPresentationParameters parameter of the CreateDevice() method to D3DMULTISAMPLE_NONE.

It's a good thought, but we already do this. If this were something that the presentation parameters could take care of, it would already be done. This param appears to be unrelated to the method DirectX uses to upscale when calling Present().

Another suggestion is setting the MultiSample parameter of the CreateRenderTarget() method to D3DMULTISAMPLE_NONE.

We don't use CreateRenderTarget(); I don't know if it would be involved in any kind of method to work around this issue or not. But since the multisample param doesn't impact the upsampling in Present(), it almost certainly wouldn't here either.
Quick update on this.

I suffer from the same 64x64 upscale blur problem as most people do, namely on any ss13 server out there.

http://puu.sh/e3h61.jpg
(Blurry, 64x64 map)

However, when I open my right click context menu, this entire issue seems to vanish and everything becomes properly crisp at 64x64 mode.

http://puu.sh/e3h7X.png

Not exactly sure what wizardry is going on here, whether it's my card suddenly supporting the interpolation when the context menu is opened or what...
http://puu.sh/eduNz.png

It's also fixed by mousing over something in the taskbar like this
In response to Paprka
Paprka wrote:
http://puu.sh/eduNz.png

It's also fixed by mousing over something in the taskbar like this

I've noticed this too and stated this before somewhere, I wonder why tho.
I don't know whats happening there when the right click menu / taskbar window popups come in to change the game screen like that. It might be a directx thing, antialiasing only being on or the stretch type being like that. EIther way, if there was a way to force it on all the time, the nearest neighbor blur issues would be cut down a lot, at least in windows 7 i think. I'd like to know what's going on here too, it's pretty weird.
Have there been any new developments with this issue? BYOND's hardware scaling on my primary work machine is super blurry, and it's becoming more and more of a headache. If it were an obscure issue with only my computer then I'd just go out and buy some new hardware for development, but it seems to affect quite a number of players as well. Scaling the map view of my 16x16 icons to 32x32 or 64x64 makes the everything super blurry and essentially unplayable.

I did some google research of my own into this problem, and I came across a forum post that looks to be describing the same exact issue in Directx 9 (the guy is even using 16x16 sprites that exhibit the same type of blurriness when scaled). Other users quickly helped him find a solution: http://www.gamedev.net/topic/ 617420-directx-scaling-pixelated-textures/

I think that the most relevant snippet is contained in these quotes, but I'm not sure:

setting MagFilter = POINT did the trick.

and

If you're using POINT sampling for pixelated textures, you may need to offset your texture coordinates by half a pixel (0.5 / size), or you can end up with weird texturing issues that may be hard to spot at first.
In response to Silk Games
That post is referring to SetSamplerState(), which doesn't appear to be relevant to how Present() works.

The only information I've found on the subject is in this thread, which indicates this is at the very least a difficult problem. That thread shows the opposite issue to what you're seeing, suggesting this is a driver setting.

I suspect there has to be some way around this issue, but it's been a very difficult one to suss out. So far the only people to come forward with ideas keep returning to SetSamplerState(), which does nothing to Present() as far as I can tell. I'm wide open to ideas if anyone has any.

[edit]
I took some time to do more research on this, but I'm still running into dead ends. I'd love to find any solution that would work for the majority of computers. StretchRect() might be promising if I can figure it out, but it doesn't seem to be able to stretch directly to the screen, requiring an intermediate buffer. Not finding any examples on that, but maybe some eagle-eyed users could find some.
Page: 1 2 3 4 5