Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Wulf2k wrote:
Have there been any situations where it's technically ACE but so slow or limited that it's more interesting to just use it as a quick skip?
I'm thinking something like default data being an instruction to skip to the next room, but maybe if you spent 20 minutes arranging your inventory it would be ACE.
There are multiple cases where ACE has been used to simply skip game elements to reach the end faster without introducing new elements to the game or demonstrating something unrelated to the game itself.
It's not in a published TAS (yet), but the SMB3 run abusing the NES DPCM glitch with subframe inputs that warps directly to the end-game almost instantly after power-on is technically an ACE example that simply skips gameplay.
Link to videoThis SMB3 run is another example of using ACE for a game end glitch.
This Mega Man run also uses ACE for a game end glitch.
These are all examples of runs that simply use ACE to skip some degree of gameplay without adding any custom payload/demonstration.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Regarding duping items: Wasn't it discussed somewhere else that duping doesn't qualify as 100% even if it causes a game to show 100% in the credits? The argument being that the all items had to be collected from their proper locations for a 100% run instead of simply being duped into existence.
My memory doesn't work near as well as some others here; but IIRC, it was in the discussion of one of the Zelda games.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
GJTASer2018 wrote:
I also think it would be worth trying a "max score" run i.e. collect everything you can get to, kill all the enemies you can and find the optimum treasure room run to collect as much as you can out of it.
In my opinion, this would essentially be a "100%" run. I'd define 100% as including all of the following:
-Visiting each room at least once
-Collect all Gold Coins
-Collect and use all swords (likely not enough in each stage to kill all killable enemies)
-Collect all torches (not sure if multiple can be collected within one stage or not)
-Collect all amulets
-Collect and use all keys (or at least as many keys as there are doors); if there are more keys than doors, finish the stage with as many extra keys as can be held (up to 5).
-Collect the maximum possible treasure/coins in the treasure rooms until time runs out.
Truly the only major difference between 100% and max score would be the requirement to visit all rooms in 100%. Theoretically a 100% run should yield a max score run.
Even if 100% didn't require visiting all rooms it would still likely yield a max score. The only major score variable would be optimization/maximization of treasure room coins collected.
FWIW, I have no desire to 100% this game. I don't think it would be any more entertaining, and it would be so much longer with all the backtracking necessary to accomplish 100%. I wouldn't be surprised if it eclipsed the 2 hour mark.
And the route planning would be INSANE!
EDIT: After further thought, I don't think visiting every room should be necessary. We don't require visiting every room in other games to get 100% (Super Metroid for example).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
I've got a message out to the C64 SMB creator to see if he thinks it may be related to the VSP scrolling. I haven't received a reply yet.
I'm guessing it has something to do with how BizHawk processes that scrolling technique.
I've also tested on VICE with no problems and CCS64 as well also with no problems.
EDIT: I received a reply from ZeroPaige (the SMB dev), who suggested I test Mayhem in Monsterland in BizHawk as it also uses VSP scrolling. After testing, I can confirm that it also exhibits this same twitchy background bug. So anyone wanting to update/improve the C64 core now knows where to look to improve this issue.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Asnivor wrote:
EZGames69 wrote:
Do any of these versions contain less loading time for bootup? I wonder if it’s worth using them for this tas simply for convience of the viewers.
Its a standard tap file, so I could probably shunt it into a +3 disk image (*.dsk). However, this involves modifying the loading routines in the code so it knows to load from disk rather than tape.
A potentially murky area maybe.
Media conversion has been discussed before (specifically regarding commodore 64 games). The ultimate result of those discussions being that leaving things in their original/proper format is best unless the format conversion can be proven to be possible by a general user and directly on the original system without the need of additional/specialized equipment.
As much as I'd personally like to see shorter loading times on any system, I also understand the need for maintaining as much authenticity as possible in the media formats.
TL:DR - Stick with the .tap format and don't shunt/modify the code for a different media format/image.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Going a bit off topic with this as it's not from IRC....but...
from heredwangoAC wrote:
The downside of an audience full of perfectionists is that you'll have to deal with us, well, asking you for perfection, but it will be oh so worth it.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
CrowdSorcerer wrote:
Hi! I'm a fan of both TASes and a player of competitive pinball. I found out that MAME supports a limited subset of pinball ROMs, including games from the classic 90s era like The Addams Family and Attack From Mars. I immediately wondered about opportunities for TASing, trying to imagine the ideal set of inputs to complete some objective as fast as possible. I stopped by #tasvideos on IRC, and they suggested that I join the forum and post my progress and ask for needed help.
I understand that pinball roms are not an appropriate for the actual TASvideos concept, because ultimately they are not a video game. The visual aspect is likely to be a spastic flurry of conflicting animations, definitely not something that most people would find entertaining. And because most games loop the score back to 0 when the maximum score is reached, even if all the other things were not true, it still wouldn't be eligible.
With all that said, my small group of friends and I have been discussing a few different "attacks" for Lua speedrunning of pinball ROMs
- High score attack (get to max score)
- Wizard mode attack (complete the final "Wizard Mode" which many games feature after completing many other modes)
- 100% (complete all game features)
I've downloaded a recent MAME mainline and have a basic understanding that a callback occurs once every emulator frame. I'm able to write proof of concept Lua code that would eventually complete a high score attack. I'm not using MAME-rr, unfortunately, because the version it is forked from doesn't support the ROMs in question.
The issue that prompts my post has to do with the interaction between the "switches" which serve as the inputs to the ROM and the emulation of the ROM.
Briefly :
- There is a framerate of the emulation (which is probably the frame rate of the DMD (dot matrix display)
- There is the framerate of the actual ROM (which is how long a switch has to be held down in order to register a "1" state)
Is there some way, possibly by examining the MAME source, that I could determine non-experimentally how to ensure that all switch presses are registered? I'm not sure of where to start, but iteratively hacking at it out of MAME ignorance is opaque enough to motivate asking for help from the experts!
I don't have enough knowledge of MAME or Pinball machines to answer your questions, but dwangoAC may be able to help. I remember him showing interest in human speedrunning of pinball machines a while back. I think he even has a pinball machine or two of his own. Maybe he can offer some knowledge/perspective in this area.
You can likely find him in Discord.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
xxNKxx wrote:
Thanks your reply, but are you sure this things still following TAS rules?
This bug happen in verification movie file, the after file just enjoy from the before. Most pepole when watch the run will ask something "wtf, why this happened like as this", lol
Here's the rule.
If you choose to try the save-anchored route using a verification movie, it's a greater risk of rejection. But due to the glitch opening up another way of playing through a "new" game, a TAS of just the latter run may still be allowed (provided there's a verification movie).
Again, if you do everything in 1 complete TAS, you will have played from boot with a clean SRAM. The question here becomes whether or not the second run is even worthwhile. It may be considered trivial after having already watched through a nearly complete first run (minus beating the final boss) even though only the second run actually beats the game. In my opinion, running the entire game a second time (even if significantly faster than the first run) is likely going to take longer than just finishing off the final boss during the first run through.
If the save-anchored glitched save can be created in a verification run, the staff may allow a TAS just the 2nd run through. This would result in the fastest single completion of the game. I repeat, this method would likely require moon tier response from the community to get accepted/published.
EDIT: oops. Was in the midst of typing this when feos responded.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
xxNKxx wrote:
Hi! I have question need ask how about use a old save file for make new run
My current run: http://tasvideos.org/3707M.html
This guy found new bug can start new game with old file save: https://www.youtube.com/watch?v=MiULZ-z99rY
although I can't understand what he wrote in his video, but I can understand how this bug work, something maybe like this:
- start new game then save to slot 1
- load save game to final battle
- use bug skip battle for run out battle then overwrite save to slot 1
- load slot 1 for start new game with all old stuff having
if this is allow, then I can make new run can saves alot time
A judge would have the final say, but this seems like there are two options you could take.
1) Do everything you've listed above in one TAS project. Then it would likely be eligible for vault if the resulting run couldn't attain moon tier.
2) Start a new save-anchored TAS project from "- load slot 1 for start new game with all old stuff having" and simply provide a secondary verification movie of how the used save file was generated. This verification movie would not need to be optimal; it just exists to provide proof of no cheating on the actual TAS. However, using this method would require enough positive response to warrant moon tier publication as runs beginning from a save file aren't vault eligible, IIRC.
Option 1 would be a longer total run, but would likely be vault eligible. Option would be a shorter run but likely not be eligible for vault.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
GJTASer2018 wrote:
DrD2k9 wrote:
Curiosity...wouldn't a mode B run be faster?
The problem with that is that each mode behaves differently when you reach Level 100 - AFAIK only Mode A has the killscreen, while Modes B and C rollover back to 1. This would essentially mean each mode could potentially have its own branch, given a high enough entertainment rating, and obsoletion of an existing submission could become problematic.
If there's a kill-screen in mode A then completion of that mode is reaching the kill screen.
For Modes B & C though; if nothing new occurs after the roll-back to level 1, the game can be considered endless. thus rules for endless games come into play (at least for vault purposes).
Therefore a completion point must then be defined.
I see basically two options for an end-point:
1) Finishing the 1st 100 levels until the level # rolls over.
OR
2)Finishing just the first 25 levels.
According to this data it appears that difficulty stops increasing after level 25. Therefore, it could be argued that only the first 25 levels need to be completed to reach a point where no new content is introduced to the endless gameplay.
If the first option is used, the completion of a Mode B run would be roughly half the length of this submission.
If the latter option is used the completion of a Mode B run would be even shorter...somewhere approximately 1/8 the time of this run (9-11 minutes).
I don't know how mode C would be affected as I haven't come across difficulty data for the clay pigeons. Thought I would assume if there is a difficulty ramp in that mode it would mimic the difficult ramp of the other modes.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Curiosity...wouldn't a mode B run be faster? While there are a few frames between ducks, the dog would hold up 2 ducks at once instead of just 1, thus halving the wait time within a round. This could significantly lower the overall run time.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
link_7777 wrote:
PikachuMan wrote:
If we're going to do a TAS of this and Gyromite with R.O.B., we need a CRT TV connected to the computer with either a VGA to Composite adapter. on an HDMI to Composite adapter. With that said I'll have to vote no.
There is already a TAS of Gyromite.
I don't think a TAS with a real R.O.B. is very viable. Technically it should be possible if you build in some margin and everything happened to work as expected during playback, but there are a lot of factors. Also this category would be very long with a real R.O.B. (though perhaps 99 phases would be shorter).
If you were interested in making more of an attempt to play the game as intended I would suggest a "virtual R.O.B." category where you would send the correct commands, but just show the R.O.B. activities as an animation (imagine if R.O.B. was also tool assisted and performed activities quickly and accurately). This category would also be a bit long with a "virtual R.O.B.", I would argue that in a lot of ways the R.O.B.-less category in this submission is a more interesting TAS.
A TAS using a virtual ROB may be interesting. Unfortunately, the result may not meet moon level entertainment value. And as the shortest way to beat the game (due to the honor system) is by just hitting the start button as seen in this submission, a TAS using a virtual ROB would likely not be vault eligible.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Niamek wrote:
I didn't mean it exactly like this. I mean removing the rerecord field from the site so it can't be seen by everyone, but the admins (and judges if needed).
Some additional thoughts stemmed from the above.
Is displaying rerecord count necessary once a run is published? If the run is accepted as worthy of publication, does anyone need to know the re-record count beyond that point? If someone wants to try and beat a current publication, whether they do so with more or less rerecords isn't really important so long as they succeed in actually beating the active publication.
I don't personally care if they are present or not in a publication (as I tend to completely ignore the rerecord count when watching already published runs anyway), I just had the above curiosities.
I realize that some may use a published rerecord number as an indicator of how much work went into the published TAS, and thus, use that information to sway their decision on if they want to try and beat the run; but I personally don't think someone else's rerecord count should be a factor in choosing a specific game. I feel that if someone wants to TAS a specific game they should, regardless of how much/little work someone else has put into that game in the past.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
While re-record count can be a very good indicator of how much work went into a TAS; it's unfortunately not a metric that really tells us anything about the quality or entertainment value of the final TAS movie itself.
I'm sure there are published runs with very high re-record counts, that I personally would find boring. Also, there are likely some with low re-record counts that I would find rather entertaining.
Similarly, a high re-record count doesn't guarantee a quality run from a technical aspect; just as a low re-record count doesn't guarantee a poor quality run.
Re-record count may be a useful metric as a tool for helping with the judging process (for example, in helping a judge determine how much effort to put into finding potential improvements before accepting/rejecting a run). It is, however, not a metric that I feel should alone sway a judgement one direction or another; I don't expect this has happened much if ever (I have pretty good faith in our judges).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Radiant wrote:
I suggest Eindeloos. It's a very technically advanced game (for the C64, that is) and offers a huge maze. At the time of release, it was rumored to be impossible; the name literally means "Endless", suggesting there is no end to the game. There actually is, but it took players several years to reach it. It would probably make a good dynamic TAS.
I'll look into it.
EDIT: Looked into it. Have roughly translated the in-game story as well as the instructions and story presented on the game packaging.
Tinkering with controls at the moment. Not a very easily controlled game. Joystick input is only read every 8 frames or so....shooting is even worse....roughly every 16. Lots of lag that varies depending on movement and screen activity.
Interesting note...Radarsoft offered a contest right on the game's packaging offering some nice sounding prizes for whoever could map the game. Unfortunately....I have been unable to find ANY maps of this game.
Thankfully there is a longplay on youtube I can use as a base guide for doing a TAS.
MAYBE if I get REALLY ambitious....I'll map this whole thing!
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Sometimes (if not most of the time) glitches are found by accident; either through casual gameplay or via the course of testing normal mechanics/parameters for a game.
Once a glitch is discovered, then it must be determined whether or not that glitch is useful, or can be made useful.
One glitch that occurs in multiple games results from pressing both U & D or R & L together. Doing these inputs together isn't commonly possible with most hardware (gamepads/joysticks) but the game code itself will still try and process it if they are done together. This can sometimes allow for unusual/glitched results.
Just play around and see if things happen that you don't think the game's developers intended. If you find something that looks odd....congrats you've found a glitch! Now try and make it useful.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
EZGames69 wrote:
Not a judge, but I’m pretty sure that rule is saying a movie cant start from something like a savestate. Starting from “power on” would usually mean when the game actually boots up, which can include the BIOS (if the emulator allows it to play)
Hmmmm...
If this is the case, then perhaps we need to consider a new way of timing DOS/C64/etc runs for publication when they require longer booting/loading sequences.
It would be nice and better reflect the actual speed achievement of these runs to have just the time from when the game is executed to the final input instead of from power-on w/ boot and loading.
As examples:
While it would take more detailed analysis of the run, C64 games could be timed starting when return is pressed to send the "RUN" command to the CPU.
DOS games could similarly be timed from when enter is pressed to send the executable command to the CPU. This timing method for DOS would solve the issue of timing DOS in libTAS vs. jpc-rr (though it still doesn't solve CPU clock speed discrepancies...but that's another issue altogether and off topic)
This isn't perfect as a good number of C64 games continue to have further loading after the "RUN" command, but it would still be better than current methods for expressing accurate gameplay timing. It would also allow publications of C64 games to include only video from the execution of the program by the "RUN" command onward eliminating long boring loading screens from the published videos.
However
Due to the way times are automatically calculated, however, this all would definitely throw a wrench into the automated submission system. Then again we could always just go with the automated time while the run sits on the workbench and have the publications show the actual game-time. This would unfortunately require more working steps by the publishers.
c-squares points/concerns are legitimate.
We may not need to change anything regarding how submissions or publications are handled. This might be able to be cleared up by a rewording of the rules; perhaps adding something regarding "deterministic vs variable boot/loading sequences" simply for clarification.
This situation is probably best addressed/discussed by feos (as the senior judge) and other site administrative staff.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
With our current methods of emulation, DOS (via jpc-rr) and C64 timing should be guaranteed consistent from power-on and through loading; so long as the same disk images are used.
While I acknowledge that inclusion of these loading/boot sequences causes the published time of runs using those systems/emulators to be somewhat inflated in relation to actual gameplay, it's a minor issue because of the consistency.
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.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Something was nagging at me and I just felt the need to run through this one more time...
I saved even more frames mostly through slightly better movement optimization of a few screens.
Here's an updated .bk2 of this run.
As of this file, the BizHawk version is now faster than the current published run. Therefore I've not redone the inputs in FCEUX opting instead to stick with the more accurate emulator.
If I need to cancel this submission and make a new one with this userfile, please let me know.
I'll be editing the submission notes and adding an encode as I am able.
EDIT: Submission notes updated and Encode added. Once someone with the power to do so replaces the submission file with the above userfile, the emulator used will also need updated to avoid confusion.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2057)
Joined: 8/21/2016
Posts: 1012
Location: US
Well I feel stupid for not trying this before now....
It's possible to use the Magnet scroll before Mordamir taunts the player about not having any more defenses. Doing so negates the need to hold A/B through his taunting monologue and doing the spell afterwards. This shaves a bunch more frames from the end of the game.
Can someone with power replace the movie file with the following User movie #53712640492961666?
This does alter the end game making the above encode SLIGHTLY off. Essentially, Mordamir's monologue text will display slower, but the game will still finish as before.
Assuming acceptance: if whoever encodes/publishes the run wants an input file that uses A/B inputs to display the text faster, I can provide that. But this new .bk2 is the earliest I could get a final input to beat the game.
