Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
I love pacifist runs, and one that subverts the original design of the game (namely kill everything) is even better. I'd definitely look forward to a pacifist "ultra-violence" run.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Interested to know how this is optimal. Playing the home team and being ahead after the top of the ninth would prevent having to play the bottom of the ninth. Also, there are balls thrown which seem unnecessary.
I know it's an April Fools submission, but it should still be optimal.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
I appreciate all the effort put into this. Unfortunately, as others have mentioned, the game just doesn't lend itself well to a TAS. A TAS is supposed to do things that are harder than humans can do, but removing 90% of the enemies by turning them into to coins makes it a much easier game.
Voting 'no', but don't let that discourage you from finding a better game and TASsing that.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Thanks for the run. It looked pretty optimized to my untrained eye, however the horrible graphics, music, and that long, long stampede level make it so I can't say it's entertaining. A good addition to the vault, IMO.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
Who wants 10 minutes of TV/Youtube fame? If someone can find a way to perform ACE on this game, I think you could do it.
Hear me out. This is a game made by the magician duo Penn & Teller. In Smoke and Mirrors, they made an "Impossible Mode" that is literally impossible. However, if someone could find a way to use ACE to beat the Impossible Mode, and could hide the mechanism that runs the TAS (in a controller for example), that person would stand a good chance of making it on to Penn & Teller's "Fool Us" show, and I think even stand a good chance of fooling them.
Food for thought. :)
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
I was so ready to vote meh on this run, but it kept getting faster, and faster until it entered the realm of ridiculous. Great work on achieving the humanly impossible. That's what we look for here. Yes vote!
I think I see where the rules support starting from application start:
That is, the following option must be chosen:
"Record from power-on/start"
It's that "/start" that covers this scenario. Do I have that right?
Where I got confused is that the header says:
The movie must begin from console power-on
I took the "console" to be the Windows or Linux machine.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
For games using a program like libTAS (as opposed to a true emulator like jpc-rr), where boot-up can vary so drastically, I think it makes more sense not to include boot-up sequence in the timing. The only way to effectively compare runs using libTAS/Windows is starting from a point where consistency should be guaranteed which may be game-start instead of power-on.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
I recently discovered that Windows and Linux TASses don't need to start from power on. DrD2k9 provided a good explanation for why this is, but I do think the rules need to be updated to reflect this. Current rules say that "The movie must begin from console power-on" which is not true for Hourglass and libTAS movies.
On a related note, this is something that will need to be considered when defining how to compare libTAS vs. JPC-rr DOS runs.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
fsvgm777 wrote:
c-square wrote:
Isn't it supposed to be timed from power on?
It does, in fact, start from the moment the game window pops up. It's the same in libTAS.
..unless I misunderstood your question, in which case I apologise.
DOS timing includes boot up of the OS, C64 timing includes loading of the game. I would think Windows and Linux timings would be the same for consistency. Or DOS and C64 timings could start from the first frame the game code is actually running.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
I only counted 94 lives obtained in the one autoscroller. The first five weren't obtained, they were given from the start. No vote.
jk. That was awesome! ;)
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
feos wrote:
The safest way is just following the official instructions. If that's not available, going for the most common CPU speed of that era is also safe. I wish the table gave some insight about popularity.
This is why I think the trend line works very well, as it is likely the closest we can get to the most common CPU speed of each year with the information we have.
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
DrD2k9 wrote:
I think a list of one CPU Divider per year is a very good idea as a resource for new DOS TASers. It would give them a quick reference to know how to setup JPC-rr and know their run is 'safe' from being rejected for the reason of bad emulator settings.
However, I don't think all DOS TASes should be concretely limited to that list; simply because there was variability in real systems, and utilizing variability (within reason) that still yields a valid system environment should be acceptable for the site.
We're in full agreement here. feos, any objection to making this happen?
Experienced Forum User, Published Author, Active player
(372)
Joined: 9/25/2011
Posts: 652
feos wrote:
c-square wrote:
I'm not certain this is what you're asking, but there are three published runs that are considered "overclocked" by the table I posted last, and by the current rules would require being recreated from scratch to improve them:
How does gameplay change between the divider that was used and the one that should be used?
The currently published runs play faster than they would under the new rules. That should be the only change between a faster divider and a slower divider.
For what it's worth, I have no intention on revisiting the HHGttG run, so the grandfather rule isn't a big thing for me. I'm much more interested in having a list of one CPU divider per year to keep the choice simple without needing extensive research or fear of rejection due to someone digging up a specs doc after submission.
