 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Resolution Independence in 2D Direct3D Games An Alternative Approach |
|
 |
Ravyne Member since: 2/26/2007 From: Kirkland, WA, United States |
|||
 Posted - 11/20/2008 5:03:22 PM |
||||
| So, the article is decent enough for what it is, but I think the stated conclusion that this method results in better visual quality is sorely mistaken. Essentially, you've taken a game that was programmed as if it were 1024x768, and whose art assets were designed for 1024x768, and then tried to scale the vertices such that they fit the other resolution and noticed they don't look so good. The upscaled framebuffer looks fine, however, and you claim it to be the way which produces better visual quality -- It does in this case, of course, but only because you've not made any concessions to allow the typical method to work to the best of its ability, which, if done correctly, ought to look better. You're comparing "your way" to a ham-strung version of "the right way". Now, the method you describe does have its merits, namely that it is basically non-invasive, and allows you to focus on a single resolution for art assets. On the other hand, there are real downsides which you yourself mention. Also, the point may be somewhat moot -- On CRTs, better results can be had by changing to the supported resolution and LCDs will stretch to fit the display, doing essentially the same thing. I concede that your method may produce better, more-consistent results across different LCDs (particularly cheaper ones) at some additional processing costs, but the other side of that coin is that some high-end LCDs with high-quality scaling circuits may produce better results on their own. In order to make the traditional method work well, the art assets need to be designed for a 1:1 pixel ratio at the highest resolution, if not 2:1, and mip-mapping and multi-sampling should be enabled. |
||||
|
||||
 |
Aardvajk GDNet+ Member since: 3/3/2006 |
|||
 Posted - 11/21/2008 1:42:07 AM |
||||
Quote: Of course. I happily agree with every point you make, but I am only presenting this method for the situation where you wish to focus on a single resolution, and the consistency of results across different hardware and resolutions is one of the chief motivations. Unless you are pre-rendering your sprites from 3D models, it may not be practical or desirable to do your pixel art at some theoretical maximum size. I'd also contend that on less powerful, older graphics hardware, the additional texture memory required (considering you are suggesting storing graphics at the maximum resolution and creating a mipmap chain) and the costs of multi-sampling could seriously outweigh the minor costs of the approach I've outlined. As I said in the article, I don't claim this to be any kind silver bullet and there are pros and cons compared to other approaches. It is just a method I have found to be successful when working with native-sized pixel art that I wanted to share. |
||||
|
||||
|
Tape_Worm Member since: 4/21/2000 From: Calgary, Canada |
|||
 Posted - 11/21/2008 2:38:21 AM |
||||
Quote: This is relevant to my interests. However, it looks as though you have a spelling mistake: Quote: I assume you meant loop instead of look?  .Oh internet... so many idiots... so few bullets. Linky goodness: [journal] | [Gorgon] |
||||
|
||||
|
Ravyne Member since: 2/26/2007 From: Kirkland, WA, United States |
|||||
|
Posted - 11/21/2008 3:58:00 AM |
||||||
Quote: Fair enough, and I'll also happily agree that it fits the bill for those wanting to focus on a single resoultion. I may have come off a bit harsh, particularly in the first paragraph, I would have toned it down had I realized it wasn't some no-name from the forums :) I guess I read the article as if it had come from someone fresh who thought they had stumbled on the greatest thing ever, rather than someone more experienced presenting it as an easy solution for a specific set of circumstances. Quote: Also fair enough, particularly for hobbyists and programmer art. Less of a concern when dealing with a real artist though. Quote: Well, the MIP mapping only requires 34% more memory for all levels vs. just the largest size, which is notable but probably not a deal-breaker, however, I applied the term incorrectly. If you can know the size up front it'd be easier and more efficient to just load the necessary MIP level as the sole texture. Also, now that I think about it, multi-sampling is probably overkill, and bi-linear filtering ought to be sufficient. Quote: Understood. As I said, I likely misinterpreted who was presenting the article and likely due to my own supposition rather than the content of the article itself. |
||||||
|
||||||
|
Aardvajk GDNet+ Member since: 3/3/2006 |
|||
|
Posted - 11/21/2008 5:16:32 AM |
||||
Quote: Hey, no problem. I'm perfectly happy for people to criticise as harshly as they want  .I should actually have considered that people would read it this way and perhaps explained the limited application of this approach more clearly in the preamble. |
||||
|
||||
|
Aardvajk GDNet+ Member since: 3/3/2006 |
|||
|
Posted - 11/21/2008 3:57:48 PM |
||||
Quote: How the hell did that happen? P isn't even next to K? Oh well. Glad to hear there is some relevance for you. |
||||
|
||||
|
BornToCode Member since: 4/17/2004 From: USA |
|||
|
Posted - 11/23/2008 5:24:29 AM |
||||
| There is a actually a better solution than this. What you can do is render your scene into a texture at the native resolution and when you create your screen aligned quad to match the resolution you want your game to be in, D3D will automatically stretch the texture to fit the quad. then turn filtering on, you will get the same effect as StrechRect, but it is a lot faster. |
||||
|
||||
|
Aardvajk GDNet+ Member since: 3/3/2006 |
|||
|
Posted - 11/23/2008 9:05:30 AM |
||||
Quote: That is certainly true, although on hardware that only supports power-of-two textures, you might end up wasting a bit of texture memory - at 1024x768, you'd need a 1024x1024 texture. If the native res was 1280x1024, you'd need a 2048x1024 texture, or a 2048x2048 if only square textures were supported. Your approach would be faster though, and would have other advantages (running the final screen through a shader, being able to combine images with alpha blending etc). It would be fairly trivial to adapt my code to do this instead. [Edited by - EasilyConfused on December 1, 2008 1:05:26 PM] |
||||
|
||||
|
Rompa Member since: 10/26/2003 |
|||
|
Posted - 11/24/2008 7:13:15 AM |
||||
| How is this different to just using an orthographic projection whose width and height represent the "native resolution"? In this case, I imagine you would not incur the StretchRect overhead? |
||||
|
||||
|
Aardvajk GDNet+ Member since: 3/3/2006 |
|||
|
Posted - 11/24/2008 12:26:08 PM |
||||
Quote: To be honest, I'm not sure as I haven't tested it. I'd assume that using the ortho perspective would produce similar results to manually scaling the vertices on the CPU, since D3D would be texturing a quad of non-native size. Of the two images I posted in the article, the second is doing no filtering at all, either when rendering the sprites or when doing the CopyRect() so I'd consider the overhead equivalent to when running a D3D app in windowed mode. |
||||
|
||||
|
BornToCode Member since: 4/17/2004 From: USA |
|||
|
Posted - 11/24/2008 11:15:47 PM |
||||
| Yes using a OrthoProjection that represents the final resolution will give you the same result as if you scale up your vertices which even with blending looks very bad. Letting D3D do the scaling for u with Linear Filtering turn on actually looks alot better. |
||||
|
||||
|
Cranky Member since: 9/17/2007 |
|||
|
Posted - 12/22/2008 8:43:48 AM |
||||
| I don't get it. Why don't you just set your viewport to the desired resolution? Especially if you are using orthographic projection that is all you need for resolution independence. Set the width and height of your viewport to like 800x600 and it will properly scale to whatever resolution you choose to run your game in. That way you will have a target resolution (800x600 in my example) for which you create your art assets and let the resolution be handeled automatically by D3D. Sorry, but I kinda don't get what the point of this article is. Either I am missing something, or this "alternative approach" is more complicated than it needs to be. It's just ~2 lines of code to achieve the same effect. I know this because I do this pretty often, I let the program run in windowed mode with 800x600 while the viewport is 640x480, and it gets scaled just the way you described it. |
||||
|
||||
|
Inu Member since: 1/22/2009 From: Wroclaw |
|||
|
Posted - 1/22/2009 6:40:21 AM |
||||
| I used it in my program and it works wonders, but... When my character is near to the middle of the screen it looks quite nice. But when I move it to the sides of the screen it's getting all blurry. It's quite ugly looking then and the anti-aliasing of character changing as it walks is quite bad... Any ideas how I could prevent that? |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
