Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Bizhawk doesn't have any limitations like that. I'm not much of a TASer, but I know that when you start getting into the nitty gritty details of frame by frame tas precise input in games, there can be a lot of surprises in what the game will and won't accept. Might check if there's a game thread on this in the snes forum?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Quick movements would be ones that are just held for fewer frames. If it's quarter circles and stuff, sometimes the games require any of the 8 cardinal directions passed to be registered, so for instance a half circle forward might (depending on game), need B, DB, D, DF, F in sequence.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I worry about changing the cycleCounter that the emulator uses internally; touches a lot of things. Wouldn't it be easier to change just the tracelogger code?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Alyosha wrote:
Trace Logger gives the same cycle counts for both cores. Looks like gambatte's count is being cut in half for the lua function somehow, I'll look into it.
EDIT: Yeah, Gambatte is using master clock rate (~4MHz) / 2 for TotalExecutedCycles. This comes from the audio code it seems like? Not sure yet how to get the count it uses for Trace Logger.
The frame advance external API uses the 2mhz notion of master clock, not a 1mhz, 4mhz, or 8mhz, because gambatte's audio code has always worked that way, so it was natural for that. Looks like a lot of CPU stuff internally uses a 4mhz master clock. Tracelogger using 4mhz when frame advance already used 2mhz was just an error for sure.
I worry that the tracelogger's notion of timing might be busted after a while; doesn't gambatte's cyclecounter variable occasionally reset backwards to account for 2^32 rollover?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I don't think there's a right or wrong answer here. TotalExecutedCycles should be relative to a "master clock", but the rate choice for the master clock is somewhat arbitrary, and as pointed out the architecture of the GB makes it more ambiguous than some systems what the right master clock rate is. Ideally we should be exposing a MasterClockRate or similar field as well.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Of course. It's fun, isn't it? These are all quite different and each would need its own palette.
1. Gameboy color being viewed in broad daylight
2. Gameboy color being viewed in incandescent room light at night
3. Gameboy color being viewed in flourescent room light at night
4. Gameboy color game on GBA
5. Gameboy color game on GB Player
There's an option in Bizhawk called "GBA" that attempts to model #4, but I don't know how good it is.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
ThunderAxe31 wrote:
And the objectively correct palette for GBCinGBA mode is Vivid, as it reflects to what we already use for GBA movies.
Be careful with the word "objectively", it's sharp.
The screen on a real GBA was most definitely not sRGB perfect (which is the implied color space when you use vivid; it just upconverts RGB15 to RGB24 in the standard way and then assumes your monitor is sRGB perfect).
For objective evidence, I submit the game Final Fantasy Tictacs Advance, which has a color configuration option with three choices: "LCD A", "LCD B", and "TV", with notably different palettes. So developers and artists who did their research then were convinced that there was a significant difference even between GBA, GBA SP, and GBA Player, let alone whatever the honks we're doing in an emulator.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
If memory serves me correctly, the SaveRAM file is the internal backup ram concatenated with the external backup ram. (I do not remember which order the two are in).
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Cyorter wrote:
Now I know what's PikachuMan's problem with video dumping.
I was trying to dump video with ffmpeg writer, in the newest release it was updated, so in MP4, it tries to dump with libvo_aacenc, but it isn't a selectable codec anymore in ffmpeg, so I tried to change it to aac but at the first frame recording I notice the change doesn't applies (still uses libvo_aacenc), the only customable format is the custom (obviously), any change to other options doesn't do anything. So for encoding, the only change must be from libvo_aacenc to aac, the others work perfectly.
For MP4 encoding must be -c:a aac -c:v libx264 -f mp4.
PikachuMan, use this in the custom option while this is solved (or not, do it forever from now).
Fixed; all three codec presets that were using libvo_aac now use aac. If the UI is allowing you to customize the non-custom presets (or type something in there to make it look like you're doing that, then that's a different bug.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Aktan wrote:
If your goal is to have the best quality on YouTube, I still think capturing the original interlace signal and then using software deinterlacer like QTGMC would be better quality.
Remember that very few games will have genuine interlaced content (each field represents the scene at a different point in time). This is because rendering in this way is very hostile to slowdown: If you're not able to make time on rendering a new field, what do you present this field? The previous field's buffer? But that was for a different location (either one line higher or one line lower than the current one), so the user will notice the jump up or down as a very visible studder. Two fields ago (assuming you still have that in a third buffer somewhere)? But that's actually behind the previous field in time, so the user will notice a huge motion jerk. No, what you actually want to show is the scene that you just presented, but the other "field" for it. But you never rendered that. Whoops!
That's why games for consoles in interlaced mode usually render a full progressive image, and then present it for two fields, getting both the bottom and top. If you end up behind, you just show an old field again. There will be slight studder and slowdown as there always is with lag, but with none of the jumps or jerks from the above situation. So, the best way to deinterlace those is to simply recover the original progressive stream by looking at adjacent fields and seeing which ones line up.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
upthorn wrote:
Technically, the only thing keeping camhacks from working on BizHawk is that nobody has written them into BizHawk.
I investigated the feasibility of rewriting the sanic camhack tools in lua for BizHawk once and quickly gave up. The code was a giant ugly mess of junk and I didn't really have the heart to get into it...
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
feos wrote:
We can't afford trying every image in the world hoping that it results in optimal outcome.
Of course we can. Just reverse-engineer the thing. It probably does something like this:
raw read some arbitrary sector(s) early on the disk
hash the data
use that hash to seed a prng
use that prng in a random character creation algorithm
If we knew that and how it works, then we could make custom CDs just for the job that contained a few garbage sectors of garbage, and distribute them.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
sounds about right. I think the snes gets more complicated in interlace mode, but few games use that.
Whatever, all of those digits are just mathematical masturbation. Would need hours of gameplay to drop or dup one frame. More stated accuracy than the accuracy numbers on the crystals, too, so better play in a temperature controlled 68 deg f room.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
As a former encoder and publisher, I believe that a completely open source project is essential to anything suitable for TASVideos. I say this not from idealistic or moral grounds but from practical grounds. Syncing, judging, encoding, and publishing runs is incredibly difficult. The open source nature of the emulators we support has allowed our community to improve many of these emulators long after the original authors abandoned them.
I advocated Doom demos for TASVideos because I felt it could be held to the same standard. It is completely open source, and has a long history of support of many of the useful goals of TASing, including years of research and fixes to determinism. I myself added some video dumping code to PRBoom+ before I came here, which I would not have been able to do without the code.
I don't see add-on tools for individual games like worms or towerfall meeting this standard unless the entire game is open source. 5, 10, years from now everything will be derelict and abandoned and it will be near impossible for users that want to play the runs themselves to do so, or for new encoders to reencode to the newest standards. Closed source games makes the question of cheating much more difficult as well.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Depends on the system. Some of the Bizhawk cores support this: You'll need to have all of the CDs selected ahead of time, but you can switch between them and even switch to ejected/empty in some cases while emulation is running
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Alyosha wrote:
Fortranm wrote:
Each archive contains two ROMs; the original ROM, and a version with a fixed header that allows it to run on normal Game Boy hardware and most emulators.
This is from the description of the recently surfaced Pokemon Gold/Silver demo rom. It would be nice if GBHawk can run the original rom, just saying.
It can't run on normal Game Boy hardware? If that's the case then it shouldn't run in GBHawk either.
What did the original run on then?
If the information is correct and it really is just a fixed header, it very well may have run on real hardware. I don't think the GB bios actually verifies mapper information from the header? It just so happens to be correct on all licensed titles.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
RaijinXBlade wrote:
I imagine it's likely because it's not running at full speed like the other systems you mentioned.
The Saturn has a notoriously complicated hardware architecture, so anything trying to emulate it with any sort of prioritisation for accuracy is certainly not going to run well unless you have good PC hardware.
Unfortunately, this is the case. In addition to the Saturn being complicated, our Saturn emulation core incurs some additional overhead from the method used to take savestates and some additional overhead from lack of time on my part to maintain it.
To see if speed is the issue, try running the core with all throttles off and FPS display on. If it's not making at least 70-80fps unthrottled, it's going to have troubles running at full speed.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Hold the phone. There's code in Bizhawk to hook up the tilt sensor and the vampire sensor to the mgba core. Is that not working? If so, it's probably a 5 minute fix for me. Did someone report this? I don't see anything on the issue tracker with "tilt" in it.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
phoenix1291 wrote:
Is it possible to implement a function for the screen orientation?
It would be very useful for games that change the screen orientation during the game, like Makaimura on WonderSwan.
Wonderswan has a keybind to flip the orientation. Is that working for you? If not, what do you want that it can't do?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
Alyosha wrote:
Looks like a problem with the triangle channel linear counter. Should be an easy fix.
I'll look into it in the next couple of days. Thanks for the report.
EDIT: fixed
Sweet! Thanks for that. Now NesHawk is more than 100% accurate!
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I'm not sure what I'm supposed to be seeing (or hearing?); crappily edited youtube videos with no explanation aren't the best means of discourse.
Still, I don't doubt that there could be some emulation flaws; the 100% is just 100% of some random set of tests, and no one is claiming NESHawk is perfect except in your strawman. Post a detailed bug report to the github issue tracker if you want to help.
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
A PCEngine has no soft reset. There's no button or signal for that. As MESHUGGAH says, many games use certain combinations on the pad to implement a 100% software controlled soft reset, and those should work in PCEHawk.
Hard reset would just be pulsing the power entirely, and so would only be useful for games with persistent saving, but it very well might help in some of those. Is there an instance you need it for?
Editor, Emulator Coder, Experienced Forum User, Site Developer
Joined: 5/11/2011
Posts: 1108
Location: Murka
I have a feeling you'll still need some sort of option or different codepath. For rendering on things like GB/GBA, you really need very small pixel perfect fonts with no AA, but on hi res you do want AA and vector fonts. But good luck on getting them both under one umbrella.