nesdev.org

Posted: **Tue Jun 06, 2006 5:56 am**

My nes emulator which use DirectX looks faintness. The SDL version don't have this problem. Why and how to fix it ?

http://ershu.3q5.com/UUAuth/2006-6/66149366.bmp
http://ershu.3q5.com/UUAuth/2006-6/66306937.bmp

Thanks you for answer.

Posted: **Tue Jun 06, 2006 6:33 am**

It looks like you've got pixel interpolation turned on in your DirectX surface, and the window is not exactly 256x240 pixels in size.

And please post .png files instead of .bmp files.

Posted: **Tue Jun 06, 2006 6:35 am**

Did you set the correct surface and window sizes in DirectDraw/Direct3D?
My emulator uses DirectDraw 7.0 and does not experience the blurriness shown in the first screenshot (unless I stretch to 2X size, but that's normal).

Are you rendering a 256x240 image at 100% size, or a 512x480 image at 50% size? If you are doing the latter, it is possible that DirectDraw/Direct3D is smoothing the image during resizing while SDL is not.

Posted: **Tue Jun 06, 2006 6:47 am**

That looks like Anti-Aliasing to me. Try creating the surface in system memory. It'll be slower, but it will solve the problem. Btw, you have a very bad dump of SMB (as opposed to a bad one).

Posted: **Tue Jun 06, 2006 6:56 am**

WedNESday wrote:That looks like Anti-Aliasing to me. Try creating the surface in system memory. It'll be slower, but it will solve the problem.

It shouldn't be necessary to create the surface in system memory - that usually only prevents it from being smoothed when stretching.

WedNESday wrote:Btw, you have a very bad dump of SMB (as opposed to a bad one).

Posted: **Tue Jun 06, 2006 7:17 am**

(opens GIMP and measures key points)
It is being stretched. It looks like just over 254.5 horizontal pixels of the 256 are being displayed, stretching distances and triggering your video card's linear interpolation. The distance from the top of the M in MARIO to the top of the cracked blocks is also slightly greater than it should be: 193 pixels instead of the expected 192. Try loading up a ROM that just displays a grid so that you can use it for calibration.

Posted: **Tue Jun 06, 2006 8:32 am**

The window is 256*240 exactly. See this Spy++ screenshot
http://ershu.3q5.com/UUAuth/2006-6/66141827.bmp

I creat a 256*240 bytes buffer myself. And a 256*240 Back Surface. At end of every frame, I copy data from my buffer to Back suface, then use lpddSurMain->Blt to blt the rect {0,0,255,239} to screen.

My GB emulator has the same problem

http://ershu.3q5.com/UUAuth/2006-6/66215147.bmp
http://ershu.3q5.com/UUAuth/2006-6/66564484.bmp

Why? When using SDL, my coping process is not modified at all. But it looks great!

Posted: **Tue Jun 06, 2006 9:11 am**

ershu wrote:I creat a 256*240 bytes buffer myself. And a 256*240 Back Surface. At end of every frame, I copy data from my buffer to Back suface, then use lpddSurMain->Blt to blt the rect {0,0,255,239} to screen.

Does the problem disappear if you blit {0,0,256,240}?

Posted: **Tue Jun 06, 2006 9:33 am**

finally!!!! I find why!!!!
The problom is not about the source rect, but the destination !!!

My old dest RECT was calculated as:

Code: Select all

RECT rect;
GetWindowRect(m_hwnd,&rect);	
rect.left   +=   m_GSM_CXBORDER;
rect.top    +=   m_GSM_CAPTION+m_GSM_CYBORDER+m_GSM_CYMENU;
rect.right  -=   m_GSM_CXBORDER;
rect.bottom -=   m_GSM_CYBORDER;

Now I modify it to:

Code: Select all

RECT rectDst;
POINT pt;
rectDst.left = 0;
rectDst.top = 0;
rectDst.right = m_nScreenWidth;
rectDst.bottom = m_nScreenHeight;
pt.x = pt.y = 0;
ClientToScreen(m_hwnd, &pt);
OffsetRect(&rectDst, pt.x, pt.y);

The two result is not the same! first one is not accurate! Now it works!
http://ershu.3q5.com/UUAuth/2006-6/67970237.bmp

But if I want to implement scale 2 (512*480), using DX blt function to stretch it still look paintness. Did everybody writes your own function to scale 2 ??

Posted: **Tue Jun 06, 2006 11:19 am**

I implement a software scale 2 filter and it looks great now.

Thanks for everyone's advice~

Posted: **Tue May 13, 2008 7:31 am**

*Bump*

I'm having exactly the same problem as this guy. I have an offscreen surface of 256x240 big and the destination surface is 512x480 big. Unless I create the surface in system memory (which results in a huge cost for my emulator's efficiency), the result is a blurred (is it called nearest neighbour interpolation?) picture, just like his. How can I switch this feature off with DirectDraw?

Posted: **Tue May 13, 2008 7:42 am**

If you use DirectDraw to blit a 256x240 pixel surface to a 586x480 pixel destination, is the result any more blurry than an NES console connected to a TV?

Posted: **Tue May 13, 2008 8:20 am**

Maybe he likes the crisp 1:1 emulator look.

I don't know how to turn that off with ddraw. Over here I use a d3d renderer by default, that does support turning on/off bilinear filtering.

Posted: **Tue May 13, 2008 9:08 am**

tepples wrote:If you use DirectDraw to blit a 256x240 pixel surface to a 586x480 pixel destination, is the result any more blurry than an NES console connected to a TV?

You mean 512x480. And yes, I do like the crisp 1:1 emulator look.

And no, I'm not converting to D3D/OpenGL/SDL.

Posted: **Tue May 13, 2008 9:22 am**

WedNESday wrote:
tepples wrote:If you use DirectDraw to blit a 256x240 pixel surface to a 586x480 pixel destination
You mean 512x480.

What I mean is that pixels of the NES PPU are not square on NTSC or PAL. (See further discussion.)

If you want an even crisper emulator look, try post-processing your rendered image with Scale2x

nesdev.org

Simple Question About the DirectX

Simple Question About the DirectX