TASVideos

Posted: 4/5/2019 9:56 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

hey cool find! Maybe you can find some other improvements and make a new submission. It always kind of bugs me when the puzzle games don't have fully optimal solutions.

Posted: 4/5/2019 12:08 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Already? Wow that's amazing! Hopefully this breaths some fresh life into SNES work. It feels like it got so close but never quite overcame issues of complexity and hardware timing. This is just a suggestion, but you might want to contact DwamgoAC and some of the other TASBot folks. I remember them having some really serious issues working with the snes a while back. Maybe they can offer some input in how to future proof this or give it more options to behave like a real snes.

Posted: 3/30/2019 9:13 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

I've started working on a vectrex core. A lot of components already exist as parts of other cores so development shouldn't be that hard. the toughest part is the MC6809 cpu which is pretty involved for an 8 bit cpu but shouldn't be too much of a hurdle. Probably not a core with much utility but i wanted to try something a bit different.

Posted: 3/20/2019 11:09 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Unless another Asnivor pops up, I don't think you'll find much developer interest in older systems. However, if you are interested in such systems, I can help with core building within BizHawk. The VIC-20 for example is a pretty standard and simple design, and uses the 6502 CPU which we already have. If you aren't interested in the inner workings of BizHawk's infrastructure, I could even put together a blank core that is already hooked up, so you would basically just be responsible for putting together audio, video, and system layout stuff (which is admittedly the bulk of the work, but is really simple in terms of actual coding.) It's a great way to learn about console design and even basic coding. Porting existing emulator's is out of my capability though, so I can't help there.

Posted: 3/16/2019 1:16 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Did you try it? There are various supported Nanjing mappers.

Posted: 3/16/2019 1:15 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

I could make a version that always runs a constant number of cycles, in fact that is what GBHawklink does by necessity. However I don't like how this makes input frames disconnected from video frames, so I'm willing to live with slight anomolies when the screen is off instead. As I've said in the past, I might make a constant cycle count version when everything is more mature and finalized, but for now it's not a priority.

Posted: 3/14/2019 11:27 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Do you have GB -> settings -> sync settings -> use existing save ram selected? The intent of this setting is to allow for play without having to worry about accidently modifying your working save ram file.

Posted: 3/9/2019 11:11 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

I notice that is a kirby's dreamland thread. Yeah that game turns off the screen a lot, so it will appear to run fast. GBHawk isn't really build for RTA anyway so I'm not that worried about it.

Posted: 3/5/2019 2:04 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

It’s currently non-functional. So far I have the ppu cou and apu converted to C++ and have removed the reflection that proved pretty annoying. But I haven’t stitched them together yet.

Posted: 2/24/2019 2:33 AM
(Edited: 5/31/2021 1:10 AM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

https://www.dropbox.com/s/rr4mn6trfh5iqgj/streemerz_joe.bk2%20%281%29.frame.r08?dl=0 http://tasvideos.org/userfiles/info/71811809490780451 Here is a streemerz input file for superb joe mode. once again this sync on Mesen and my personal build but not on Bizhawk dev build.

Posted: 2/18/2019 8:56 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

I made some improvements to NESHawk that give a roughly 5 fps boost in performance through some simple code optimizations. Some gems of wisdom include:

if (true)
else if (false)

replaced by simply:

if (true)
else

I also rewrote the audio handling to bring it in line with other cores and simplify it a bit. Note that these changes break savestates (but not sync)

Posted: 2/17/2019 7:25 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

feos wrote:

Haha, yeah baby! It should have happened sooner or later. 10 years ago writing a core in C# maybe looked like a grownup approach, but over the years it's been getting more and more accurate, slower and slower, and at this point it's obvious that if we can't emulate 6502 or Z80 based systems at full speed, we're doing something wrong. It also means there's no way younger consoles will ever run at usable speeds if the same approach is taken. Though I don't think anyone will be using it for further development, as opposed to just running movies on it. There are tons of NES emulators now, and it's kinda getting old. Even bizarre accuracy isn't that novel anymore. So I don't know if this is eventually adopted by hawk again, but this undertaking is obviously something worthy.

Indeed, C# just isn't suited for this type of thing. It's kind of a shame too, since we're at a cross roads where making new in house cores in C# is not even practical except for the few remaining 8 bit systems and old computers. But on the other hand our ability to interact with ported cores is usually difficult and limited. It's also unfortunate that so many NES emulators have code bases that are quite difficult to work with. Wouldn't it be great to be able to drop the NESHawk core into the FCEUX frontend and suddenly have a fast, complete, and accurate NES TASing emulator? I think so, but I don't dare to even try.

Posted: 2/16/2019 9:15 PM

Post subject: NESHawk++

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

I have started work on a derivative of NESHawk ported to C++. Current repo is here: https://github.com/alyosha-tas/NESHawkplusplus The motivation here is that NESHawk is super painfully slow. It's way too slow to do serious bot work with. QuickNES is 20-30x faster. But, NESHawk is very highly accurate, unlike QuickNES. Also, NESHawk can be run at the precision of one PPU tick. This provides easy access to subframe resets and inputs. So I thought I would try to port the NESHawk core to C++, cut out the fluff, maybe do some optimizations, and see how fast it could run. So far porting the core is been relatively pain free. I'm about 30% done. I'm hoping to have the porting done in a week and see if I didn't break anything. The goal here is to have a framework for a build-it-yourself emulator that won't limit the user in any particular way. Anything you can do with C++ you can wrap around NESHawk++. You will have full access to the core state, and can increment it with a single function call. And since it will be the exact same core as running on BizHawk, you can create BK2 files of your work that will still sync on actual BizHawk. Also, this won't be an actual emulator in the usual sense. There won't be any controller support, mapper support (maybe some common mapper examples), gui, user settings, or similar extras. It will basically be a virtual NES (cpu, ppu, apu) that users will have to develop their own tools for. That's basically it. If anyone is interested in helping with this or has a project in mind they think this would be helpful for, feel free to contribute or let me know.

Posted: 2/15/2019 1:49 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Hmm, this made me think, NESHawk is currently very slow, but it is also in a form where one can run the entire underlying core one cycle at a time. You also have access to the entire state at all times. So you could basically extract the entire core as is and directly translate it to C for example and be able to increment the core one cycle with one function call. You could then wrap any machinery you like around that and have no extra BizHawk overhead. You could probably also simplify things a bit for a specific application for additional performance benefits . I’m not sure if this would be faster then QuickNes, but you could do some serious stuff with it. And the results would still be valid on BizHawk. Just a thought . I might consider trying it in the future.

Posted: 2/13/2019 1:26 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Ha that's cool! All 3 save files involved that's intense.

Posted: 2/12/2019 12:59 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

phoenix1291 wrote:

I don't know if this is the case with other cores (I didn't have time to test), but with Atari7800hawk core (last dev version), for me it's impossible to make a video rendering by resizing it, I tested with most codecs, by not resizing the video at the output, no worries, the video is good, but by resizing, only the sound is ok, the image is not, there's just a black screen.

woah that's weird. After a cursory glance I don't see any reason why this should be happening. I'll look into it. EDIT: Seems to be broken in "Allow alpha to matter in screenshots. " here (BitmapBuffer.cs):

		public void DiscardAlpha()
		{
			// HasAlpha = false;
		}

The commented out code breaks scaled video capture here (MainForm.cs):

							bbin.DiscardAlpha();

							var bmpout = new Bitmap(_avwriterResizew, _avwriterResizeh, PixelFormat.Format32bppArgb);
							bmpin = bbin.ToSysdrawingBitmap();

That's definitely the cause. not sure what side effects are are uncommenting out that. EDIT: fixed in master

Posted: 2/11/2019 11:59 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

No, streemerz should have the same sync requirements as battletoads but somehow never synced on console in earlier tests despite many tries . So it’s likely that battletoads synced only from lucky error cancelling.

Posted: 2/11/2019 1:36 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

For the first time in a long time I have some new direction for possible NES console verifications. I have created a movie file with a version of Bizhawk that syncs to Mesen's power up timings. the movie file won't sync in the dev build of bizhawk since the timings are different, but here is a r08 of the input file I made using my personal build: https://www.dropbox.com/s/ukn7330nwkjhqxe/streemerz.bk2%20%281%29.frame.r08?dl=0 If anyone out there has the ability to do some console testing please give it a try. Keep in mind that NES power up timings are still quite variable, so it might take numerous tries to get it to sync, as this game is ppu timing sensitive. If this works out it is likely that I will change NEShawk's timings to match Mesen, then there will be many new areas to investigate, but for now hopefully this test works.

Posted: 2/10/2019 2:50 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Got it, updated. Good luck.

Posted: 2/10/2019 3:03 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

I practically never watch published tases. I can recall occasionally downloading an mkv if I didn’t want to run a movie in an unfamiliar emulator , like for comparisons in Dega movies .

Posted: 2/10/2019 2:44 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Game boy link cable support is essentially complete for both GBHawk and Gambatte. Well for 2 players at least. Also GBHawk appears to have slightly better compatibility. Future work might involve 4 player support but it’s not likely in the near term.

Posted: 2/9/2019 4:06 PM

Post subject: Game Gear Linking

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

I have started work and made initial commits on Game Gear link cable support (GGHawkLink) I was able to reuse a large part of the GBHawkLink code which made the initial steps relatively painless. So far you can use multidisk bundler and load the 2 games but they currently aren't actually linked. It looks like it should be possible to get all the linking stuff sorted out. It's a bit messy though since the SMS core is pretty far behind in terms of development compared to NESHawk and GBHawk. So if I run into any roadblocks it might delay things quite a bit. I'm not sure how much linked Game Gear play really offers, but it seemed like low hanging fruit so I went ahead and started it. this also shares a lot with what would be needed for subframe input support, so it's a first step in that direction as well.

Posted: 2/3/2019 4:19 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

I just made a fairly significant commit to Atari 2600 that improves HMove emulation. now various newer demos relying on precise Hmove behaviour (like Bang! and Flush) work. Also behaviour is much closer to Stella in "Hit HMOVE At Various Cycles After WSYNC Test (Bradford W. Mott) (1998) (PD)" although there are a couple remaining differences. Anyone using A2600 please keep an eye out for regressions.

Posted: 1/27/2019 3:58 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

dwangoAC wrote:

Thanks for the feedback, keep it coming. A couple of points - I don't think that TAS content at GDQ's has "jumped the shark" in the classic sense as we're not so desperate for views that we're trying anything and everything to retain them. Having said that, we're possibly in a midlife crisis. We're 5 years in to something that I anticipate will be a 50 year journey so perhaps that's not apt either, more like we're having growing pains, but you get the idea. And yes, I plan to be doing this for 50 years. Maybe not the same form, maybe not the same "traditional" consoles that we use now that will be archaic in 50 years when I'm in my 80's, but a continuing, evolving concept of using physical hardware and tools to create art.

I think this is a good explanation of the current situation. There isn't really a clear path forward from here. Even with LibTAS, only very few games are worth presenting in traditional TAS style that could actually be entertaining (Celeste being the current example.) What comes to mind for me for a good direction to look in is things like 'Luigi wins by doing absolutely nothing' or the similar thing Masterjun did a while back with Kirby's Air Ride. I think it's unintuitive and silly goals like this, yet still easy to understand and follow, that could provide the most entertainment. Of course they are also much harder to come up with. And you have to be careful they don't become gimmicky and boring like Scribblenauts. ___________ On a completely separate note, there seem to be more and more dead ends lately in terms of getting things to actually work. Obviously I'm not privy to the details, but this seems to have eaten up a rather large amount of time. Maybe it's time to set out a semi-formal roadmap of things that need to be done / researched and what future work this could enable. Some focused R&D seems necessary, and not just for immediate needs, thinking a few years down the road.

Posted: 1/24/2019 10:46 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
Location: US

Cool! glad it works! Out of curiousity, how long would a normal TAS be without save corruption.

Posts for Alyosha