tinyfiledialogs was a good band-aid, but it was always kind-of a
janky solution. Mind-you, this file-browser I threw together ain't
the nicest either, but at least it's within the main SDL window.
Now that the menu is in place, it's possible to switch between
games without restarting! Also, opening the file-picker pauses
ANESE, so that's good to finally have.
Thanks a bunch to cute_headers for a neat little cross-platform
directory traversal library, and also SDL_inprint for a quick-and-
dirty embedded font for use in the menu. Not having to bring-in
SDL_ttf is a huge load off my shoulders.
Oh, and i've noticed that `gui.cc` has started to get bloated, so
now I need to get around to cleaning it up weeeeee.
It's kinda jank, but hey, it works?
The serious issue is that it relies on the SDL2 dylib installed
from homebrew, and if that verion ever gets bumped, RIP.
fucking windows REEEEEEEEEEEEEEEEEEEEEEEE
fopen() silently converts line-endings on windows, and since I did
not explicitly say I was wiring binary data, it solently bloated my
sav size.
Literally fixed by adding a single char: "w" -> "wb"
Also cleaned up some things that were causing compiler warnings.
Nothing mission-critical, but its nice to keep things clean.
I shuffled A LOT of files and functions around.
Two big things in this change:
1) There is no more Cartridge class.
I wrote that class when I was just starting out with ANESE, and
before I had a good idea of how NES hardware operates. As it turned
out, the Cartridge class essentially just mirrored the Mapepr
interface! The only real functionality it brought to the table was
routing the raw ROM data through into thte ROM_File class, which
would parse the ROM data.
I restructured all that.
File parsing shouldn't be under the /nes directory, since the nes
couldn't care less if the ROM file is iNES, NES2.0, or whatever
other formats there are. All the NES cares bout is that there is a
ROM_File struct with good data in it.
So, I moved the specifics of file-format parsing out of /nes, and
put them under /ui/fs/parse_rom.h.
I've changed all the interfaces that used Cartridge to just use
Mapper, and pushed the construction and ownership of the ROM_File
struct to main() for now. Which leads to number 2...
2) Main doesn't have any filesystem code anymore.
Yep, i've moved all the code required to read roms (and general
files) into /ui/fs/load_rom.h, so all main() has to do is pass the
path to a ROM / file, and it gets back a fully validated ROM_File
struct, or filled data pointers!
The code could still use some work, reorganizing the freestanding
functions into classes / namespaces, but this is a big step-up
from just having it all cluttering up main()
----
So yeah. Not much on the emulation front today, mostly just
improving code-quality.
(i'm also just procrastinating having to implement MMC3 lol)
I started looking into how to make the APU, and boy, let me tell
ya, it's going to be a massive undertaking.
Undoubtedly a fun undertaking, but still...
Since it's a personal goal to get Super Mario Bros 2 running
before new years (after all, that game has won
game-of-the-year i don't even know _how_ many years in a row),
i've decided to just use Blargg's venerable `nes_snd_emu` library
for now.
It took some wrestling, it it's in, and it works!
Almost.
I still don't know why enabling the Frame IRQ kills most games, but
i'll look into that!
Welp, on to bigger and better things!
Namely: MMC1, which will give me Zelda and... Super Mario Bros 2!
added some 3rd party libs today! man, cmake is pretty complicated,
so it took a while to figure out, but hey, it seems to be working,
so that's good!
I added two libraries:
- `tinyfiledialogs` to handle opening a file-select window (that
varies per platform) in the case that no rom is specified on the
commandline.
- `args` handles parsing and validation of commandline arguments.
As I start to add more and more flags, it's probably a good idea
to set up a more extensible framework to configure ANESE
Oh, and FYI, this is all me procrastinating working on the PPU.
weeeeeeee!! isn't emulation fun?!
yeah, i'm a bit of a dummy. I was building ANESE in _Debug_ config
with MSVC, and wondering why it was so bloody slow. Well, no shit
it's slow, it's not even being optimized!
I've set all the flags properly now, and have killed the windows
clang portion of the cmake script. Clang is a massive pain in the
ass to set up on windows with visual studio, so finally getting
MSVC to run ANESE properly is awesome.
At this point in development, MSVC is not generating optimized
code for ANESE, and struggles to hit 60 fups.
Clang makes beautifully performant builds though :D
this isn't going well.
i've decided to forget accuracy for the moment, and to focus on
just getting the damn thing working with simple stuff, like the
Zelda title-screen demo, or Donkey Kong.
But fuck me man, this shit is complicated.
I'm going to bed now, and hopefully, next time I work on this,
i'll be able to get sprite rendering working properly.
hell, maybe i'll just scrap that, and instead focus on rendering
the background properly. I have a feeling that's going to be
a bit easier...
Right now, I really want to give up, and call it quits on this
project, because holy crap am I getting annoyed.
But then I remember that one day soon, everything is going to
work, and all this effort will have been worth it.
I hope that day comes soon.
I wasn't planning on reworking interrupts today, but one thing led
to another, and... yeah.
All I really wanted to do today was get a Palette Table debug view,
but for some reason, it isn't being populated! I had a suspicion
that maybe implementing interrupts would make something click, but
alas, interrupts are in, and no data is being written to the
palette tables :(
I'm just going to leave it be for now, and hope that as more of the
PPU comes together, it will just start working.
