Posts for andymac

Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
EDIT: I saw your post before you deleted it, also it takes about 20 mins to learn python. Qfox, you've got some valid points. Executing the keyword print generates a new line every time, so it doesn't fit with requirements if you use print more than once. Also, (OmnipotentEntity got me with this one), you can't use print, you must use sys.stdout.write, because if you use print, a new line is generated after the program executes which is considered trailing whitespace. Your first one actually runs, but all the numbers are in a giant column, they are the right numbers though. The second one gets a div0 error, but correcting you:
print 1
for x in range(1001):
  for y in range(2,x):
    if x%7!=0 and x%y==0:
      print str(x)+' '
you still get a giant column of numbers, and many of the numbers repeat themselves, but to give you credit, they are the right numbers, and you do know nothing about python. the last one give syntatical errors, you need that new line, you can't just have one giant line of code. Believe me,it seems sensible to try any of the alternatives that you provided, but I am about as knowledgeable at python as you are (I learned all the python i know yesterday) . I have tried most of these things, and they need extra code to make them work, if you were to ask me my opinion, I would say ytterbiums solution is the absolute fastest one there is. A 'sets' approach may be more efficient. on a semi unrelated note, I was going for the "other" category and decided to use NASM because it looked interesting. (it compiles into machine code). Anyways I started off with a nice easy print the first 1000 numbers on screen. It compiled to only 30 bytes and when run produces a window that will not close, makes an indefinitely occuring beeping noise, and displays random characters in the command prompt. Now where the hell did I go wrong to produce such an abomination.
ƻ뤀ϨḁĀᚋĀ঴⇍ูĀ䲴⇍
that's the code. name it anything.com. use at your own risk
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 no idea, I just assumed that because if the flagpole glitch is just jumping into the square at the base of the flag, then you should be able to do it because you had previously jumped into the wall in 1-2 to get to warp world. If you dont think its possible, then it probably isnt. you know much more than I do.
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 gave a six for both, you didn't use the flagpole glitch, but all the other tricks were executed well. as for entertainment, it's slow because you're walking, but it's better than the previous run in this respect. overall, I think this run should be published, as an improvement over the previous run.
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 didn't see your pm. Alright, well, I'll just enter the 'other' section. Isn't python supposed to be the easiest programing language to write? it's caused me so much grief, I must be really bad at programming: faildogs.com
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
it still works and it's shorter, so why not? EDIT: i'm an idiot:
EDIT: Clarification, output is expected to STDOUT, not to a file.
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 this is below 118 characters:(python) I'm not going to enter this because it is almost a direct copy of Ytterboiwhatever's code. I used the "KISS" theory. Undoubtedly it can be improved if "import" is used, but I know too little about python to use it efficiently.
d='1'
for x in range(1001):
 if x%7!=0 and any([x%f==0 for f in range(2,x)]):d=d+' '+str(x)
print d
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 would have been my first program! go easy on me, I've never programmed before.
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
For brevity and execution speed, this challenge is for only numbers up to 1000. You may use any of the following (partially arbitrarily chosen) languages: a) perl b) php c) python d) ruby
you can't use C
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 learned something: python is incredibly easy to learn. Sending you code in about 10 mins. EDIT: I have a question: can the output be 1.0, 2.0, 3.0, 4.0 ect. I made my own "prime" function and it turns out I can use less characters if it prints to one decimal place.]
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
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Experienced Forum User, Published Author, Experienced player (619)
Joined: 11/30/2008
Posts: 650
Location: a little city in the middle of nowhere
Heh, my sister got me a playboy and some other porn mags. I liked it, but my parents weren't too impressed :P
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
Yeah, merry Christmas! and g'day from Australia. (Australians have the benefit of being reasonably close to the international date line, so we get Christmas before everyone else, suckas!!) Sorry I couldn't add another language, oh wait yes I can! everyone knows "Feliz Navidad": "Feliz Navidad!, prospero ano y felicidad" I guess that's spanish.
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 movie was awesome, I only watched one third of the encode, but the m64 is excellent.
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
What I think would be awesome would be using extreme precision to jump up walls at every 16 pixel boundary.
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
EDIT: removed post Just want to wish everyone, including Xkeeper, a very merry Christmas and an awesome new years
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
EDIT: this paragraph has been removed due to excessive foul language The reason this doesn't apply to sonic games is because it has two distinguishable dimensions, the reason it doesn't apply to Ecco is because you don't use an analog joystick, and the reason that it doesn't apply to sm64 is because you can't turn while in midair, which happens to be when you're traveling the fastest. None of these reasons have any proof to say that my theory is bullshit. Next time actually provide an example that actually disproves my theory, and I'll give you a fucking medal. No hard feelings right?
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
Kejardon wrote:
badly programmed my fucking ass.
Common / popular is not mutually exclusive with bad.
yes, but what happens if I want to TAS a popular but badly programmed game? your losing sight of the point. Also you only need to save 1 unit in some circumstances to save a frame. If you fall just short of your target, you may want to use this to save that frame.
DaTeL237 wrote:
anyway, in general, I was wondering if the tiny speed increase would weigh out to the increased traveling distance when using such a non-direct route. Or do you think that by abusing the erroneous rounding you'll end up in the exact same locations?
there is a definite gain, no matter what your max speed is (in smallest units). For higher speeds, you have to deviate less to gain speed. At relatively low speeds, you can deviate larger amounts, but the distance gained is tiny compared to the speed gain (which also happens to be tiny).
Kejardon wrote:
I'm speechless. I know that even commercial games occasionally get away with horrible programming flaws, but for such an easily avoided flaw to be common? o_O Why would you even use an exponential value for a character's position?
The x,y,and z values are most likely stored in this format: p*2^q. This means that as p has a certain number of bits, as q increases, p loses a degree of precision. They use this format to prevent overflow, but at a cost. This is generally a small cost . Most values stored in the RAM actually benefit from this because at large scales, smaller numbers become insignificant anyway. It's like measuring the width of a football field with plank lengths. It's ridiculous and generally unnecessary to have more than a certain number of significant figures. However, if some values overflow, it becomes fatal to the game's operation. Programmers probably don't nitpick around to find the best type of integer length and format for every value. A "One size fits all" approach would be the most used. If the exponential format proves to be a loss to some values but is generally suited to the rest, it will most likely be used. Anyways, the spasm glitch does not generally occur during normal gameplay. It usually requires the use of a glitch to exceed the game's boundaries. Programmers generally think you will stay within the game boundaries and play like a normal human being. When they programmed sm64 in 1996, they probably weren't thinking emulators would be so prevalent and that a 5:28 completion would be possible.
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
sonic and ecco would both not benefit anyway, no matter how insignificant the gain would be, it doesn't apply to those games. for sm64, the speed is 55 for normal play, but can exceed 60k while bljing
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
Both Xkeeper and upthorn are overestimating games. It would be completely unheard of to move at 4000 units per frame. Generally, programmers don't need that degree of precision. unless you want to measure the radius of a virtual atom, your character's speed will rarely exceed 100, except in games where the speed is generally high, or there are a wide range of speeds. For example racing games or grand theft auto. In GTA, your character's speed would rarely exceed 100 whereas in a vehicle, it may do. Generally you don't need to measure anything smaller than a millimetre, and a characters speed, divided by 60 or 30 (frames) will generally give <100. your character most likely won't move more than 10cm per frame. Just bringing up GTA again because I know a little about the workings of San Andreas. Most well programmed games (SA is not nearly like cheetahmen, you've gotta be shitting me). Work on an exponential system, the characteristics of these games is that there is no overflow and that the further away you get from the origin, the less precision you have. Basically If you have a glitch that allows you to travel further away from the map than normally expected, your character will begin to spasm and expand/contract and generally asplode. This is extremely common in games. I have seen this in GTA-SA, SM64, COD4 and countless others. Back to grand theft auto, The precision is six significant figures. 1 unit is approximately 1 metre/yard in GTA-SA, and the map is 6000 units across. Therefore if you are at the edge of the map, and the units are metres, the precision is one centimetre! At a generous 20 cm per frame, your speed is only 20 of the smallest measurable unit, not 4000. Only in 11% of the map is the precision a millimetre, and only a minute 0.00027% of the entire game's standard map is the precision greater than a millimetre, only then will your speed reach over 2000, at that stage, you're right, this is useless, but in the other 99.99972% the map, my theory is surprisingly relevant. GTA-SA was widely acclaimed and has sold over 21 million copies! badly programmed my fucking ass.
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
to tell the absolute truth, Personally I think that the speed gain is slightly less than that of the smw hopping glitch. The speed gain is small, but remember, you're gaining units 30 times a second, so it adds up. As for examples try the one on the previous page, I have provided enough info for you to construct this for yourself. I would gladly provide an image but it's too much work finding a suitable host that won't crash. EDIT: off topic, but I'm now a member and not a newbie anymore! 30th post!
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 this example it was impossible to travel at 25 unless traveling straight along the x or y axis. it's not about gaining speed, it's more about minimising the loss.
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 number of things: AKA was wrong, the game crashes when Mario's speed reaches 65536/5 it's 65536 in one direction and 65535 in the other (actually scratch that, Im not thinking straight, it would be an unsigned short integer. Its 65536) . I'm not sure quite which, because I haven't experimented with this value, but it definitely is not 65526. I'm assuming that Mario's x,y,z,Dx,Dy,Dz, and direction and magnitude are all stored in the RAM and that none of these values can exceed a certain amount before something unexpected happens like overflow. 3d games are precise enough. 55 is in units per frame. Generally speed is measured in subpixels for 2d games and that is generally considered to be precise enough. This is basically the same precision, but the equivalent for 3d. There are no decimal places. I have an example in front of me that proves what Im talking about. Its where your maximum speed is 25 units per frame and you travel in a straight line at a 45 degree angle. your velocity rounds down to 24.04 units per frame. If you deviate on a gradient of 17/18 for one frame and 18/17 for the next, your velocity increases to 24.74 units per second at 45 degrees.
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
Upthorn is the only person who gets what I'm talking about here. The gain for keeping this in mind might be a frame every five minutes saved. At 55 units per frame, say you save half a unit every frame, it's only four seconds before you save a frame, and beleive me, there are enough for-second treks in a game like Rayman 2. Also a lot of people are assuming that Rayman 2 is a 2d sidescrolling platformer (moozooh). It is not. Rayman 2 is a sandbox 3d platformer. I don't blame you, because you stated that you've never played it before. Also you need two ambiguous dimensions for this to work. horizontal and vertical do not count. you would need both horizontal or both vertical (obviously not possible). sometimes, there are three ambiguous dimensions, generally in games where there is no gravity/ flying sims. The mathematics then gets more complex. Games that will not benefit from this theorem: sonic games side scrolling mario megaman Games that will benefit: 3d games top down racing games SUPER MARIO 64 (only when moving normally. while blj ing, the rounding errors become insignifcant and it would require about a full minute of blj ing to save a single frame) next person doing an sm64 TAS might save 2 or 3 frames by doing this
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
What I'm talking about here is when two dimensions are ambiguous. For example, a 3d game, where there are two horizontal ambiguous directions and one distinguishable height dimension. The horizontal speed is generally independent of the vertical positions or speeds. However traveling along a flat piece of ground will have the same approximate speed no matter which direction. Also Pythagorean theorem is just a clear method of showing my point, the actual game would most likely use standard trigonometric functions in order to find speed and direction. This theory generally applies to 3 dimensional games and I would be surprised if there are more than 10 two dimensional games that would benefit from this theory.
Measure once. Cut twice.