nesdev.com

I just released 0.9.4.

Highlights:
-Added support for 20 more NES/Famicom peripherals (controllers, keyboards, mice, barcode readers, external storage, etc.). All of these can now be properly recorded in movies, and used over netplay as well.
-60.0 fps mode to avoid dropping a frame every ~10 seconds
-Exclusive fullscreen mode support
-On Linux, it runs 25-30% faster than before when compiling on clang thanks to enabling LTO.

Debugger-wise, it adds a lot of small/medium features all over the place and fixes a good amount of bugs as well.
There's been some additions to the Lua API as well.

Wishlist or bug report: I was trying to set a breakpoint on palette writes, but trapping writes to PPU $3F00-$3FFF never triggered.

Ah, good catch - that's probably always been a problem since the palette writes don't count as being a write to VRAM (which is what triggers the breakpoints). Doesn't look like conditional breakpoints can help here, either.
You could most likely get it done with a Lua script, but that's a bit overkill for a relatively common use case. I'll most likely change the debugger so that read/writes to $3F00-$3FFF are trapped like other VRAM accesses.

It was pretty trivial to implement - $3F00-$3FFF read/writes (those done through $2007 read/writes) will now trigger PPU breakpoints properly.
If you grab the latest commit and build from that, it should work.

Hi Sour, I have 2 suggestions when using sprite conditions in HD Pack:

1. When the condition type is spriteNearby, automatically adjust the offset value according to the orientation of the sprite tile. For example in SMB I have a condition of -8 when 2 different sprite tiles are side by side:

<condition>face,spriteNearby,-8,0,58,FF162718
[face]<tile>1,55,FF162718,224,128,1,N

But this doesn't work when Mario is facing the other direction. It make more sense that when the sprite is flipped, the condition is flipped too. Otherwise I need 4 copies of the same condition.

2. Have 2 more parameters to the spriteNearby and may be spriteAtPosition to specify the orientation of the sprite.

Thank you.

Yea, that would make a lot of sense and would help reduce conditionals, like you said. Shouldn't be too hard to implement either, I think.
This is actually already available, but it looks like I forgot to document it completely. There are built-in conditions you can use for sprites: [hmirror], [vmirror] and [bgpriority]. They will only be "true" whenever that particular flag is set on the sprite.

hi, i have a bit of a problem with the controller setup.
I'm using a ds4 wireless controller and i've set up the "circle" button as the "A" button, the "X" as the "B" button, the "triangle" as the turbo A and the "square" as the turbo B and this is what happens when i press the buttons:
circle: A button is activated
X: A and B are activated
triangle: A and B are flickering (the flickering means they are in turbo mode right?)
square: the B button is activated (not in turbo mode)

but it gets weirder if i set the "X" button as the "A" button and i press it only the A button is activated instead of both buttons, in fact the preset controller settings has this in mind with:
square: B button is activated
X: A button is activated
circle: A button is in turbo mode
triangle: B button is in turbo mode

If i try to choose any different button combination i get this weird effect where both buttons are activated, or one is activated and the other is in turbo mode or vice versa.

Is there a way to fix this? i want to be able to play with the circle as the A button and the X as the B button this emulator looks really good and it does have high accuracy and friendlu UI the the controller setup irks me!
So, please? help?
ps:Also is it possible to be able to use the d-pad and the joystick at the same time?

The controller key bindings setup window has 4 tabs - it's possible you have different key bindings in different tabs, which could cause pressing X to activate both A and B - if you selected multiple controller configurations in the setup dialog, you will have key bindings on multiple tabs. Clear them all out and re-do your bindings in the first tab and it should work properly.

You can use the D-Pad and the analog stick together by binding the D-Pad in one tab, and the Analog stick in another, which will allow you to use either of them to move.

It worked! thank you very much!

Hi, I'm working on HD pack editor and will start working on sprites soon, can you give some examples of using these built-in conditions?

Also, I'm using conditions for the title screen of Double Dragon II to show graphics on blank background tiles but the frame rate on my PC is below 50FPS. Can you test to see if you can get full 60? I attached the test pack to this message.

Thanks.

Conditional rules were actually heavily optimized just a few days ago.
kya is working on another HD Pack for CV1 (different from the one he made on Nestopia last year) and abused conditionals and background graphics so much it would slow the execution to ~90fps on my computer for some portions of the game. After optimizing the code, the same HD Pack runs around 250fps. I just tried your pack on my end - it runs at 120fps w/ 0.9.4 vs 190fps as of the latest commit. 4x scale resolution does hurt performance a fair amount though, so it's normal for the pack to run relatively slow.

You can grab a build with the optimizations here: download
Let me know if/how much it helps - hopefully it gets you well above 60fps. I'll try to profile your HD pack when I get the chance to see if I can squeeze a bit more performance out of the HD pack code (but it's been optimized a lot already, so it's starting to get a bit hard to make it any faster)

They work like the other conditions, but will only have any impact if the tile is a sprite. They are automatically available in any hires.txt file, without having to define a <condition> tag for them:
Also, I've added a few new condition types recently. All of these now exist:
-tileAtPosition/tileNearby
-spriteAtPosition/spriteNearby
-memoryCheck/memoryCheckConstant (to compare 2 addresses in memory or an address vs a constant)
-frameRange (to change tiles based on the frame number)

They are not documented anywhere yet, you can check HdPackLoader.cpp to get an idea of how they work.

I haven't had the chance to take a look at changing sign of the offset values when mirroring is enabled (what you asked last time) - I'll try to get this done before the next release.

Thank you very much! The frame rate is back to 60 now. I have a few questions with sprites:

1. Can you add the negation of bgpriority, hmirror and vmirror conditions?

2. Is there a way to specify the relative orientation of the sprite tile in the spriteNearby condition? For example I have sprite tile "[" and I want to replace it with one HD tile when there is a "<" tile to the right or when the whole object is flipped, i.e." [<" and ">]". Then I want to replace it with another HD tile when there is the h mirror of the "<" to the right, ie "[>" and "<]".

3. I added 2 optional Y/N values to the end of the tile values in my editor to represent the h mirror and v mirror flags during copy and paste. Can you add this to the "Copy All Sprites(HD Pack Format)" in Sprite viewer?

Thanks.

Sour, I found a problem with HD tile for sprites, it seems the game is not showing pixels of the HD tile if those pixels are transparent in the original.

I'll take a look - will probably just add the ability to negate any condition by prefixing it with a "!"
Isn't this the same as what you were saying previously? (e.g inverting the sign of the x/y positioning if the sprite is mirrored in that direction?)
OK, should be easy.
This was working in 0.9.4 but doesn't work in the latest build? It's most likely caused by a bug fix that was suggested by kya - I included it, but hadn't really tested it yet. I will need to ask him why he needed this fix in the first place to see if there are workarounds for his case, and revert the change.

No, I'm asking for some way to compare the h/v flip of the two tiles in the spriteNearby condition, not just the relative x/y position.


Now I have tested it with other games, it seems to be the problem with bg priority sprites only.

Thank you for your hard work!