Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Is there someone who can please test kirby's tilt 'n tumble on GBHawk and let me know what they think of the controls?
If someone can just do a quick test and make sure nothing is broken I would appreciate it (I can't do it myself at the moment.)
(you need to set the controller to tilt in the GB -> sync settings menu and reboot the core first.)
tilt X should be bound to mouse X
tilt Y should be bound to mouse Y (maybe inverted.)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'm starting to look into nes console verifications again. For now I'm still working along the lines of syncing some runs to mesen start up timings. The first successful one so far is nightshade:
http://tasvideos.org/userfiles/info/71845677054219302
I've also has a few setbacks with some games behaving differently even though I otherwise match mesen's start up timings, so there is definitely more to look into.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I wanted to make a quick note about sync here. This run won't sync in the current dev build due to emulation changes. It will however sync with different initial conditions. I'm not sure yet what initial conditions I will set NESHawk too for the next release. Since this run works on hardware the initial conditions for it to work in the current core (which is zero cpu offset) seem like a good choice, but I'm still doing a lot of testing.
Unfortunately NES power up state varies widely, so picking one or another state will inevitably cause some runs to work and others not to, just a choice that has to be made.
Awesome!
Seeing this running on console makes me hopeful subframe inputs might be more widely applicable. Maybe some long standing runs that failed on console before can be made to work, like Mike Tyson's Punchout or Ninja Turtles. Maybe I'll start looking into it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Warp wrote:
Warp wrote:
Don't get me wrong. I don't think the Kirby Avalance TAS should be accepted either. It's just that the reason is different from the stated one (ie. "it's replicable via unassisted play"), which I think is a bit silly.
I must admit that I'm enjoying, perhaps in a bit cynical way, the discussion that the new SMB3 submission is generating.
I have been asking for years (although can't be bothered to find my own posts about the subject) what happens if a TAS does nothing more than to jump directly from the startup to the ending screen. I even once asked if in the future the site would start consisting on nothing more than 1-second long runs that do nothing more than show the ending screen of the game. Since not many such TASes have existed, it has been a mostly hypothetical question, but it has always loomed in the near future.
We are slowly but surely starting to see it happening.
I don’t think it’s a negative. This is just the natural end point in a long stream of developments on nes. The reason it got this far I would say is mainly because this is the reasonable intersection between complexity of the task and desire to exert the effort to accomplish it. Even technically very complicated NES runs are by far simpler then say a moderately lengthy 3D N64 run. Who would even dare to try to make a Jet Force Gemini TAS for example? That’s like a dedicated year of effort at least, with new discoveries likely to invalidate your work in the mean time. So instead people just hammer away at NES/ SNES and similar games. I know that’s what I did anyway.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Maru wrote:
I'd like to raise a few questions here because this TAS has mixed feedback so far. I was very brave to claim this TAS for judgment. This type of TAS is something that has rarely, if not never, been seen here before.
With regards to console verification, at the moment of this post, this TAS has yet to be console verified. However, it may be possible with some tweaking of the .r08/.r16m file.
So it doesn't work on console currently? I don't think this run should be accepted unless it actually works on console. This is a purely technical demonstration so I think it should be held to a standard of correctness where it either is right or its technical foul. I can work on anything on the emulation side that needs fixing. (I guess it's also possible that the problem is on the botting side, but that has seemed pretty robust in the past unless there is something unique here that is breaking it.)
As for the other questions, in my mind this is just a regular game end glitch run, it should obsolete the current one.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Awesome it’s done! Looks way more complicated then expected, nice work!
I really hope this one gets a console verification , doesn’t seem too timing sensitive so I’d think it has a good chance .
This is the culmination of a lot effort and work from all directions, so it’s great to see it done. Hopefully some of the ideas here are more widely applicable and this isn’t just a lucky fluke (well it is one , but hopefully not the only one .)
Anyway yes vote!
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
warmCabin wrote:
Regarding the console verification thing: the run obviously syncs on FCEUX, but it desynced when I converted it to run on BizHawk. It desyncs at the third dog in Wood with NESHawk, and desyncs almost instantly with QuickNES.
None of us have the hardware to test it for real, so we can't say which emulator is the most accurate as of right now.
FCEUX is very likely to be wrong. You can directly load the converted .bk2 file into Mesen too to see if it works there, it's worth a try.
It would be strange to obsolete a run that works on console with one that doesn't, that seems like a step backwards.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
In trying to sort out some recent regressions, I noticed some other bugs and also noticed that the core has fallen a bit behind in terms of accuracy and up to date TIA knowledge.
I implemented some bug fixes to catch up a bit on some of the basics, but other things are still a work in progress.
various timer tests now work (the knowledge to make them work was actually already written down on the document i linked in the first page of this thread,, I guess I just glossed over it!)
Also the 32charnew demo which requires writes to RESP to delay the draw command (but not the position counter) now displays correctly. this one was quite tricky since as far as I could tell it's not written down anywhere that this is what happens.
Anyway with these improvements the core is now (almost) back up to parity with Stella with the main deficiency being collision detection during HMOVE and hBlank when ENAB is written to. (And Journey Escape which is what originally led to this investigation.)
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I have sorted out the remaining issues and set this core to released, so it should now be fully TASable.
Unfortunately since the programmers had complete control of the screen drawing, many games run at highly variable frame rates. In order to account for this I had to set each frame for a constant time and just update the video whenever a frame was actually ended (which mercifully all games agree is at the expiration of timer 2.) This makes sure audio and video always play at the correct rate, but at the cost of having to put the video buffer in the state (actually two versions of it.) Luckily the screen is mostly empty most of the time so the state size compresses down to near nothing.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
GJTASer2018 wrote:
So will this core be in the next stable release of BizHawk? (2.3.3, 2.4, whatever number you guys decide on :P)
Yes, but it's available right now in the dev build if you want to try it out.
I've only one more known issue that i need to check before I can set this to released, hopefully by the end of this week I can track down the problem.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Vectrex is more or less done at this point. Working on the MC6800 actually led me to discover another couple MC6809 bugs which I sorted out. Menus are now available, even though there are no real choices at the moment. Virtual Pad is up and running, but there is an error in virtual pad that i need to fix before it's useful.
I probably won't do overlays just due to the tedium. If anyone else is interested feel free to take a stab at it.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Not sure anyone will be interested, but as an offshoot of my vectrex work I'm putting together an MC6800 cpu core. It can be used for such things as some Atari Arcade machines.
May or may not see any use, but since it's basically a stripped down version of the MC6809 that I already had to build for Vectrex, I figured I'd have it available while all the working knowledge was still fresh in my mind, and it would be faast to get going.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I've made pretty good progress cleaning up the remaining Vectrex bugs. I've implemented interrupts now so Bedlam works, which is one of the only games that make extensive use of interrupts. This was a good exercise because it revealed several bugs in the MC6809 core. This core is heading towards a releasable state.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Alright I got controller reading implemented, so now games are playable. Things seem to be working pretty well for the most part, so if anyone wants to try out the dev build and start bug hunting please do so. There are a couple bugs I'm aware of but surely more testers will uncover more.
Overall though things are progressing pretty nicely.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I liked the Mario Kart Wii TAS, Celeste was a little long for me so I skipped around but had some good stuff in it. Commentary was also really good this time around.
dwangoAC wrote:
No meaningful progress has been made in years to resolve this ongoing problem and I don't anticipate that changing until some new force comes in to shake things up with a different perspective on how to represent event content that isn't strictly fastest-to-the-finish content. Thoughts?
You TASBot folks are clearly the spearhead of TAS development at this point, why not make a TASBot site to have a centralized place to showcase stuff? I think this might also help bring in more innovation from people who aren't really interested in making traditional TAS content to begin with.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
dekutony wrote:
The game Spike has some voice clips. Do those work correctly in this new core? I remember the vecx libretro core didn't play those voice clips correctly, or not at all, at least on BizHawk anyways.
Nope they don't play yet. That's one of the remaining bugs I'm aware of that needs to be sorted out.
EDIT:
So if you look at this schematic, you can clearly see there is an output line from the multiplexer directly into the sound output line:
https://console5.com/techwiki/images/9/9a/Vectrex---Block-Diagram.png
So when I implement that you get the voices in Spike, pretty simple. Fixed.
The text in Spike still isn't centered properly. It seems like there is a delay to the ramp enable under certain conditions. One such condition at least is when PB7 control is turned off from the timer. My speculation is that this leaves the pin undriven and thus takes time to assume a value once written too. This centers the VECTREX text on the BIOS screen, but it's not the complete picture since there are some other scenarios, like the one in spike, where it should also occur.
The vectrex developers seem to have known something was up, since in the BIOS there are places where the multiplexer is written to twice in succession for no other obvious reason.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Vectrex is coming along. I fixed up numerous cpu and display bugs.
I also tried to add some brightness glow to make it look more authentic.
Only major thing left is analog stick controls. Maybe I'll try to add in overlays but not sure yet.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
image uploader
I'm finally starting to make decent progress on the vectrex core. Even though there are a couple other vectrex emulators to reference, it still took several hours of trace logs to figure out exactly what the system is trying to do to actually draw stuff.
It doesn't help that the system uses the 6522 controller which has a lot of little tricks in it. Of course at the same time I also had to sort out the bugs of the new CPU core, so that slowed things down as well.
Overall though it's getting there. I think the CPU core is pretty strong now, but the Vectrex doesn't seem to use the interrupt capabilities of the 6809 so that is untested.
Incidentally the 6809 is also used in some arcade machines like Simpsons, so it's theoretically possible to have a native version of that built as well, but I doubt that would ever happen.
Anyway there are still quite a few bugs to work out and a lot of cleanup to do. But, now that I can see things on the screen, I'm hoping things will move a bit quicker.
The next main things are sorting out remaining graphics bugs and getting control stick input working. maybe after that I can do some stuff to improve the display, but I'm not sure how much I can do without slowing things way way down.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
That's an interesting mystery, maybe the bsnes core within lsnes just needs to be updated. Pretty fascinating whatever the cause. Hopefully it can be resolved some day.
Editor, Experienced Forum User, Published Author, Expert player
(3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Patashu wrote:
I think the most notable use of peripheral hotplugging - that allows for a novel strat, rather than just skipping text - is in Secret of Mana [SNES], where AI controlled characters have different behaviours (such as not activating triggers) to player controlled ones, so at one point you unplug one of your three players, manipulate the AI to walk past a guard, then plug the controller back in to skip a trigger.
Thats actually pretty cool. I hope it can be supported some day.
I've made pretty good progress cleaning up the remaining Vectrex bugs. I've implemented interrupts now so Bedlam works, which is one of the only games that make extensive use of interrupts. This was a good exercise because it revealed several bugs in the MC6809 core. This core is heading towards a releasable state.
Vectrex is coming along. I fixed up numerous cpu and display bugs.
I also tried to add some brightness glow to make it look more authentic.
Only major thing left is analog stick controls. Maybe I'll try to add in overlays but not sure yet.
image uploader
I'm finally starting to make decent progress on the vectrex core. Even though there are a couple other vectrex emulators to reference, it still took several hours of trace logs to figure out exactly what the system is trying to do to actually draw stuff.
It doesn't help that the system uses the 6522 controller which has a lot of little tricks in it. Of course at the same time I also had to sort out the bugs of the new CPU core, so that slowed things down as well.
Overall though it's getting there. I think the CPU core is pretty strong now, but the Vectrex doesn't seem to use the interrupt capabilities of the 6809 so that is untested.
Incidentally the 6809 is also used in some arcade machines like Simpsons, so it's theoretically possible to have a native version of that built as well, but I doubt that would ever happen.
Anyway there are still quite a few bugs to work out and a lot of cleanup to do. But, now that I can see things on the screen, I'm hoping things will move a bit quicker.
The next main things are sorting out remaining graphics bugs and getting control stick input working. maybe after that I can do some stuff to improve the display, but I'm not sure how much I can do without slowing things way way down.