Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Really? Nah, I don't believe that a vested member as Xkeeper suddenly did such awkward and bland trolling (knowing that admins easily inspect No-voters), more like he was banned for being overly sarcastic and repulsive (IIRC). Still, perma-ban is damn disproportionate response.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
DarkKobold wrote:
Slight correction, no one is ABLE to debug this game except for FinalFighter ;)
Why noone, there were some very experienced romhackers here, like Acmlm or Xkeeper, although I haven't seen them for a while.
Crap, I've just noticed that Xkeeper is... banned?! WTF? His posts history suggests there was no reason!
Man, TASvideos really changed since Bisqwit's times.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
And wouldn't it be faster to create Warp object instead of Finish object (jumping to level 5 instead of simply finishing level 3 and having to play almost entire level 4)? -_-
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
adelikat wrote:
Looks like AnS "plays with death" with an enemy, and on the real console it isn't quite so successful :(
Haha, RL is rough. Can I watch that video?
About obsoleting, best of luck to you guys, as I don't feel like improving this run myself. But I'm sure you can squeeze at least one and half a second (plus these 10 wasted frames at the end), because in later levels there are more complex paths with many turns, where subpixel management can save several frames each time.
When I was making this run I didn't even know about subpixels, memory watching, lag and other stuff (was using only savestates + frame advance). Also luck manipulation was probably less efficient than it could be. In 2009 I was planning to improve the run, but it was the time when I started losing interest in TASing, so it didn't happen.
Here's some lua script I made back then:
http://shedevr.org.ru/temp/sound/mermaid.lua
You may find it useful to measure passed distances on 2-dimensional plane.
I'd be happy if Randil and Aglar cooperated together to make this run.
Just don't forget to put some funny scenes in boss battles. And if you think the game is too simplistic for pulling new antics, I encourage you to copy/recreate some of my old stuff (like the battle with 2 eels or seashell juggling with walrus). Because I've seen too many old runs degrade into pure speedruns, I don't wish this to happen with the game.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
jlun2 wrote:
It's 2-players and uses a trick that makes my Tanks slightly faster.
Aha, did you play this tutorial romhack or you've found this trick on your own? Probably latter, I guess. But still, if you're doing Battle City TAS or simply like this obscure game, you should take closer look at Binary City.
jlun2 wrote:
Since a stage takes nearly 1 minute, the run would be around 35 minutes long.
Enemies' respawn time reduces by 4 frames with every level, so later levels should be faster than a minute. But even then I doubt it would be entertaining to watch half an hour of so repetitive stuff.
Bisqwit wrote:
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
DarkKobold wrote:
AnS wrote:
BTW, if this submission is approved as a precedent, does it mean that all Battletoads runs must end at the fadeout screen instead of last hit?
You are missing the entire point of my statement. While the movie file could end ten seconds earlier, the actual end of the game would not come any sooner.
Not true.
* if the movie ends as soon as possible (17:31 file), actual ending happens at frame 66236
* if the movie ends after some fun (this 17:41 submission file), actual ending happens at frame 66281 (45 frames later: 37 frames of lag + waiting takes longer than normally)
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
feos wrote:
As DarkKobold & me discussed in IRC, this game requires one more Start press to skip the last dialog cutscene, though it is saying "GAME COMPLETED", is may & must be skipped.
The game doesn't require Start press, this last dialog will disappear after waiting a couple of seconds. In fact, this dialog is first part of ending. Why must it be skipped?
Man, yesterday I was so going to write detailed post about how great you worked on this game during last halfyear. But at the end of the day you rushed to beat levels 6-7 (which are now the least entertaining part of the movie) and submit the file right away, without usual discussion/reworkings. Bah. Sure I'm not gonna vote No for the movie I anticipated so much, but that's where we part ways.
DarkKobold wrote:
Also, the stylistic choice of using ten seconds of down time to have fun at the end of the movie
Since when it's called downtime? It's the end. There won't be any uptime after that.
Aglar wrote:
I suppose the extra input at the end was inspired by the similar sequence in FODA's 2-player Battletoads run from 6 years ago, a time when people weren't frame-picky enough to complain about such a thing:)
BTW, if this submission is approved as a precedent, does it mean that all Battletoads runs must end at the fadeout screen instead of last hit?
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
feos wrote:
I refused stopping the movie at the last attack of the boss, to show the final battle between characters. It lasted through all the stages.
Yes, we were discussing this arbitrary decision of yours. And I do think you're wrong when submittiong "17:41 run" instead of 17:31 one.
This made-up final battle doesn't add anything to the movie. In previous stages you had to wait after boss, but after beating final boss you can stop the movie, because ending doesn't require any additional input.
Your movie should begin from the console power-on and end when the last decisive action has been delivered.
Edit:
So someone indeed voted No (instead of me), lol.
I myself didn't vote yet, because the movie actually rocks, and I'm trying to prevent author from making mistake.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
FCEUX is accurate in emulating these games.
These games use "tint" bits of $2001 register to make palette darker. They are supposed to be dark. Of course player can manually adjust TV brightness to compensate this effect.
And those gamefaqs.com screenshots were either created using older emulator or they were edited (brightness increased).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
zaphod77 wrote:
Provided a game doesn't abuse the DMC channel or uninitialized RAM, it's tasable on hardware.
SMB3 uses DMC but it was replayed on hardware.
The problem with "Blades of steel" and some other KONAMI games is in their RNG that depends on free CPU cycles.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
I think Fang is overused in CHC runs. Also I didn't notice any beautiful dances mentioned in submission text. And finally, this game needs 2P run badly. So Meh.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Moozooh's post makes me think that maybe there's no point in "pure speed" runs of arcade games, because arcade games are designed to value completion less than actual playing. So there's probably no fun in knowing how quickly can the game be beaten in super-easy mode (bought by coins), it's more important how clever/artistic can the player be. In some cases using coins may be clever (much like using Reset button can be clever). I voted "No with exceptions", because there's no "Yes with exceptions" option.
If we are to set rules (which I don't think is necessary, maybe just general guidelines) here's simple wording:
Coins should be used only as a mean to boost entertainment, but not to gain advantage in competitive speedrunning. (that one where we have framewars)
Thus if a TASer makes pure speedrun without any tradeoffs, he is not allowed to use coins, even if the game can be completed a couple minutes faster. [*]
But if TASer makes playaround or concept demo, he can consider coins as a factor for creating richer content (e.g. having more variety by switching characters, glitching by using excessive amounts of coins, so on).
Usually the fact of using coins itself decreases entertainment, so this additional entertainment boost must outweight it by large margin.
___
[*] (now, 10+ minutes is another matter, impressive difference may be entertaining itself)
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
AnotherGamer wrote:
Couldn't care less about whether extra credits are used or not, what I care about that nobody can be arsed to sacrifice a few extra frames to turn blood on so everyone doesn't bleed spooge which makes the game looks retarded.
If the TAS were playaround or "speedrun with entertainment tradeoffs", sure.
But since it's targeted as pure speedrun, unused coins are nothing but missed opportunities.
I asked the author about effectiveness of coins-feeding, so that I'll be able to base my vote on something more or less objective.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
feos wrote:
As it was said, a TASer is a super-human, so he obviously has unlimited money :D
Superhuman could also edit memory directly, so what?
If coin-feeding is accepted, this will mean that coin-using must be as effective as possible. So I foresee arcade runs using enormous amounts of coins every level. By the way, does this run uses coins optimally?
Unlike healthbar, coins are unlimited (unless player makes decision to limit the number to some arguable value, like 4 coins per game), so there's little of management skill in distributing coins.
Nevertheless I think coin-abusing should have its own category, allowing to have at least 2 TASes for any arcade game (one that uses coins and one that doesn't).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Warp wrote:
Btw, how does a NES game detect that it has been reset, if it can't really control what happens?
At $FFFC there's reset vector (pointer to reset handler procedure). Actual value is hardcoded into ROM bank by programmer.
Every time player presses Reset, CPU starts executing code from the address provided. This isn't like subroutine calling, this is more like JMP (or GOTO), so CPU can't return back from where it was interrupted. But, as memory and registers didn't change, it's possible to "guess" at what point of gameplay the CPU was interrupted (for example, by storing current_mode_id in memory).
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Warp wrote:
What I meant is whether the game can override the implementation of this signal handler and make it do nothing (at least during the duration of saving data).
It can't [make it do nothing]. Saving process will be interrupted anyway.
But that doesn't mean that nothing can be done.
Warp wrote:
but if it can't (and hence saving may always be corrupted by a reset no matter what), then my original objection stands (because in that case resetting cannot really be considered to be input to the game).
While the game can't completely ignore Reset, it can detect saving interruption and then repeat saving (while RAM contents are still intact after reboot) instead of clearing RAM and showing title screen. Such saving implementation would stop TASer from using reset to corrupt save data.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Warp wrote:
How exactly do games "handle it in certain way"? AFAIK NES (and for that matter most other console) games cannot hook to nor detect that the reset button is being pressed and act accordingly. Granted, I don't know the exact details of the NES hardware, but I'm assuming that when you press the reset button, it's tantamount to pulling the plug: The program just stops right where it was (simply because the CPU stops working), without giving it any chance to do anything. The reset button is not input to the game.
Warp, I think you are confusing Reset Button with Power Button (maybe because in modern PCs these buttons are fused into one: when you tap the button it's "customizable reset", when you hold it for 5 seconds it's "forced power off").
But intrinsically these are two different buttons. Power button is hardware trigger, reset button is software signal.
Reset button never removes power from device.
The button acts more like non-maskable interrupt - it just changes program counter (pointer to next instruction) to some predefined address. (Well, there are also some platform-dependent hardware reinitializations, but what's important - CPU/memory/chips don't lose power)
In case with NES games it's even more game-friendly: as NES doesn't have BIOS, programmer must define the address of "reset interrupt" and write all the code that will be executed every time player presses reset button. So it's quite possible to recover from reset, and some NES games actually use reset button as "Return to menu" (not to title screen), without resetting score and other gaming data.
And theoretically it's possible to completely disregard Reset button (just return from the reset subroutine to next frame iteration), although it would look strange - player pushes Reset and game freezes, player releases Reset and game continues.
That said, I also think Reset button is kinda arbitrary (somewhat close to memory/CPU status editing), but well, it's TASing, not normal speedrunning. Until it delivers fun it's all for good.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
I agree with Derakon, it's too early for such category. If less than 1% of movies are "verified" it would only undermine credibility of whole collection.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
Heidman wrote:
Thank you for your time in figuring this out for me. Sadly the way it works I don't think I am gunna be going for it in any of my runs because I don't see it being reliable. Again, thank you for your time.
Ok, but just in case you were to try it someday: you could play this part of the level in emulator (reloading savestate after every experiment, but not resetting console) and grasp the time needed for success (those 1.5s or so), thus upping the probability from 2/105 to something like 1/10.
Emulator Coder, Experienced Forum User, Published Author, Experienced player
(724)
Joined: 2/23/2006
Posts: 682
moozooh wrote:
So, assuming a console run and no precise time measurement, one would have to try killing one of the tanks roughly 1.5 seconds after it appears on the screen, correct?
Yes, about that.
What's convenient speedrun-wise, these two lucky frames are not distributed evenly among those 105 frames. They are close to each other (first come 96 frames of nothing, then one lucky frame, then after 9 frames goes 2nd lucky frame). That's the reason this bug can happen many times in a row - while probability is rather low, player naturally kills first tank near that time (+/- 10 frames).