Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
DrD2k9 wrote:
If we can't agree on criteria for determining a rating (of any type, not just technical), what value does the rating hold?
I see this as a 'make of it what you will' type of thing. It might have little/no value, but it is also of little/no consequence. If someone gets something out of it that's fine, otherwise it's safely ignored.
If it were a situation of 'you must have this player rank to do this thing on the site,' then figuring out the best way to calculate it would obviously be more important, but it's not, it's just a number.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Personally I don't think player points have much if any value. They do seem to do a poor job representing a TASer's body of work for the reasons TASeditor mentioned. I'd rather just have a direct link to a person's published works in that space instead.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
The first 3 look like just simple IRQ issues, I'll look into it.
But I can't recall another example where different sprites are showing up, that's a new one.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
jlun2 wrote:
Nice work! What was the main difference memory wise that allowed this to be possible on console v. the other run? Nothing against this run; just curious.
It's not yet known if this one works on console, only that both Gambatte and GBHawk agree that it should.
I don't know exactly where the timing error in VBA lies. It's pretty old and much work has been done to improve GB accuracy since the last run was made, so it could be any number of things. But the game doesn't use that much complicated PPU tricks, so it must be something relatively basic related to VBL timing.
The basic idea is that this is a bad bank swap. The game assumes a HALT will be reached before an IRQ occurs, it then returns from the IRQ to an assumed bank, not the actual required bank. This has to happen exactly after the instruction JP #4067 in order for sensible code to be executed that reaches the game end glitch. This instruction is 16 cycles long, so that's the window to work with.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/48019516364747335
Here is an unoptimized TAS of the Q*Bert score trick.
Basically, the snake jumps into you after the level ends but before the transition to the next level. There is a roughly 5 frames window to do this.
The snake is still there but below the level I guess. If it ever jumps back onto the level the stage ends as normal. So the trick is to find a pattern that keeps the snake from jumping back up. Once you find it, just repeat as long as you wish. The score rolls at only 100000, so nothing particularly unique happens once the trick is started.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/47986639364398403
Here is the biggest improvement so far with 284 frames saved in 8-4.
This is also about ~150 frames faster then BagOfMagicFood's version from the Eggerland game.
EDIT: I added BOMF's 9-3 improvement, run is now submitted.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Wow it's been almost 3 years since my last post in this thread, it seems like so long ago...
Anyway, I'm looking at implementing the known improvements in this run and seeing if I can find any of my own. If anyone is interested feel free to jump in.
Right now I'm just working on getting the known improvements all in one file. I saved 32 frames in 2-2, not sure exactly what Nitrodon's improvement was but it's probably that.
EDIT: http://tasvideos.org/userfiles/info/47952051421383948
This file contains all the known improvements mentioned above. Now I'll start trying to find some more.
EDIT2: Found a pretty big improvement in 8-1. Nothing before that.
EDIT3:
http://tasvideos.org/userfiles/info/47959562881352562
Here is a file with the new 8-1 and also a bit of cleanup where I missed starting on the correct frame a couple times.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Cool! It always kind of bothered me that the nico video tas was there while TASvideos had something over 1 minute slower, but I didn't think it could be improved. Nice work finding those 24 frames. Yes vote!
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Well that was a lot of work but the result was certainly well worth it! The Spectrum uses a lot of hardware trickery to get things done, and getting everything just right is must for this core.
Fortunately, the Spectrum community has reverse engineered the system to fine detail, and had many tests available to fix bugs. It must have taken them many hundreds if not thousands of hours to get to the point where we are now where every t-state is accounted for, it's a pretty impressive feat!
Truth be told there are still a few minor inconsistencies between the z80 core and the real thing, but they are undectable on the spectrum anyway (except maybe NMI somehow?) and not used anywhere else to my knowledge, so there's not much point sorting them out.
Even after all this work, it's still interesting though how easy it is to detect an emulator from real hardware. I saw an example online while doing some research for the core where you can basically repeatedly do LD R,A and thus prevent proper memory refresh. After a short time, memory on real hardware will decay. But, obviously we can't track memory refresh on every byte of emulated memory without going at 0 fps, so this effect is lost to us. So if anyone out there doesn't want their code running on emulator, it takes only a dozen or so lines of code to detect it, pretty neat! EDIT: Well, now that I think about it, there is probably enough headroom left to do memory refresh and still run at maybe full speed (although probably no faster) but still not really worth it.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
http://z80.info/interrup.htm
This page says that SP = AF = 0xFFFF at reset.
Implementing this does indeed make the game work. So I guess I can remove that hack afterall, problem solved!
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Hitboxes in this game are actually extremely accurate
I think it's worth noting here that the Intellivision uses hardware level collision detection (like the A2600.) So, there are no hitboxes like you encounter on the NES for example. If pixels from 2 different objsects overlap, this information is placed on a hardware register. That's why the collision detection is pixel perfect.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
feos wrote:
Sorry Aran. I tried reading a whole lot of your posts, and I simply can't. I keep giving up three lines into a sentence of 10.
He's asking about combining the rating system with the voting system. (I think it was discussed somewhere before?) This sentence seems to concisely sum it up:
Aran Jaeger wrote:
And my suggestion above with the rating system being put in place of the no/meh/yes poll
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Ok, I was wrong about that. The game does set the 'ROM write enable' flag, but the root cause of the problem is that it doesn't set the stack pointer before starting to execute code. A 'CALL' instruction then overwrites the ROM bank. This happens since I initialize the stack pointer to zero, then it gets decremented to 0xFFFF (ROM bank register.)
I tried looking for documentation about where the stack pointer gets intiialized to, but I don't see it actually specified anywehere. 0x0 and 0xFFFF both crash the game, so it can't be those. It's possible that's it's just some unspecified value.
If this were the case, this game would function by pure chance on real hardware. The game does need to be able to return to the proper address after the call, so the stack pointer does have to be in writable memory.
This is very strange. My guess is that during development, they didn't realize the mistake they made since they left the ROM write anbel flag set, meaning the stack pointer could start anywhere and still be in writable memory on their dev boards, thus masking the problem.
Or it really is initialized to something internally and I just can't find what. The documentation does specify that the only register actually set is PC (to zero) so who knows what actually happens.
Anyway, I added a game specific hack to make the game run by putting the stack pointer in RAM initially. I don't particularly like it, but it does work now.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
What a surreal thread.
Grincevent wrote:
When you think about it, the site favors yes votes in general. Why? Simply because most people don't go watch each and every TAS, they choose which ones they want to watch, the ones they are interested in and they are most likely to like, and by extension, to vote yes for.
Anyway, I found this kind of funny as this is exactly what I do. I'm very surprised so many people even have the patience to vote 'no' or 'meh.'
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
HappyLee wrote:
So we end up with a polarizing submission of a run that shouldn't be controversial at all. Many people claimed that the vote result (once and for a long time less than 80% "yes" votes) makes sense because it's "subjective". My question is, what changed?
I think at least part of the answer to your question here is that you under-estimate how much TASVideos itself changes over time. I briefly looked at profiles of the people who posted in your SMBJ2 run, and about half of them haven't even logged in since this run was posted. Several have not even logged in in 2018. I would be quite surprised if there was >50% commonality in voters between this one and your 2012 run. Even between this one and SMBJ2 I would be surprised if the commonality was more then 85%. Newer people I would expect less likely to find SMB highly entertaining, just due to having not grown up with it (it's 30+ yrs old after all.)
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
It looks like you are using gambatte. 2.2.1 had some bugs in gambatte, use 2.2.2 or preferrably the Dev Build since a lot of improvements have been made since then.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Fortranm wrote:
Each archive contains two ROMs; the original ROM, and a version with a fixed header that allows it to run on normal Game Boy hardware and most emulators.
This is from the description of the recently surfaced Pokemon Gold/Silver demo rom. It would be nice if GBHawk can run the original rom, just saying.
It can't run on normal Game Boy hardware? If that's the case then it shouldn't run in GBHawk either.
What did the original run on then?
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Personman wrote:
feos wrote:
To be honest, I don't know why we even still have polls.
I think this would be a great time to abolish voting altogether.
Personally I use the polls as a quick gauge of whether I should watch a run or not, so I guess it's not strictly a tool for judges. Although I could just as well use number of posts for the same purpose if the poll wasn't there.
So I guess I agree. Also I don't like being asked a question only to be directly told that my response doesn't matter, might as well not even ask.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
Kurabupengin wrote:
Alyosha wrote:
I improved the tilt controls in Kirby's Tilt 'n Tumble to include rotation rate effects. Now the controls should feel more realistic. If anyone wants to test I would appreciate any feedback. This would also effect Command Master, if anyone is familiar with how that game's controls feel.
I made a movie of the first level:
http://tasvideos.org/userfiles/info/47518336021050499
Syncs just fine in the latest build.
Seems to control well, though I haven't played this game on a real gameboy for years, so I can't really tell if there's anything off.
Thanks for the testing. If you do happen to notice anything out of place do let me know, as I would like any TAS of the game to be physically reasonable.
I suppose one could crack open the cart and replace the accelerometer circuits with something that just returns predetermined values, but I'd still like those values to be based in reality.
Editor, Experienced Forum User, Published Author, Expert player
(3560)
Joined: 11/30/2014
Posts: 2744
Location: US
I noticed that when I convert runs from VBA they tend to sync much easier on GBHawk then Gambatte. This is because VBA apparently also ends frames always on VBlank boundaries. On GB and GBC, the distance between VBlanks can be arbitrarily large since the console can disable the screen, and many games do so during loading. So on games with significant loading times, the difference between the time in reported frames x frame rate and actual real time can be pretty large.
For example in my new Kwirk movie, using frame count and 60 fps gives: 15:51.59
But, a more accurate time would be to divide cycle count by cpu clock speed (4021503155/4194304) = 958.80 seconds = 15:58.80
It's probably not worth doing anything about, I don't even know if you can get a cycle count from VBA, but the difference seemed significant enough to at least mention, since there are many VBA GB runs.
