Hi all,
I'm looking for input on what things people want to see that I might be able to work on in BizHawk. Up until now I've just done whatever without any real direction. But now I'd like to try to do things that people are actually interested in.
So, just to be clear, I'm looking for things that people would actually, really use to make a TAS, not just 'it would be cool to have this system in BizHawk.' I really want to focus on something that would actually be used to do some TASing.
I've had a request for arcade PacMan, so I'm thinking of doing that, but I'd still like to hear other ideas.
Anyway, I'm open to suggestions. I do still plan on working on GBHawk but it's on the back burner until I can muster up the motivation to do the audio. I like to be working on a few different thing at once anyway.
One thing that would be nice would to be having access to debugging tools on more cores. Currently, mgba for instance lacks code logger, and trace logger:
Similarly, both NESHawk & QuickNES lacks code-data logger.
vba-next lacks code-data logger.
Sameboy lacks debugger, trace logger, and code-data logger.
Snes9x lacks debugger, trace logger, and code-data logger.
I think the gb core has all however. BSNES has access to all those tools too. Haven't checked other console cores yet.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
How about this?
https://github.com/ekeeke/Genesis-Plus-GX/issues/172https://github.com/ekeeke/Genesis-Plus-GX/pull/173
GPGX merged super accurate new YM emulation code and has already made it optional for libretro, the plan is to merge it into MAME too I think. This is so far the frontier of science, and it's already implemented.
YM3438 was used in some Megadrive 2s, so makes sense to make it optional, as they did, and probably even default to it. This latter part should be discussed at #bizhawk if you feel like merging this thing into our gpgx. Makes sense to also ask natt's opinion.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
It would be great if the libretro MAME core becomes fully functional.
Coleco Adam would also be a nice addition. I will TAS Coleco Supergames - Donkey Kong Junior when that happens.
Thanks for the feedback so far.
I'll look into at least getting Trace Logger going in mGBA, that seems pretty important. I'll probably look at Code Data Logger in NESHawk, although that's less important. The debugger more or less needs a rewrite, so that won't be happening soon.
Our GPGX build is very dated, That one will need natt.
TASeditor wrote:
Output log (dynamic RAM Watch).
Can you give an example for this one?
Still so much to do! 8D
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Fortranm wrote:
It would be great if the libretro MAME core becomes fully functional.
I'm at it. Like I keep saying everywhere, it is my own top priority and a reason I stopped tastudio work. But to do it fully the right way, I need time, because I'm constantly being distracted (by tasvideos duties and sometimes just resting), and because the idea is to first integrate into original mame the parts it needs out of what we need back from it, then we can start either improving the libretro layer, or directly adopt the libretro'd mame core and do whatever we want with it.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Other than I'm still waiting patiently for that mamehawk to become a thing, I think BizHawk is already pretty much a perfect emulator, so there's not much else I can really ask. I thank you guys for all the good work.
I only did request [URL=https://github.com/TASVideos/BizHawk/issues/960]this[/URL] sometime ago, and pointed out the reasons why. I see it labeled as high priority. Think you can do it, Alyosha? or is there someone else already taking care of it?
I only did request [URL=https://github.com/TASVideos/BizHawk/issues/960]this[/URL] sometime ago, and pointed out the reasons why. I see it labeled as high priority. Think you can do it, Alyosha? or is there someone else already taking care of it?
Can I waterbox Mednafen's PCE core? lol no. 8D
I don't know anything about waterbox or mednafen or any of the relevent infrastructure stuff. natt would have to do that one.
I could potentially fix PCEHawk, I've looked into the code base in the past and it's not that much worse then other cores (except for the CD stuff.) It would need a ton of work though starting with a new CPU core.
But, there's really no point in having both in BizHawk. If Mednafen's core was ported, it would 100% obsolete PCEHawk. Properly fixing PCEHawk would by necessity make it on par with Mednafen, so porting it wouldn't be needed at that point.
I think I'll end up doing Coleco Adam next, so at least on my end the PCE can will be kicked down the road a bit longer.
*The user can use many ways to add an output column; from RAM Watch or RAM Search where a button can be clicked to add selected Addresses to the Output log; In TAStudio going to Columns->Output->Add the standard Add Memory Address dialog from RAM Watch will pop up; or using lua
*In the Add Memory address dialog a new item will allow the user to set automatic coloring
*A second window where data is displayed graphically can be opened, too. Displaying values of addresses or lua variables can happen in either of those or both [graph window and tastudio]
*If the user displays a variable or address in both, clicking the corresponding column in the piano roll will cause the graph to have a indication dot on the frame the user clicked on the piano roll. The same can also happen backwards.
*With lua the user can also add "input" columns, where the user clicks or types in numbers which can act as modifiers for the actual game input, like: automatic moving, way point lists
*Double clicking into an output column or in the graph will open "Better" Basic Bot with the address and frame already typed in
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
TASeditor, I think what you're looking for is User Columns controllable from lua? With that you'll have the basic way to put ram watches into such columns, or even complicated formulas ram watch doesn't yet support. Or some text, whatever.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
adelikat and I had a talk about user columns long ago, ask him if he feels like the time has come.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 8/15/2005
Posts: 1941
Location: Mullsjö, Sweden
Not sure if this type of thing counts too for you list:
With the SNES9X core you are able to disable the Transparency effects. This is very useful to have when TASing dark rooms, as you'll be able to easily see anyway.
However, this option does not exist with the BSNES core. If that could be added somehoe, it would be nice.
I echo the prior comments for better support of the various tools, especially trace logging and eventually debugging.
Beyond that, I think it would be good to have support changing controller inputs during input poll events, rather than at video frame boundaries. This might only be helpful for a few systems/games, but it's still an extra TAS capability that's not available on at least some of the cores.
For us real-time folks, finding a means to lower the frame rendering latency in BizHawk 2.x would help a bunch, too :)
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Omnigamer wrote:
I echo the prior comments for better support of the various tools, especially trace logging and eventually debugging.
Beyond that, I think it would be good to have support changing controller inputs during input poll events, rather than at video frame boundaries. This might only be helpful for a few systems/games, but it's still an extra TAS capability that's not available on at least some of the cores.
Trace logging mostly just takes using some disassembler for an existing core, so it's the easiest among what you mention.
Debugging isn't happening soon, because bizhawk fundamentally can't pause midframe at all, nor does it have any idea what it is. Poll-based movies are even less probable, because all cores and all movies (and all their ecosystem) are designed around frame-based movies.
I'm the one interested in both of these, but it takes admin level decisions and efforts to happen. Debugging is becoming a big thing lately, more and more people request it for bizhawk, so maybe it has some chances, but you need zeromus to tell exactly.
OmnipotentEntity wrote:
Updating the Linux and/or MacOSX support is something I would like very much. It would make my life much easier.
p4wn3r is alone in the Linux journey, even though he's made some serious progress. Mac support requires porting the GUI over, and Sappharad is alone in that. So if anyone cares about these, help is greatly needed.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Debugging is definitely one of BizHawk's big weak points at the moment. Lack of subframe inputs is as well.
For in-house cores, the situation is at least tractable. NESHawk for example already has the entire core state available on every single clock tick. I've made progress on making other cores work this way as well. Eventually all in house cores will work this way. As feos mentions though this would require a new ecosystem to have any real use, but it's basically doable.
For ported cores the problem seems to be much more complicated. I'm not sure it's really even practical, and the maintanance burden would likely be quite large. But, these are also the cores that people are most interested in, so that's awkward.
Maybe we are just seeing the limits of this kind of multi-system, multi-source architecture?
Tompa wrote:
Not sure if this type of thing counts too for you list:
With the SNES9X core you are able to disable the Transparency effects. This is very useful to have when TASing dark rooms, as you'll be able to easily see anyway.
However, this option does not exist with the BSNES core. If that could be added somehoe, it would be nice.
In theory you can do this for the SNES by maintaining two sets of PPU registers: one for emulation and one for presentation. The game only sees the emulation bits. The (custom) renderer uses the value of a presentation bit if it was enabled by the user (most won't be), else it falls back to the emulation bit.
With that the user can set the brightness, set the color constant, disable color math (e.g. water, fog), fix palette entries, disable mosaic, fix window positions and logic, and more.
Also, I was wondering about something. Alyosha, could you please add a volume slider for the SMS core? The reason I'm asking this is the same as when they asked you to add it for NEShawk. It's just that when you enable FM Chip, the volume is way too low. You can only hear it properly if you set your PC's volume to max.
Also, I was wondering about something. Alyosha, could you please add a volume slider for the SMS core? The reason I'm asking this is the same as when they asked you to add it for NEShawk. It's just that when you enable FM Chip, the volume is way too low. You can only hear it properly if you set your PC's volume to max.
I'll do this as I rewrite the SMS/GG core to bring it up to speed with the other cores. This will start to happen in the not-too-distant future.
Emulator Coder, Site Developer, Site Owner, Expert player
(3573)
Joined: 11/3/2004
Posts: 4754
Location: Tennessee
jlun2 wrote:
One thing that would be nice would to be having access to debugging tools on more cores. Currently, mgba for instance lacks code logger, and trace logger
If we could implement these things we could get rid of VBA-Next completely. The only the reason it is still an option is that it has more debugging features available.
Because you are a talented developer Alyosha, let me repost this here:
phoenix1291 wrote:
Not really a bug, but is there a way to access the INS / DEL and FUNC keys on SG-1000?
Oh, and are there any plans to integrate the joystick support in addition of the keyboard for the C64 and Apple II cores?
And, if we can talk about dreams, well, it would be a Dreamcast/Naomi core, really functional and without the defects of nullDC/Demul and their descendants...
I hope someday the same crazy work that the Mednafen team does for the Saturn will be done for the Dreamcast.
And if you want to try to work / integrate other cores Alyosha, you can always refer to my posts in the section "Other Emulators", for some, the work is almost already done, some examples: WinArcadia (Emerson Arcadia 2001 and some other) and Altirra -Atari 400/800, 1200XL, 600/800XL, 130XE, XEGS, 5200
Similarly, both NESHawk & QuickNES lacks code-data logger.
vba-next lacks code-data logger.
Sameboy lacks debugger, trace logger, and code-data logger.
Snes9x lacks debugger, trace logger, and code-data logger.
I think the gb core has all however. BSNES has access to all those tools too. Haven't checked other console cores yet.
