Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Samsara wrote:
compucat wrote:
I thought I'd finally register here (hi!) and keep an eye on this thread
So this is actually my biggest concern about the whole event.
As a whole, TASGiving felt almost entirely separated from TASvideos.
...
It's honestly worrying me how much of a growing disconnect there seems to be between TASvideos and the TASbot community, and being left in the dark like this did nothing to alleviate those worries.
Speaking as an active(ish) member of both communities:
TASGiving was almost entirely separated from TASVideos. The event was neither conceived nor planned in our forums, nor did it require any direct involvement from our site (or members of our site acting directly for our site) to be the event it was. Some TASes from our site may have been used during the event, but the licensing we use for our content allows for that. Yes, some members of both communities were involved, but that doesn't mean our site had anything to do with the event itself.
I can understand that some may have a desire for the TASing community as a whole to maintain a strong degree of cohesion. However, as with anything that grows as large as TASing has become, it's nearly guaranteed that disjointed perspectives/approaches will develop and ultimately lead to some degree of disconnection between those varying perspectives/communities.
We've arrived at this position in regards to TASing. And while TASVideos may be the largest and/or most well-known site for classic TASing and its resources, we hardly own the concept in the sense that we can make demands on other TASing communities: regardless of whether or not they've stemmed from our own. Using the phrase "being left in the dark" suggests that there is some impetus on the TASBot community to keep TASVideos 'in-the-loop' of all things that are happening there and that they have somehow failed (or intentionally kept information secret) when that information hasn't made it to our site/forums.
There are members in each community who have no desire to be involve with the other community. We cannot suggest that it is somehow wrong/improper for long-standing members of the TASBot community to not be members here. If someone actively involved in the TASBot community has no desire to create/submit TASes themselves or get involved in our forums, they have no reason to create a membership for our site regardless of how involved they may be on the TASBot side of things.
While it would be nice for someone in the TASBot community to keep TASVideos apprised of everything that's occurring in that community, it's just not feasibly possible in my opinion. I'm in both communities, and I sure don't have the time to do it. I can't keep up with everything happening in either community individually, let alone be able to concisely summarize all that's happening in one of those communities to effectively present that summary to the opposite community
Beyond the feasibility though, I don't feel that it's necessary or even overly important that the TASBot community to be expected to constantly report back to TASVideos on what's happening over there.
While they still promote classic TASing and TASVideos, the TASBot community has grown into something with a much broader view of what to do or even can be done with TASing tools compared to what TASVideos is focused on. This should be easily observable by how often the TASBot community has exhibited things which 1) cannot be submitted on TASVideos due to limitations of our site and 2) would be rejected for not meeting the rules of TASVideos if they were able to be submitted.
We cannot fault the TASBot community for growing further apart from (or perhaps someday even larger than) TASVideos simply because they have chosen to take TASing in a different direction than what our site's restrictions are for potential publications.
It is the absolutely these varying directions that the TASBot community is taking with TASinng concepts that fundamentally disjoint it from our site. That community doing anything in lines of communication to keep our community involved/aware of what they are doing is as much a courtesy as it is anything else.TLDR: I understand how it may be frustrating to some TASVideos members to not know what may be going on with the TASBot community; but we should not feel "left in the dark" when we aren't directly told everything that's happening in that community. There is no forced regulation on them to tell us anything they are doing in the first place, nor should there be. The impetus for knowing what's happening in either community is the responsibility of any individual of one community wanting to know what's going on in the other.
While there is a degree of sadness that the TASing world as a whole is becoming somewhat disjointed, we should not be surprised by this. Further, we really should be thankful that our site continues to be mentioned and promoted when the varying directions that other TAS communities follow give them the opportunity to promote our site as well as their own pursuits.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
First thought: Many PC games (at least in the 90s) were released with some form of documentation--either in the manual, or on the game's packaging itself--that provided minimum and/or recommended system specifications.
If the game being TASed included this form of minimum/recommended specs, those should be settings of the emulated system regardless of year of release.
Second Thought: While the idea of 3 major generalized settings that should cover most games definitely makes things simpler, it also goes somewhat contrary to the way things are currently with JPC-rr as the only effective method of TASing DOS.
Current/JPC-rr method: Essentially, in games where the speed of gameplay itself is affected by the CPU speed, the emulated speed is limited to speeds available at the time of the game's release. If ONLY loading times were affected by CPU speed, any emulated speed is allowed as it doesn't affect gameplay itself.
Unfortunately, this presents a dilemma with the '3 Generalized Settings' approach.
1) If the generalized setting is from somewhere in the middle of the era, latter games in that era will be emulated slower than for systems they were released.
2) If the generalized setting is from the near the end of the era, some games from early in the era may be emulated at much more rapid speeds than systems for which they were intended.
3) Either of these effectively allows for games to be played outside of the CPU speed limitations that are currently imposed on DOS runs created in JPC-rr.
Regarding #1 above, if the later year releases of a given era are allowed to be TASed with the settings of the next highest era, this again could result in the game running at significantly faster CPU speeds than intended.
Regarding #2 above, this would likely affect 80's era games more than 90's era(s), as a comparatively greater percentage of 90's era games have gameplay speed tied to real time as opposed to CPU speed.
For reference:
CPU speeds in the 80's ranged from under 10mHz up to 33mHz. Meaning speeds could be up to 3 times faster for an early released game played at end-of-era settings.
CPU speeds in the early 90's (1990-1994) ranged from around 20mHz up to 200+mHz. Meaning speeds could be up to 10 times faster for an early released game played at end-of-era settings.
CPU speeds in the late 90's (1995-1999) ranged from around 150-200mHz up to 1GHz. Resulting in speeds which could be up to 5+ times faster for an early released game played at end-of-era settings.
TLDR:The idea of 3 generalized settings sounds like it should be effective enough. However, looking at the rapidity of how quickly CPU speeds increased over the years, shows that a large discrepancy in CPU speeds still exists from the beginning to end of each of the three noted eras.
In the for what it's worth category:
I understand the desire for accuracy/authenticity of emulated systems for TASing. This desire is what has driven both previous and current discussion about PC emulation settings.
However, when it comes to TASing PC/DOS games, I feel we also need to consider that one core concept of TASing is to show superhuman ability.
Given that real humans are speedrunning some of these games on real systems with MUCH higher than intended specs or on unthrottled emulated systems; it is theoretically possible that a human could outmatch a TAS which is forced to be limited to release-date specs. (I'm actually wondering if this will be the case for King's Quest 6, which I've done some basic TAS work on--the RTA community uses an unthrottled emulator which affects movement speed at the highest in-game speed settings). If this occurs, then the TAS is only partially superhuman:
1) If the human is forced to run on native specs, then the TAS would be superhuman.
2) But if the human's unthrottled run is compared to the TAS, the TAS may no longer appear superhuman.
So considering both superhuman play and the concept of fastest completion, I personally have no problem with TASes of DOS games having no CPU speed restrictions at all. Even from the perspective of obsoletion in TASing, I'd be fine with a higher CPU speed run obsoleting a lower CPU speed run even when CPU speed affects gameplay aspects of the TAS.
For example: If the highest CPU setting that one TAS author is able to complete a game is 100mHz, and the submission is published; then another author comes along and is able to beat the same game at 300mHz speed resulting in a faster run. I feel that being able to finish the run using 300mHz speed when other's can't shows greater TASing ability than the author using 100mHz speed. Obviously this would only apply to situations where the CPU speed affects gameplay itself and loading time is disregarded.
I realize there may be many in the community who would disagree with this particular perspective, and I realize that this perspective is unlikely to result in changes to the current rules for JPC-rr or for the rules ultimately created for PCem. I offer it mainly as a way of documenting that this is a perspective that exists in the community.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Yea...I'm not sure how I missed the "4/1." I guess my eyes were just drawn to "Maximum" and I was confused why you were promoting a high golf score. Sorry for the confusion.
FWIW, my thoughts still stand otherwise.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
I'd argue that for a golf game, a "Maximum" Score run would actually be the minimum attainable score.
In my opinion, the concept of "Maximum" score from a vault standpoint is essentially the idea of the best possible score performance, not necessarily the highest numerical score value. In most games, that means the highest numerically achievable score. In others games though (some racing games for example) it may mean the lowest achievable time (which may be the best score performance for that game). Given that the best score performance in the rules of golf is actually obtaining a low score, it only makes sense to aim for the minimum numerical score value.
Besides, going for a high numerical value score in golf is actually intending to play poorly, which is somewhat contrary to the superplay idea of TASing in the first place. Given, as you've already noted, that the upper limit of score is capped at 2x Par; the maximum numerical value score can be clearly defined. But given the capped value, it also becomes trivial to achieve.
While it could be argued that whoever can get to that score the fastest still offers a competitive challenge, it still requires intentionally poor play. To achieve the max numerical score; one would only have to hit the ball out of bounds or into water hazards repetitively as needed to rapidly increase the stroke count, then make sure the ball is holed on the stroke that will yield the capped score value.
On a side note, while it can be anticipated that a minimum score performance in a golf game would also yield the fastest overall time, it is theoretically possible that a slightly higher than minimal score may be performed faster. For this reason, I believe that both a fastest completion run and a "Best Score Performance" run could be published side by side in the vault if they aren't the same run.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Thoughts on the above area problem...
Graph depiction
Assuming a standard graph with X on the horizontal axis and Y on the vertical...the displayed picture actually shows y^6 + x^4 = 36xy + 4 instead of the given equation. Basically x and y are swapped.
This is effectively moot because the area will be equivalent with either of the equations.
Finding the solution
As far as solving the question of area....one option could theoretically use calculus.
Using the four component functions that are required to make the above shape (see these super complex functions are here), one could use integration from the necessary x values on those functions to yield the areas between the curve and the X-axis. These resulting area values could then be added/subtracted appropriately to yield a final answer that would be the area.
So why didn't I find the answer?
HA! I'm not smart enough to do the integration on those crazy equations on my own....or even figure out how to get wolframalpha to do the integration for me.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
It's slightly off topic, but I'm going to throw in some thoughts here regarding SGB.
There are literally NO games designed to be played on the SGB as the primary system for playing the game. Every game released with SGB enhancements was first and foremost intended to be a GB or CGB game. From the perspective of playing games on the systems for which they were originally designed, we really should question why SGB would ever be preferred over the same game in GB or CGB mode.
Further, SGB enhancements are almost entirely cosmetic (visual/auditory) variations; only a small percentage have gameplay impacted.
Of this list of games with SGB enhancements, only 31 out of 529 have multi-player support. I can find no other information on any game where the enhancements provided by the SGB offer anything new from a gameplay standpoint. So that leaves less than 6% of all SGB enhanced games having anything more than cosmetic variations when played on the SGB.
Of those 31 games with multiplayer support, I don't know if all are simultaneous multiplayer or if some are multiplayer via sequential turns. Many of those that could potentially have simultaneous multiplayer are fighting games; meaning that the additional multiplayer gameplay enhancement provided by the SGB would be effectively meaningless from a TASing perspective aiming for beating the game as rapidly as possible. It's also possible that the multiplayer aspects of these games that the SGB allows could be just as effectively played using link cables.
The SGB (at least the original version) itself also has faster CPU timing than the handheld systems for which the games were developed. It could be argued that (at least in some cases) this difference potentially alters gameplay from what was intended.
TL:DR
If we're going to be making the argument that games must be TASed by emulating the original intended hardware, we should never prefer SGB over GB; because SGB was never the primary intended hardware for any game regardless of whether SGB enhancements are present. If developers had wanted the SNES to be the primary system that their game was played, they would have created a SNES game, not a GB game.
The SGB was nothing more than a gimmick for Nintendo to sell more systems. There's nothing gained by TASing a game in SGB mode regarding any new game content that wouldn't be available TASing the game in standard GB or CGB mode.
TL:DR #2
None of this post suggests what should be done regarding allowing GB in CGB games or not, but it should cause us to question why we'd prefer SGB mode over standard handheld modes.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Nach wrote:
Memory wrote:
Those jumps are absolutely possible on DMG and the fact that it's a TAS means you might have trouble doing them real time.
The jumps that were bothering me took place in 6-6.
I see DrD2k9 taking the most direct and obvious route possible, which I tried many times and could never accomplish. I had to come up with a different and less obvious solution. It's possible it requires frame precision to get the jump just right. But it seems impossible to me that the spikes can just be jumped with the key. I don't know that they're possible on a DMG, but I'd be happy if I was proven to be wrong about that.
It's actually possible to clear the spikes in 6-6 either direction both against and with the wind without using the wire.
When going left against the wind, it requires handspring jumps. Going right with the wind actually has a relative large window in which a standard jump will cross the spikes (9 frame window for both sets of spikes).
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
To add to the above post regarding allowing multiple cheats for a given memory address:
Another reason to allow it would be for setting two different cheats on the same address that would allow for different results depending on the 'compare' value.
The following (while not exactly practical) is a valid example:
In Super Mario Bros., the RAM address for lives is 0x075A.
Cheat #1 could watch for a compare value of 0x00 at that address and set the value to 0x01. This would effectively produce infinite lives while still allowing the displayed number of lives to change when displayed between lives/stages. The lowest value displayed would be 2.
Cheat #2 could then watch the same address for the value 0x09 and write a value of 0x08. As the above code produces a minimum number of lives, this code would limit the upper boundary of number of lives so that the displayed value could not surpass 9 when shown between stages/lives. While not really impacting gameplay, this code could be used for aesthetic reasons to prevent a crowned/glitched lives count.
Even thought they are for the same address; as these two codes watch for different 'compare' values, their effects would never conflict.
Therefore when these two cheats are utilized together, the displayed number of lives on the screen between stages/lives would never be outside the range from 2-9.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
WarHippy wrote:
I know it’s pretty late for this, but there are several levels where on the final screen you simply land and walk all the way to the end. Is there a reason you don’t try using up fuel during these sections? And does it cost time to fire the laser? Just another way to use up fuel before the end. (I’m assuming less fuel equals faster level end)
The power/fuel meter is simply a timer. Hovering doesn't cause it to reduce any more rapidly than standing still.
I tested hovering on the very first stage of the game. Simply starting the stage and standing still results in death due to power loss at frame 6526. Staring the stage and hovering upward continuously until the power meter is drained also results in death at frame 6526.
I honestly didn't check this aspect of the other two ports (probably should have, and I will do so then update this post as I'm able.)I did not test continuous firing the laser, but I will and include the info when I update this. EDIT: Firing the laser did not impact the rate of power decrease either.
EDIT 2:
For both Coleco and Atari, the Power meter is also just a timer; Hovering and laser firing have no impact on rate of decrease.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
I don't agree with the maximum lives classification.
The lives value clearly rolls over; and thanks to the additional overlay, we can see what the equivalent RAM value is. While this does stop increasing briefly at -8, it restarts increasing later on.
Unless I'm missing something, this movie doesn't achieve maximum lives...it only (apparently) achieves the maximum obtainable lives before the first stage timer runs out.
Given that the lives counter completely rolls over at least once through all 256 possible values in this video, it can be assumed that further rolling over of this RAM value would be possible using subsequent lives on the same stage.
Therefore, this movie fails to achieve what it claims it is because a maximum cannot be defined.
Further, as already mentioned. this doesn't beat the game.
While interesting, I don't believe this video is publishable.
I would be interested to find if increasing the lives value above 0xFF affects the next RAM address value in such a way that may lead to a glitch.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Radiant wrote:
Yay! That's the version I was hoping for when this site got its first HERO run. Plus I always like being able to compare various ports of a game.
Yes vote!
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Maybe my recent DK run can stand as a pseudo-example.
While it has now been console verified, it took extra preparation work (involving pre-seeding the system's wRAM using a different cart) to make happen.
Thus, the inputs in the publication alone aren't always going to work on console.
This results from the fact that BizHawk uses a standard initialization of wRAM (for determinism sake) before the game code is run. However, the game itself uses uninitialized wRAM to seed its RNG as opposed to a preset RNG seed value. As this uninitialized wRAM can vary from console to console (or even on the same console depending on the previous game played), the published movie isn't going to console verify consistently without actively preparing the wRAM before each and every console verification attempt.
This means that even if the game completely syncs a run on the console without issue, shutting the system down and restarting will likely result in a desync on a subsequent verification attempt, as the wRAM most likely won't match what it needs to for the run. Doing multiple console runs in sequence would require additional human intervention beyond the power cycle and TAS start. Namely, between runs the wRAM would have to be actively pre-seeded by cart swapping once again before the system could be power cycled for the TAS run.
By contrast; typically once a NES game has been console verified it can be reasonably consistently repeated without any extra intervention from a human beyond simply power cycling and then restarting the TAS.
EDIT: Sadly, I don't believe this type of desync issue is something that can be rectified from an emulation or TAS creation standpoint. So it doesn't really help much from a development perspective.
EDIT 2: (Much Delayed) My DK run has been verified.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
GJTASer2018 wrote:
I previously tried to improve the current submission for this game in BizHawk 2.3, but got stymied on the first "U-Turn" hover (on Level 8). For some reason, I couldn't get the player to "snap" to the ground at the end and had to manually land him instead, wiping out the previous gains I had accomplished. I gave up at that point because I assumed that the previous submission took advantage of an emulation bug (and that "proper" emulation would result in a slower submission as a result), so I would like to know if my initial conclusion was wrong or if there really WAS an emulation problem in that version...
I'm not sure exactly all the ways the emulation differences affect the run. What I do know for sure is only at the beginning of the run. There are 5 lag frames at the beginning in the old run. There is only 1 lag frame in the new one. This allows for a faster start in the new version.
As far as improving the old run. I copied the inputs from the old TAS and put them into the newer BizHawk version. I then went through every single screen making improvements everywhere I could (NYMX then found further improvements). So I don't even know if our improvements would carry over and work in the older versions of BizHawk.
I suppose it could be theoretically argued that all the frames we saved from minor movement optimizations could be attributed to emulation differences; but I strongly doubt that's the case.
In the comparison video, I dumped the current publication video from BizHawk 1.11.9.1 and the video for this submission from BizHawk 2.5. Even still, if you look close, it's possible to see some instances where the current publication gets closer than necessary to the rock walls before dropping bombs. So there was some optimization done beyond emulation differences.
All that said: Without seeing your inputs, I can't explain why you had trouble with the hovering "U-turn" in stage 8 on your attempts.
NYMX understands the flying mech a bit better than I do, so maybe he'd have some insight.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
EZGames69 wrote:
>DrD2k9 & NYMX's Coleco H.E.R.O. in 09:20.42
>DrD2k9 & NYMX's A2600 H.E.R.O. in 09:48.27
>NYMX & DrD2k9's C64 H.E.R.O. in 10:07.03
This annoys me to no end.
The one who did the bulk of the work for each port was listed first.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Something else to consider with TASing a DOS game for TASvideos.org is that some DOS games need to be run at native CPU speeds in order to be eligible for publication.
Here is the pertinent rule.
In the youtube video linked above, DOSBox is set to Maximum 100% cycles for CPU speed. This means that the emulated CPU may be running faster than a CPU that was actually available at the time of the game's release. This could potentially be allowing for faster movement/actions in-game than could have been done on a proper era CPU.
All that said, it's possible that a JPC-rr TAS could match or even be faster than the video posted. Primarily, the RNG would be knowable and the inputs could be planned in order to eliminate any time loss from unknown RNG events. Also, it may be possible to manipulate the RNG; either through altered input or possibly by altering the emulated real time clock settings (as has been done in other DOS games published here).
Further, JPC-rr (with TAScript) allows for sub-millisecond precision with inputs, which may provide opportunity for an even faster run.
Sadly, I don't know of a way to convert what you have to a JPC-rr movie/input file. To TAS this game in a way that would be publishable using JPC-rr would likely require a complete redo.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
Chakratos wrote:
EZGames69 wrote:
You need to get an NTSC console.
But then i had to rebuy all the expensive and "rare" games i already own :(
Isn't there any other way? Or maybe some PAL Tas M64 files?
While TASvideos.org is the one of the primary places regarding creation and archiving of TAS runs; console/hardware verification is not as big of a part of this particular community. We do mark runs that have been verified on consoles, but the actual work of console verification isn't heavily discussed here typically.
If you're wanting more information on running TASes on original hardware, look into the TASBot community. Individuals there are more heavily involved in running TASes on real hardware, and they can likely give you some good direction on how to proceed in achieving what you're desiring.
https://tas.bot/http://discord.tasbot.net/
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
psychicide wrote:
no... i know there's no game page, but what i''m asking is: how do i get a game page to be created?
It depends on whether you are wanting a publication page, or a resource page created?
Publication Page: Submit a TAS worthy of publication and the publication page will be created by a publisher.
Resource Page: A staff member can create the page for you, but it will be blank. It'll require editor rights to add anything to that page. If you don't have any pertinent info for the resource page, there's not much reason to create one.
Editor, Experienced Forum User, Judge, Published Author, Expert player
(2081)
Joined: 8/21/2016
Posts: 1018
Location: US
The biggest deterrent when it comes to various sports games is that many of them have a clock that runs for a preset amount of time. Thus there's no real way to "speedrun" them from the standpoint of two runners competing for the fastest time; because no matter what is done in-game, the final run time can be matched fairly easily.
This is one reason that it's difficult to get the TAS of a sports game eligible for vault publication. Moon tier publication would require a certain level of audience entertainment value for publication, but wouldn't be as restricted by the time factor.
If you can prove that there are indeed methods to reduce the overall time of this game somehow and prove that it's not trivial to do so, there MAY be a chance it could be published in vault.
But I think vault publication would be a very tough argument for Tecmo Super Bowl as it sounds like the only way to minimize time is to avoid clock stoppages. While it may not be exactly easy to accomplish (even in a TAS), the minimum possible time is still limited by the game clock. Thus, no matter what any TAS author chose to do in-game, as long as the clock never stops, the minimum possible TAS time will be achieved and is effectively pre-determined.
Ultimately, the decision would be up to the site's judging team (of which I'm not part).
So to answer your question as directly as possible:
A TAS of Tecmo Super Bowl may be rejected as un-publishable in vault if it doesn't attain a high enough entertainment response from viewers of the submission to warrant publication in the Moon tier.
EDIT: Please do not let this response deter you from TASing the game if it's something you want to do.
