I'm not sure if it's just my computer, but when I was using TAStudios with GBHawk, saving a tasproj file (the Sailor Moon run to be specific) took a long time for some reason. Loading a branch also took a while. Is that normal? Saving seems to take shorter amounts of time when using the mgba core for GBA game TASing.
Hello. Um... I made a palette. This palette replicates Nintendo's 3DS Virtual Console palette that they use for their rereleased games. https://files.tasvideos.org/dekutony/3DS%20Virtual%20Console.pal Maybe it can be added to the official BizHawk palettes folder with the others, since I didn't saw this palette in there. You can add it if you want to of course.
Over the past few days I've been expanding GBHawk to have GBC support. It's now in a fairly presentable state so I thought I'd make an announcement in case people want to try it out. It's still a bit buggy but I'm hoping to iron things out over the next couple days. All of the grunt work of sorting things out between GB and GBC is done though, and all of the basic GBC functions are in there (except IR port.)
Originally I was going to hold off on doing this until some new test ROMs became available to properly fix PinBall Fantasies, but I don't see them yet and I wanted to get started on GBC while I have a little time to focus.
GB is still the primary accuracy component of the core, but I'll be working on GBC accuracy as the core becomes more mature.
In terms of performance for me it currently runs about 130 fps, while the GB side runs around 210. I think 130 isn't too bad considering double speed mode, HDMA, and colorizing things makes the core do considerably more work. Maybe some optimizations here and there can improve things a little more, but Gambatte is still 10x faster anyway.
_____________________
http://hhug.me/gbx/1.0 Someone is is making a new file format for Game Boy games. I don't know if it's a good idea if GBHawk could support it.
Thanks for the hard work! Are you gonna implement a hacky support for the GBA mode, or are you gonna wait for the actual bios dump?
I've made some more commits to GBC, and finally fixed the long open bug with Sachen Beast Fighter. It turns out the GBC Warriors of Might and Magic was doing the same thing as Beast Fighter, so it was pretty easy to work out what the intended behaviour was.
Also I started working on MBC7 for Kirby tilt 'n tumble TASing, but it's not done yet.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Also I started working on MBC7 for Kirby tilt 'n tumble TASing, but it's not done yet.
Ok we can now tilt 'n tumble!
I think I got everything working with the mapper and EEPROM. Motion controls and centering work, saving works, and TASing is possible.
However, I've never had a GBC or played this game, so I don't really know if the controls feel right, or if it gives the proper playing experience. So, if you are interested in this game I would really appreciate some testing and feedback. (I know there are a few graphical bugs, I'll work those out over time, I'm primarily interested in how it controls.)
Some notes on controls:
You control the angle of tilt directly with the controls. This means there are some nonlinear effects. They aren't really that noticable in casual play though, since the angles are not that large.
The control scheme is based around rotating about the up-down tilt access first, then rotating around the left-right tilt second. However, both rotations are around body fixed axes. This means that left-right tilt is coupled to the up-down tilt. The effect of this is that left-right tilt is less effective as up-down tilt increases. This might be an important consideration for a TAS, but so far in casual play I didn't see any serious impact.
The current control scheme assumes you tilt slowly (basically the only accelerations on the system are from gravity.) There are no induced accelerations from fast motions. This is one area where there might be noticable differences between real play and emulator. I can simulate them if the feedback is that it's really needed.
I just committed some improvements to GBHawk that allow the game Airaki to work.
This is a game by Furrtek, which is known for their anti-emulator checks in their games.
This game did 2 things. First, it checked that reading from the Cart was disabled while DMA is in progress and DMA address is from ROM space. Second, it checked if the timer divider register is being used to clock the length in SQ1 in the audio. (You can prevent clocks by constantly resetting the DIV register.)
These are both well known behaviours, but aren't commonly implemented in emulators I guess, at least at the time the game was made, Sameboy for exmple runs it just fine.
I should also mention I'm getting a lot of audio problems with GBHawk right now, it seems to speed up and slow down a lot which in turn makes the pitch sway wildly.
