Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
I should add that you would make those sacrifices for probably dubious benefit. On most systems input can be polled whenever the game wants. Sometimes it's multiple times per frame, other are only every couple frames... And at varying times within the frame. It is definitely common, but by no means universal, to poll after vsync. I had at one point experimentally altered my pce core to do this and it was not a categorical improvement, so I switched it back to the simpler mode of fixed-length frames starting at scanline 0.
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
This is one of those things where your background and mental model really affect how you approach an issue. From a TAS/lua hacker point of view, I understand why 'end the frame at the vertical refresh interrupt/end of active display' makes sense.
If an emulator author did not have that specific background, that is not really the natural way to do things. So just as a simple example, the SMS has 262 scanlines, of which 192 are active display. Vertical interrupt will fire at scanline 192.
So... Frame 0 will execute 192 scanlines, and every subsequent frame will execute 262 scanlines, with each frame starting at scanline 192 and ending at scanline 191.
On other consoles things can get weirder. The pcengine is very configurable regarding the size of active display, and the line on which v-int fires is not fixed. So now we have variable-length frames. So then throw, for example, audio sync into the mix. I may not have generated 1/60th of a second worth of samples in a short frame.
Those problems are all solvable, but my point is that there are non-trivial architectural sacrifices you must make to end the frame right at v-int. I am just trying to explain why an emulator author may have chosen not to do that.
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
ReyVGM wrote:
I understand the sole purpose of bizhawk is to make TAS(es), so faithful graphics or plugins is not really a priority.
I would just like to emphatically state that making TASes is NOT the sole purpose of Bizhawk. I am one of the core developers for Bizhawk and I am definitely more of game-player than a TASer. Although adelikat, natt and zeromus all have a long history with TASvideos so, you know, I'm outnumbered.
Bizhawk is about more than TASing, BUT, sync-stable emulator cores are kind of a requirement. A lot of emulator cores that have never been targeted for movies aren't sync stable because it's easy to make subtle mistakes or omissions that break sync if you aren't explicitly targeting it and testing for it.
Sync stability and determinism is key for just having robust savestates and rewind, so the sync-stable requirement doesn't only benefit TASing.
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
Bizhawk in general, displays whatever the video processor of the emulated system is generating in a 1:1 pixel fashion.
On many systems this is just dandy, on other systems it causes more "issues". PCE/PCE-CD have many games that do funky things with resolution changes and manipulation of the active display region; Genesis has 40-cell and 32-cell mode, as well as interlace mode; SNES has mode changes as well.
We do plan to address this eventually, it just hasn't been the top priority so far.
Whatever solution we implement down the road would probably be toggleable, as there are some situations where Bizhawk's current behavior is kind of nice. For instance, Lords of Thunder PCE-CD has some 16:9 cutscenes and it's kind of glorious to see it taking up your whole widescreen monitor. It can also be good for encoders, who can use more advanced methods to manage the resolution changes.
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
hegyak wrote:
Also, can I get some info on the Genesis/Mega Drive core?
I wrote what there is of the Genesis core. I haven't had a chance to work on it much in the last few months (I did do the ColecoVision core though)... But winter is coming very soon and typically, that's when I don't want to leave my house, and work on emulators! I do still intended to work seriously on that and have it at a production quality in the future. Also, Genesis is my favorite console of all time, so this core is getting finished, it's just a question of when.
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
the_randomizer wrote:
creaothceann wrote:
Bilinear can be done for free by the video card, or with very low performance impact on the CPU.
And yet they removed it because AMD GPUs were apparently "suffering". So by auto-hiding or hiding the task bar, I can use 3x scaling? Why I can't manually adjust the window size to anything I want is beyond me (I don't care about accurate pixel aspect ratio).
Jesus, dude. I never said that.
We are emulating old consoles. Most of us prefer to see pixels rather than blurry crap. Bilinear can be done for free in the video card. We can probably make it an option. I never said we wouldn't, just that we didn't realize anyone actually wanted that functionality.
What I meant was that it was actually difficult to disable bilinear on AMDs, because of an oddness with AMD drivers.
We've tried to be helpful and we're working to address some of your issues. In response you've just been combative. So.. thanks for that.
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
Please post your screen resolution and what ROM you are loading.
Every time the emulator core resizes the framebuffer, the client re-evaluates the maximum zoom size that will fit on the screen.
Many cores initialize the framebuffer to an expected size before any frames have been executed. The game may then change the framebuffer size during it's bootup sequence, so the window will have to be resized.
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
Out of curiosity, what resolution is your screen? Do you have an unusual multimon setup?
Bizhawk window scaling should work fine.... but it has logic that will try to make the window fit on screen. For instance, if I have it set to 5x scale, but the biggest that will fit on screen with that specific console/game/resolution is 3x, then it will use 3x scale.
Switching to fullscreen mode will make it fill as much of the screen as possible. You can do this by double-clicking the display portion of the window.
Bilinear filtering is not difficult... in fact it took extra effort to kill it on AMD cards. We just didn't realize anyone actually wanted it. :D
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
@CoolKirby: Hm, Kirby Tilt 'n' Tumble fails for me too. Hopefully natt can check it out.
As far as the palette goes, once a GB ROM is loaded, open the GB menu -> "Change DMG Palettes..." -> Load...
I use "BGB (lcd green).pal" but I lost the vote for the default. :)
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
Yep, this core is under active development.
It was kind of languishing due to RL.. but I've had some time recently to dedicate to it. RL is still busier than I'd like it to be, but the Genesis core is my priority for the foreseeable future.
But as adelikat said, it's experimental and I wouldn't tas on it, unless it's for giggles.
Sound: yes, as I'm writing a non-MAME-derived YM2612 core, there are still several unimplemented features that cause audio to sound wrong, especially on sound effects. This will be fixed.
No Sega-CD or 32X support yet. Sega-CD definitely on the agenda. 32X is less certain.
It wasn't an accident that we didn't announce anything related to gen for 1.10, as you noted, it still has significant issues, but I'm happy that the work we've done on it is noticed :)
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
zeromus is the TI-83 guy, so I hope I don't foul things up by spreading misinformation.
Dwedit, you seem fairly knowledgeable about TI-83 emulation. If you look at "gamedb.txt", right near the top you will see an entry for TI83 with a md5 hash. You may also notice a PC entry point specified.
If you enable the log window, and try to load a TI-83 rom that we have not supported, it should tell you what the MD5 is. If you add an entry for that MD5 so that it gets recognized as a TI83 ROM, other versions may work?
I'd be curious if you have any success trying this. I don't know if PC entry is different for different BIOS versions.
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
@Sappharad
We were aware that Mono supported Winforms, we also knew Mono had several caveats listed (obviously, P/Invoke based winform stuff won't work).
Bizhawk has been in development for.. perhaps longer than we would like to admit, in the early days we did some test with Mono and at the time, it had trouble running our emulation cores alone, without any UI. This was fairly discouraging to us with respect to mono.
It looks like Mono has improved a lot since then, so hooray!
What did you have to change to get it to run that far under Mono? Even if Winforms works, obviously the DirectX stuff would all fail under OS X...
Experienced Forum User, Published Author, Former player
Joined: 7/22/2010
Posts: 14
@Tub:
The existing cores are all developed from scratch. zeromus and adelikat are the primary authors of the NES core. I wrote the SMS and PC-Engine cores.
We did use the Z80 core from "Cogwheel", although we have modified it and made it our own. Cogwheel is also MIT licensed.
The primary reasons for developing these cores from scratch were 1) We favor MIT/BSD/APL style licensed cores. 2) We were experimenting with the best ways and interfaces to abstract the emulation core logic from the client logic while still maintaining the sorts of rich features people expect.
The emulation cores (in Bizhawk.Emulation.dll) contain no windows-specific code and were designed to be portable. However, the client is significantly complex, so unfortunately just "porting the GUI" to another platform is a major undertaking.