Bug in Nestopia's NTSC filter?

[*Spitfire_NES*]

Thanks for posting the fix blargg. Looks good. Most of my errors went away.

The only errors im getting are in NstVideoFilterNTSC.cpp
im getting a bunch of syntax errors. I put up a pastebin cause im pretty sure i did this right:

http://pastebin.com/KKw2xgyE

Ill go back through and check again, the only confusing part was the bits part in this cpp file.

ok now im confused here im down to one error now:

error c2248: NES::CORE:PPU:OUTPUT cannot access private member

this line of code : renderer.bgColor = ppu.output.bgColor;

[blargg]

I'm not sure how you're getting any errors with the patch I posted. That compiled without any errors when I issued make. I'm using Ubuntu 12.04 updated a few days ago.

[*Spitfire_NES*]

I'm not sure how you're getting any errors with the patch I posted. That compiled without any errors when I issued make. I'm using Ubuntu 12.04 updated a few days ago.

Everything is fine until i put this line in: renderer.bgColor = ppu.output.bgColor; in NstMachine.cpp It always says:

error C2248: 'Nes::Core::Ppu::output' : cannot access private member declared in class 'Nes::Core::Ppu'


Im using vs.net 2003 as im adding this into the xbox port. But i dont think it matters what compiler im using does it? lol one more thing, if i change it to:

#pragma renderer.bgColor = ppu.output.bgColor;
or
#pragma warning renderer.bgColor = ppu.output.bgColor;

then it compiles..but i dont think that will work though.

[blargg]

Did you make bgColor a public member of NstVideoRenderer.hpp?

[*Spitfire_NES*]

I followed your list to a t. this is what i added:

virtual ~Filter() {}

virtual void Blit(const Input&,const Output&,uint) = 0;
virtual void Transform(const byte (&)[PALETTE][3],Input::Palette&) const;

const Format format;
+
+ uint bgColor;
};

struct State
{
State();

***************
*** 234,245 ****
--- 237,249 ----

Filter* filter;
State state;
Palette palette;

public:
+ uint bgColor;

Result SetBrightness(int brightness)
{
return SetLevel( state.brightness, brightness );
}

But if it compiles with a #pragma, im not sure why it would with it but thats the only way i can get it to. Am i missing anything else?

[blargg]

I think that the #pragma is basically commenting it out. #pragma whatever is a compiler directive that is handled specifically to the compiler.

And wow, sorry, apparently the makefile isn't setup up right or make just doesn't work at all like I thought. When I modify e.g. NstVideoRenderer.hpp and issue make, nothing is recompiled. So I need to apparently do make clean to even be sure it compiles changed files. Ugh.

OK, one addition:

Code: Select all

diff -c6 -r source-orig/core/NstPpu.hpp source/core/NstPpu.hpp
*** source-orig/core/NstPpu.hpp	2012-11-28 15:23:14.000000000 -0600
--- source/core/NstPpu.hpp	2013-03-18 20:36:39.582196143 -0500
***************
*** 409,421 ****
--- 410,424 ----
  			Regs regs;
  			Scroll scroll;
  			Tiles tiles;
  			Chr chr;
  			Nmt nmt;
  			int scanline;
+ 		public:
  			Output output;
+ 		private:
  			PpuModel model;
  			Hook hActiveHook;
  			Hook hBlankHook;
  			const byte* rgbMap;
  			const byte* yuvMap;
  			Oam oam;

[*Spitfire_NES*]

thanks that worked, could you do me a favor and attach what your NstVideoFilterNtsc.cpp file looks like?

The reason why i ask is becuase i have in my code the scanline xbox stuff at this point:

for (uint y=HEIGHT; y; --y)
}
NES_NTSC_BEGIN_ROW( &lut, phase, bgcolor, bgcolor, *src++ );

Pixel temp;
// 50%
#define PIXEL_OUT( i ) \
NES_NTSC_RGB_OUT( i, temp, BITS );\
dst = temp;\
temp >>= 1;\
temp &= 0x7BEF;\
reinterpret_cast<Pixel*>(reinterpret_cast<char*>(dst)+pitch) = temp;

and want to make sure i have everything in the right place. Since some of this code starts right where we added the scanlines stuff the other day.

[*Spitfire_NES*]

At some point in the future is there a possibility to be able to extend the overscan on the sides a little bit more with the ntsc filter? Not sure how easy/hard it would be.

[thefox]

At some point in the future is there a possibility to be able to extend the overscan on the sides a little bit more with the ntsc filter? Not sure how easy/hard it would be.

Only semi-related, but does anybody know if the background colored "borders" (that I assume you're referring to) are affected by pointing PPU address in the palette area while rendering is disabled?

[blargg]

Yes, they are; my flowing palette demo paints well into horizontal overscan.

[*Spitfire_NES*]

Is there a way in the future to extend the sides a little more?