Posts for andymac

1 2
15 16 17
25 26
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I thought I might get you guys organised... I started up an SVN repository, which seems to be the best way to start community based projects. If anyone would like to contribute to the run, PM me, and I'll add you as a contributor. http://code.google.com/p/supermario64-120star-tas/
Nahoc wrote:
Is Mario hex editing is easy ?
learn to grammar. Anyway, the m64 file is binary based, which makes it a little harder to hex edit than text based movie files, but it's definitely possible, and sm64 is very sync robust as well. Even lag doesn't affect the game's ability to sync due to the constant in-game time between frames regardless of real time differences. As long as you have a reference frame that is somehow distingushable from other frames, you should be able to easily hex the movie file. Some stars, however, will not be able to be hexed in because of randomness, and many tools (like TASedit) can stuff up your movie file, by misjudging the number of V/I's.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I know what's less work than typing your... okay, fuck this, here's a turtle.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
In the discussion topic for the pokemon gold run, nitsuja provided a savestate that you could load so that the run would sync on v19.3. That's how I watched the run a few days ago.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
The RAW format is the same format that the DS uses for it's save files. The raw save file is 512kb by default but is not completely full generally. You will usually have to remove any trailing 1's that fill up the rest of the 512 kb. Luckily SM64DS' save file occupies the entire 512kb so there is no need to do any nasty hex editing. Here are the steps you need to follow to get your save file working: (8 stars in first file and 57 stars in the second file right?) 1. Open up DesMuMe 2. Chose Config -> save type -> EEPROM 512kbit 3. Rename your save file to the name of the ROM you are using. 4. Open your ROM That worked for me, but I used the european version of SM64DS. So there's a possibility it might not work.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
There are people who will have problems with everything, no matter what you do. How are we going to cater for the people who don't have computers for example. What I'm saying is that when someone says they have a problem, most likely the problem can be fixed but they just don't know how. So, the problem isn't really with the container or format I would imagine.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Beleive it or not, none of the screenshots above used hardware acceleration. There is no antialiasing in the first screenshot. The comparison is between a nearest neighbor interpolation and super 2xSal, and does not represent the scaling abilities of different operating systems. Your output will look like the first screenshot if you enable a special scaling algorithm, but will look almost as crappy as the second if you rely on hardware acceleration. also, the emulator was snes9x.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Just for comparison... I chose this screen because it contains relatively simple graphics and more complicated graphics on the same screen. When applying the hq3x filter, the filter does not dumbly interpolate, but the filter is supposed to intellegently find lines of gradients 0,1/2,1,2 and undefined, and replicate those lines and antialias them. The above image is not scaled with this algorithm, but the super 2xSal algorithm. However the above image does demonstate what happens to source images of varying complexity. When a scaling algorithm encounters a complicated image (like the covers of the games above) it simply scales by 2x with nearest neighbor interpolation, but when it encounters images with less color detail (such as the text) the image is scaled more naturally to a larger size.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
That's something I don't get. Optimisations are killing uploading to viddler? for one that doesn't make any sense. If you are reffering to the cpu hogging properties of that website that is. viddler reencodes the videos before they end up on the site, so the cpu usage would not be related to it's original encoding. Another thing, why would b-frames make uploading to youtube a problem? Barring the fact that it's obviously not compatable, If I were uploading something to youtube, I would get the original input file and do an encode at 10,000 kbps of standard h.264 and MP3 audio with the container being avi and upload that to youtube. Two passes are not needed if you are dealing with those kind of bitrates. So basically, why is it so important that the movie file encoded by TASVideos is the one uploaded to video hosting websites. Isn't it possible to upload a different file for the purposes of compatability? I thought that would be the obvious solution.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
This was epic, rewatching now
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
well done sir!
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I believe Xtra.krazzy knows. Since shortly after I made my post, changes were made on the SVN. Whether I was the cause of this is unknown. But seriously, the 3 bit analog precision that was planned would have killed all gamecube TASing. Those who have tried to TAS n64 will agree that in many circumstances and many games, the precision of the analog stick with 8 bit precision is simply not precise enough. And there are very few games where the full precision of the analog stick is not needed. The reason I brought up the 3 bit d-pad was not because it didn't support combinations like up + down, but because it didn't support diagonals (like up + left) which are part of normal play. Support for diagonals requires 4 bits, so you may as well support up + down as well.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Here's an interesting page... Adelikat, if the website is struggling, have you tried hosting images externally?
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Dailymotion has an option where you can link to a second video from the first when the video ends, this could probably assist with the whole 20 minute limit.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I'm feeling a bit iffy about the dolphin movie format.
For analog sticks, a two bit value for strength would be enough: 00: 0%, 01: 25%, 10: 50%, 11: 100% Each analog stick is 6-bit long: SYYSXX, where XX/YY is strength and S are sign bits Start,A,B,X,Y,Z are binary 1-bit values, summarizing to 6 bits per controller. The D-Pad is a 3-bit value portrayed as follows: 000: No Direction, 001: Up, 010: Down, 011: Left, 100: Right. L, R are 2-bit values, combined with the 6-bit Analog Stick and C Stick, we get 16 bits. 6+3+16 = 25 bits per controller every frame. We reserve 3 additional bits, so that data is readable in hex format (7 hex characters per frame) and future features may be added, such as soft resetting.
The analog sticks should be infinitely more precise, to reflect the precision of the actual controller. I think the precision of an analog control stick on a GC controller is represented by a byte of data per axis. If that precision is available, then it should be accessible. L and R are pressure sensitive, with 256 degrees of accuracy. This should be recorded in the input file. The D-pad should be four bytes not three. Diagonals should be supported and so should up/down and left/right. The data length in bits should be divisible by 8 in order to improve hex readability, even if this means adding an extra 7 bits per frame. EDIT: corrected technical errors
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
this seemed to work for me, I get much better framerates, this may work for others as well. The <p> tags somehow made the video run smoother. also for the record my PC is a 2008 quad core desktop with 4GB ram and 1024MB graphics card, and it struggles with viddler.
<html>
</body>

<p>

<object classid='clsid:D27CDB6E-AE6D-11cf-96B8-444553540000' width='437' height='333' id='viddler'>
<param name='movie' value='http://www.viddler.com/player/99d5f743/' />
<param name='allowScriptAccess' value='always' />
<embed src='http://www.viddler.com/player/99d5f743' width='437' height='333' type='application/x-shockwave-flash' allowScriptAccess='always' name='viddler' allowFullScreen='true'>
</embed>
</object>

</p>

</body>
</html>
Daily motion seems fine with me. For videos under 20 minutes, An admin can easily submit anyone's work. If the video is over 20 minutes, then the creator of the movie can register themselves as a motion maker and upload their own videos to a TASVideos group with no time restriction. The only problem here is that it must be the creator of the movie that uploads the file. As for the comment above, well, yes it's a CPU hog, and half the people here would agree that the videos there are unwatchable because of that. 5fps is not the kind of framerates you want to watch a fast movie on. so no, the videos do not run "smoother" for half of the people here. Maybe not you, but quite a few people. Also wouldn't it be fairly easy, if you hate the layout of the dailymotion website (to ignore it?) to embed it on the TASVideos website somewhere? sounds reasonable to me.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
sorry to burst you bubble, but I am still suffering from 5fps syndrome after watching that. EDIT: I might have figured out one source of my 5fps syndrome. I have no problem playing embedded viddler videos on some websites such as failblog.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I would say that a suitable video hosting website would need to have these characteristics; * Videos are of suitable quality. (ie do not run at 5 fps) * Advertising is kept to a minimum. * Non restrictive size/time limits on videos. Fortunately viddler and youtube aren't the only video hosting websites, take your pick (taken from wikipedia): I'm sure you will find one that matches all the suitable criteria. * AniBOOM * AtomUploads (part of AtomFilms) * BGVIP.TV * Blinkx * Blip.tv * Break.com * Buzznet * Crackle * Dailymotion * EngageMedia * ExpoTV * Facebook * Famecast (music only) * Flickr * Gawkk * Gubb (Gubb.tv) * Tangle.com (formely Godtube) * Google Video (no new uploads) * imeem (ceased video hosting service) * Kewego * Liveleak * Megaupload|Megavideo * Metacafe * MSN Soapbox * MySpace|Myspace * MyVideo * OneWorldTV * Ourmedia * pandora tv * Photobucket * Rayzz * Revver * Rambler (portal)|Rambler Vision (Russian) * ReelTime.com * RuTube * SAPO (company)| Sapo Videos (only portuguese) * Sevenload * TroopTube * Truveo * Tudou (Chinese) * Twango * Vbox7 (Bulgarian) * Veoh * Vimeo * Vuze * Yahoo! Video * Youku (Chinese) * YouTube * Vidoosh (Iranian) * Viddler * Vimeo * Vzaar * Indiavideo.org
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I would have to say that it remains 50/50. the probability of your first born being any gender is 50%, if you had a girl first, then the probability of the second child's gender is still 50/50 and so on. It only affects the total number of children born.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I have to disagree with the whole USB keyboards are limitless thing. The type of port used has absolutely nothing to do with how the keyboard is wired. Better quality keyboards are the ones with higher limits. If you want to get a higher key limit, buy a more expensive keyboard, which is basically what it boils down to, not whether the keyboard uses USB or not. The two USB keyboards in my house have an old matrix setup and have and 18 key limit each. (this was done by counting the contacts along the larger axis of the matrix, not by actual testing)
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I think you are misunderstanding the magnitude of the situation. We are on the brink of having a current gen TASable emulator available and all you care about is whether the movie format is text based or binary? give it a rest.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I know that adelikat and Lord Tom are currently planning on doing a warpless run on SMB 3
I didn't know that, and considering the quality of their warpless TAS, I would suspect they would be able to produce a mcuh higher quality TAS than I could.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I was thinking about doing a warpless run, so I started and rerecorded over the current warp run (1-1 and 1-2), which gave me a 1 frame lead over the published warpless run. I had gained about 2 pixels on the current warpless run in 1-F by not stutter running and still achieving P-speed, but I had to sacrifice 2 frames for hammer bros. manipulation at the end of 1-2, where the published run did not, putting me behind 2 pixels in 1-F. Is there anyone on the original team that can tell me how to make the RNG lag? EDIT: I found a series of values that fits the description of the RNG starting at address 000781. This will probably help.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
A key limit is where some key combinations on a keyboard cannot be pressed. On my keyboard, I can press at maximum 17 keys at the same time, while still legally registering, and it has to be a very specific combination. I recommend mapping the buttons to "shift", "ctrl", "alt" and the windows key because they are generally able to be pressed with many combinations of buttons. On my keyboard, for example, left shift is the only button which is pressed independently from any other button, so can be used with any combination.
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Microstorage wrote:
Microstorage This upload script has a limit of about 2 megabytes, and accepts FCM, SMV, VBM, M64 and GMV files right now. And do NOT zip it, rar it, or anything else like that. FM2 limited support File: Comment: Please include the game name, at a minimum. Please give a good and useful comment. Terse help
Measure once. Cut twice.
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
I like Potato Stomper's idea, as a way of discovering obscure glitches that wouldn't be found otherwise. I'm not so sure of the genetic search algorithm, as I would say a computer would take (if not given an initial input that finishes the game) years to find a single solution to a short game, let's say SMB1. Given say, klmz's movie, and many other previous TASes as parents, I would say if mutation was to occur, the possibility of the game finishing at all would be less than 1/1000 and 1/100 for a creation of a file from chromosomes completely from parent TASes (a very generous probability for both of these). If mutation were not to occur, there would most likely be little or no discovery of new methods to make the game faster, because characteristics would only be obtained from parents which are assumed not to have perfect chromosomes (i.e. not 100% optimal). If perfect chromosomes were assumed there would be no point in a genetic search algorithm in the first place. However, mutating a TAS would mean doing millions of iterations before a solution that is found that completes the game, and completes it faster in some aspect (let's assume that the probability of finding a time saver is 1/1000, which is very generous, considering that human input would usually require this number of rerecords to find a new technique to implement assuming that their input was measurable and decisive, and not completely random). A lot of the time, imposing the restriction that the game must be completed otherwise that child will die at birth, will mean that some mutations, even though they don't complete the game may have some techniques that could contribute to a faster completion. Even if it does complete the game, the solution might have a high probability of being "bred out" in subsequent generations for other faults, and the new method may be lost. Obviously we cannot impose artificial restrictions in order to make the game progress faster eg: must complete levels 1-1, 1-2, 4-1, 4-2, and 8 because the optimal solution could be one that skips one or more of those levels (however unlikely that may be). One of the purposes of a genetic search algorithm in in fact to find techniques that humans couldn't, because otherwise, a human would make the TAS, so you must not assume the fastest solution is known, because of the probability of a sequence break occurring that means that a halfway goal is not obtained but the net time is faster. Even though obscure techniques may be found that humans would not be able to immediately see, I would assume that inherently obvious things such as frame precision may be ignored during a genetic search algorithm, because a human is not behind the wheel. For example you might lose a frame somewhere but save three somewhere else, and since the use of halfway checkpoints would not be able to be used, because of possible sequence breaks, the genetic algorithm may not be able to easily assess the health of the child, and the faulty characteristic may survive into subsequent generations. Most likely however, if the program is indefinitely run, the faulty characteristic will be bred out. All in all, I think that the genetic search algorithm has distinctly human traits about it. For a movie such as the current SMB1, the flagpole glitch has proven a successful trait and has survived into subsequent generations of TASes. Take the current SMB3, both Lord Tom and Mitjitsu had found improvements over the current run (two parents), so the successful characteristics were carried into the next generation. (one child). The difference, (I believe) is that computers are producing blind, random input, whereas the input provided by humans is decisive and has definite intent. IMO
Measure once. Cut twice.
1 2
15 16 17
25 26