first commit in a _long_ time, and it's just because I installed a
fresh linux distro and wanted to see if ANESE compiles on it.
It does, but I noticed a couple of warnings and bugs, so these are
some quick fixes.
looks like I had an unintended fallthrough in my bgr_fetch routine.
not sure how mission-critical this is, but maybe it fixes stuff?
other than that, g++ helpfuly noted some other silly errors and
unused vars, so I cleaned those up too.
lastly, I removed some code that skipped the first directory
returned by cute_files in the menu component. Not _super_ sure why
that was there in the first place, but directory traversal now
works on some more linux distros (such as the one I am running)
that's it then, the final piece.
You can play games, record scenes, and boot games back up with the
recorded map.
It's not perfect, _far from it_, but it works!
There is still a lot of work to do, improving heuristics and such,
but I think wideNES is at a point where it can be merged into
master and shown off a bit :)
exciting!
wowie this was a trickyboi to figure out, but I think I managed to
get a decent-working solution.
The algorithm consists of 2 parts: 1) detecting scene transitions,
and 2) figuring out if the new scene is a duplicate.
Part 1) was solved using perceptual hashing, and watching the delta
of the frame hash between frames. When it spikes, odds are that's a
scene change.
Part 2) was a bit trickier, but boils down to hashing every frame
and associating it with a scene + scroll values. That way, when a
scene transition is detected, I can check the hash-maps to see if
the "new" frame is actually one I've seen before.
There is a bit of extra work that gets the technique working with
elaborate fade-in animations / animated backgrounds, but it's not
magic or anything.
What's left?
Well, 1) needs to be improved, since the current delta threshold
value i'm using has been pulled out of thin air, and while it gives
reasonable results on many games, ideally, it should be more robust
2) is pretty good though!
All that I need to do now to be super happy with it is serialize
the scene data and enable loading / saving it to disk! Once that's
done, the initial vision of being able to automatically map out a
game will have come true!
exciting!
Perceptual hashing... that's the cool shit.
I mean, my "advanced" perceptual hashing algorithm is really dumb
right-now, literally just taking a sum of all pixels in the frame,
and yet, it's good enough to detect when a _bunch_ of pixel-values
change from frame-to-frame. I bet that with a bit more tweaking,
like normalizing the frame wrt. the palette, I can get some even
better results.
I also have a "true" hashing implementation, where each frame gets
a unique hash. It seems to be realtively collision-free. That said,
there are times where there are collisions, namely in Metroid,
where the game likes to reuse screens. I'll have to figure out how
to deal with that...
So, what's the next step?
Whenever a scene changes, take the hash of the new screen, and see
if it matches up with anything we've seen before.
That way, we can have "re-enterant" scenes, which is a key to being
able to save/load tiles!
didn't think i'd be able to pull it off, but Zelda seems to scroll
fine now! All I needed to do was sniff the PPUADDR register, since
after all, PPUSCROLL and PPUADDR both point to PPU t/v anyways...
I also bunched-up the heauristics a bit better, hopefully making
the code a bit nicer.
before showing off my work, the big thing that needs to get done is
scene detection. Yeah, heuristics are cool, and fun to implement,
but I can do that later. What I _should_ focus on is getting scene-
detection working, and afterwards, saving and loading, since that's
the killer feature (imo)
It's going to be tricky, but i've been reading-up on perceptual
hashes, so that might be useful?
Alternatively, I could sniff what games tend to write to the PPU
during "scene transitions" and see if there is anything I can use
to fingerprint scenes...
yeah... i'm not entirely sure of the thought process I had with my
old method... It worked, but it wasn't very clean, or intuitive.
This new method is a lot cleaner, and makes a lot more sense.
Moreover, it enables me to add the 16x16 block sampling
functionality, which is awesome, since animated blocks tend no to
get "banded" or "smeared."
basically, instead of using a referance to a pointer, i'm just
using a double pointer. Aside from looking nice, it also gives my
NES class a more C-like interface, which will come in handy if I
ever want to export ANESE as a libretro core.
I think i've settled on how to expose the inner workings of ANESE.
1) callbacks at key points
2) direct-acess to member variables using _functions.
Anything in ANESE core that starts with an underscore is something
that is _not related to NES emulation_, and is purely there for
instrumentation / debugging.
gui.cc is now _almost_ module agnostic, which is awesome!
The last thing to do is to figure out what's the best way to route
input from the wideNES window to the main window, as the current
solution of _always_ passing input to the emulator is jank af.
I also finally got a ROM loading / unloading solution i'm happy
about. essentially, load/unload have become utility methods on the
shared-state struct.
no more SDL in ANESE core!
Also, with this commit, I can merge back into master, since wideNES
is hidden behind a flag :)
Before I do that though, a bit of cleanup is in order :)
to fix the smearing in MMC3 games, I needed to change which scroll-
values to use depending on if the status bar is at the top / bottom
of the screen. If it's at the top of the screen, then I need to use
the scroll values recorded _after_ the IRQ is fired. If it's at the
bottom of the screen, then I need to use the scroll values recorded
_before_ the IRQ is fired.
Also, turns out with my newer, better sampling methods, I don't
need to use that janky "true 0" filter anymore, so that's gone!
Lastly, I removed all wideNES specific code from the PPU, instead
adding scroll callbacks (so I can register values on my end)
I wanted to use SDL_inprint in multiple renderers, and that meant I
had to modify the library a little bit.
also, I just noticed that the smearing issue is back! Not as bad as
before, but MMC3 games seems to be affected when the screen scrolls
upwards...
wierd.
If a human can figure out which parts of a screen to chop, why
can't wideNES do it automatically? Well, it can! sort of...
I implemented a couple of heuristics that use the state of the PPU
and the Mapper to "guess" what padding values make sense.
For now, I only have 2 implemented:
1) Check if the bgr-mask column is enbled on PPUMASK
- if so, add 8px of padding to the left of the screen
- many games that mask the left also have artifacting on the
right, so mask off 8px on the right too.
2) Check what scanline the Mapper IRQs happened on
- mask-off the rest of the screen
- many games use the Mapper IRQ for status-bars (smb3, kirby)
Now, these are not perfect heuristics by any means, with exceptions
rampant. eg: Lode Runner doesn't have any graphical artifacting on
the right of the screen. eg2: MegaMan IV uses the IRQ for different
reasons, unrelated to status-bars.
Nevertheless, they do a decent job with many games, smb3 and MC Kids
work flawlessly. Moreover, Metroid and Super Mario Bros work great
too, automatically having the entire screen captured (no padding)
While implemeting this feature, I decided to cleanup how I was
reading the NES's state, and implemented a basic Callback system,
enabling arbitrary methods to hook into important parts of the NES
lifecycle. eg: I added callbacks whenever a mapper fires an IRQ,
and a mapper whenever a PPU frame finished drawing (scanline 240)
This had the happy side-effect of fixing my smearing issues, as it
makes a lot more sense to sample the NES's state _before_ the NMI
handler happens, as that state the one that resulted in the current
frame! Just like that, every game I tested worked flawlessly, no
smearing to be found!
Also, this lays a much more solid groundwork for implementing a
proper debugger! It should be easy to take the nastyness that is
ppu_debug.cc and extract it into it's own GUI module! That way,
there will be _no_ state of SDL in ANESE core!
I still haven't figured out the smearing issue, but I _did_ figure
out how to greatly-improve compatibility with many titles!
I added the ability to "pad" the screen, cutting-off any artifacts
at the edge. This means that with a bit of tweaking, games like
SMB3 and MC Kids work near flawlessly!
It _should_ be possible to guess "good" padding values for games by
using some heuristic that relies on current mirroring mode, scroll
direction, and if the PPUMASK is on...
I also updated the README some more, putting a "teaser" for wideNES
on the main page, but splitting off the details into it's own page.
Yeah, it's about time I get wideNES out of the main NES module, it
was starting to make a mess. Instead, wideNES now has it's own
window, with it's own SDL rendering context.
I'd actually like to refactor the emu module some more, possibly
splitting it into sever different ones. eg: emu_core for the main
NES console + frameloop, emu_controls for handling input / movie
support, and take the file i/o and throw that into the menu module.
I'll get around to it eventually :)
Plus, if I can modularize things a bit more, I can merge this
branch into main, and put the entire wideNES module behind a flag!
-----
smearing.
I'm very confused.
I tried a bunch of stuff, and one thing I stumbled on was that if I
use the _last_ frame's scroll values, then I can fix smearing in
some games (smb2, metroid) at the expense of adding it to other
games (smb1)
I'm really not sure why that's happening, but i'll try investigate.
-----
Oh, and I added basic pan/zoom to WideNES, so you can scroll around
the viewport now :D
the last tile-based approach was a very jankyboi, with oversized
tiles that were clipped using SDL, with no memory of a framebuffer.
not great, not great at all.
I revamped the system so that each tile has it's own internal
framebuffer, and updates occur by copying chunks of the main nes
framebuffer into the 4 tiles the screen currently overlaps.
this works really well, and has major upsides like
1) no more black-strips
2) possiblity to save tiles (easy access to framebuffer)
3) easier to work with
I'm still running into some issues though, the biggest of which is
that most games that scroll end up "smearing" the background...
It's hard to explain in text, but if you load up SMB2 or Metroid
for example, whenever you scroll, the stuff you leave behind has
duplicate columns, resulting in a "smearing" effect.
I'm at a bit of a loss as to what might be causing it, as the
scroll-register values being sent to the PPU by those games seem
sensible...
I'll try to fix it somehow lol.
