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
[1558] NES Super Mario Bros. 3 "warpless" by adelikat, andymac, Lord_Tom & Tompa in 47:04.70 <- has the heavy glitch abuse tag [1484] NES Mario Adventure by andymac in 49:42.39 <- doesn't have the heavy glitch abuse tag, even though it uses more glitches (and more frequently) than the other movie. I think either remove the heavy glitch abuse tag from the first movie, or add it to the second should resolve 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
Most likely they will still synch, when the devs change the core, they add an extra flag into the movie file to indicate what emulation settings will make the movie synch. This hapenned when they fixed echo RAM.
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 your problem regarding text in AVI recording, all you need to do is check Config -> Video -> Text in Image.
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
Hmm, when I think about it, Fisher-Yates is probably the algorithm Darkkobold wants. You start off with a list of 180 X's and 720 Y's and randomly shoose one out of that list to be the next number in the sequence. It works because if you strike out an X, it will change the probability of getting an X for the next roll, and when you get to the end, there will be either 100% chance of getting Y or X. This algorithm is guraranteed to get 180 X's and 720 Y's and also guarantees equal probability for all combinations.
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
Or take a list of 180 x's and 720 y's and shuffle it. There's plenty of fast algorithms for that on the webz.
Sure there may be a lot of algorithm's on "the webz" but if you use one of them, you can't be sure it's unbiased. Plus, it's not like my algorithm would take more than a second anyway. Maybe if you're dealing with hundreds of thousands of numbers, then that might be a different story, but I'm almost sure there my algorithm is O(n) if done right, so it's pretty fast no matter how many numbers you want.
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 don't think I understood this. If you're able to manipulate the probability function at will, couldn't you simply assign it to 1 if you have less than 180 X samples and 0 otherwise? Or are there bounds for the probability of X and Y?
There's no randomness in that algorithm. you would always get the same result: 180 x's followed by 720 y's. He wants a random sample that remains as close as possible to 80% in the final distribution. I think a better way to do this, that will always succeed is consider a field of 900 Y's, now generate a number between 1 and 900. Replace the Y with an X at that position, now ignore that position for further iterations of a loop, generate a number between 1 and 899. place an X at that positon, and so on and so forth. Do this until the number of X's = 1/5th of 900. I'm pretty sure this produces a fair randomness sample, it will produce any distribution of 180 x's intersperced with 720 Y's with equal probability. ( 1/(900C180) )
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
Detour for Hammer suit = 760 frames Boom Boom fight start ~ screen transition = 730 frames In other words, the detour takes longer than the fight even takes, so this won't save any time. Maybe you can acquire Hammer suit in a level though ... I'm not sure.
I think you're underanalysing this. If we did end up using the HB suit, it would be is a strategic location as to use it in as many fortresses as possible. For example, if we use it near the end of world 7, we would save time because we wouldn't need to get a fireflower, and would also save time in 4 boom boom fights, blus maybe the boomerang bros. Not to mention bowser himself. Also, IIRC, hammers are faster than mario, so it would save time in 8-2 and maybe a few frames in 8-1 and the body of 7-F 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
I thought that glitch where he finished the fortress insanely early with the hammer suit might save some time. I think it might actually be worth getting the HB suit
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 completely blame Tompa for this :P *shifts blame* because this is just a logical extension of the regular pipe glitch. For the normal pipe glitch to work, you must be on a walljump pixel anyway. Also, unfortunately, this is either the one place where it saves time, or it's one of two, and by the looks of it, it only saved 4-5 frames or so. Also, another improvement to the warpless would be corner boosting. It was only discovered in world 4-something, so it could probably be used before then. Also, there was a 2 frame improvement to 2-1 that involved pressing left before the level to start 10 pixels further to the left, which meant less stutter running. It didn't work with the current HB setup, and we would have needed to lose those frames anyway.
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 not sure exactly why you need collision detection and detection of sprite groups. Most in game characters are a collection of sprites, but their positions are accurate. Also, if you want to you can basically externalise your own custom PPU, using bitmaps straight from VRAM. If you just render exactly as the PPU does, then you should have no problems whatsoever. (In all seriousness though, for emulators with a layer disable function, why don't you just disable any BG layers, dump the video and overlay it onto an atlas map?). Also it turns out that the GBA also has the OAM in the normal address space:
GBA Specifications wrote:
OBJ Attributes There are 128 entries in OAM for each OBJ0-OBJ127. Each entry consists of 6 bytes (three 16bit Attributes). Attributes for OBJ0 are located at 07000000, for OBJ1 at 07000008, OBJ2 at 07000010, and so on. As you can see, there are blank spaces at 07000006, 0700000E, 07000016, etc. - these 16bit values are used for OBJ Rotation/Scaling (as described in the next chapter) - they are not directly related to the separate OBJs. OBJ Attribute 0 (R/W) Bit Expl. 0-7 Y-Coordinate (0-255) 8 Rotation/Scaling Flag (0=Off, 1=On) When Rotation/Scaling used (Attribute 0, bit 8 set): 9 Double-Size Flag (0=Normal, 1=Double) When Rotation/Scaling not used (Attribute 0, bit 8 cleared): 9 OBJ Disable (0=Normal, 1=Not displayed) 10-11 OBJ Mode (0=Normal, 1=Semi-Transparent, 2=OBJ Window, 3=Prohibited) 12 OBJ Mosaic (0=Off, 1=On) 13 Colors/Palettes (0=16/16, 1=256/1) 14-15 OBJ Shape (0=Square,1=Horizontal,2=Vertical,3=Prohibited) Caution: A very large OBJ (of 128 pixels vertically, ie. a 64 pixels OBJ in a Double Size area) located at Y>128 will be treated as at Y>-128, the OBJ is then displayed parts offscreen at the TOP of the display, it is then NOT displayed at the bottom. OBJ Attribute 1 (R/W) Bit Expl. 0-8 X-Coordinate (0-511) When Rotation/Scaling used (Attribute 0, bit 8 set): 9-13 Rotation/Scaling Parameter Selection (0-31) (Selects one of the 32 Rotation/Scaling Parameters that can be defined in OAM, for details read next chapter.) When Rotation/Scaling not used (Attribute 0, bit 8 cleared): 9-11 Not used 12 Horizontal Flip (0=Normal, 1=Mirrored) 13 Vertical Flip (0=Normal, 1=Mirrored) 14-15 OBJ Size (0..3, depends on OBJ Shape, see Attr 0) Size Square Horizontal Vertical 0 8x8 16x8 8x16 1 16x16 32x8 8x32 2 32x32 32x16 16x32 3 64x64 64x32 32x64 OBJ Attribute 2 (R/W) Bit Expl. 0-9 Character Name (0-1023=Tile Number) 10-11 Priority relative to BG (0-3; 0=Highest) 12-15 Palette Number (0-15) (Not used in 256 color/1 palette mode)
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
Is anyone actually still working on this, or is this a dead project?
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 that's one of the games I've been looking for a long time now too. It's a regular Game Boy game and you play as some sort of demi-humans, if we're looking for the same thing. I had it on a 100 in one cartridge I acquired in Greece and never knew its original name.
Yeah, that sounds more like the game.
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
Avatar: the last airbender
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
Okay, I noticed that at first, the category for this game was "glitched" and it didn't obsolete the old any%. Then someone changed the category to "pipe glitch", and obsoleted the old any%. Then it was changed again to "Memory manipulation" and the older any% was republished. After that, the category changed back to "glitched" and the old movie was obsoleted again. What is going on? Just chose one way and stick with it. By the way, I am going to do a 100% glitched with the new pixel trick because that's what most people seem to want, when I asked on IRC (sorry MUGG).
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 mupen64 plus team, but that's still very far in the future.
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
Hmm this thread reminds me of a game I played once with a friend's gameboy. It was either gameboy or gameboy colour but I think it was just gameboy. My memory about it is pretty vague. It was a vertically orientated non scrolling puzzle game, where you were a guy who had to push blocks over ledges and climb ladders to make platforms ect. It was sort of like lode runner, but it was more about pushing blocks. I don't think there were any enemies. I can't remember exactly the object of the game, but I think it was to get a key to a door, or just get to a door. I also remember that you could rewind your movements by pressing B. I don't think it was an incredibly popular game.
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
Sync stability. I tried TASing this game twice, it desynchs every time you activate (or skip) a cutscene. For some reason it must add an extra frame, or remove one every time a cutscene plays. for this reason, you have to play from the beginning up to every cutscene every time you get to one, and then save from there. As far as long term sync stability is concerned, I'm not really sure either. It doesn't appear to desynch, as long as you don't load a state. I reccomend the latest glide plugin for CBFD.
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 a large number of consoles there is a part of RAM called the OAM, which has all the sprite positions and attributes. It is in the same place for any game, and it is extremely accurate. It shouldn't take more than 1/1000th of a second to find and label all the sprites on screen this way, so instead of identifying sprites visually, which would take a while, use the OAM. Also, there is usually some RAM specifically for the graphics of anything on screen. If you find this, you should be able to draw any sprites onto an atlas map.
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 this pause glitch may be able to make the game completed quicker than the current run. I think we may be able to complete the game earlier with some extremely good luck. How it's done is to make the CPU execute either one of these four instructions, and we'll be able to get to the credits. So far we have been able to get the pause glitch to execute random, misaligned parts of memory: 08 D5 A2 (assuming SP !=0) EA D5 A2 (assuming the register A != 0 ) 02 (assuming BC = D5 A2) 12 (assuming DE = D5 A2) We should be able to do this with a bit of extreme luck. There might be other ways, like changing mario's position to be close to the credits block early, or something along those lines.
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 just wondering how this TAS is going. I hope I didn't ruin it too much by executing a walljump. Baxter has been giving me some previews of some of the later levels (thanks Baxter), up to 2-5, so I was just wondering how this TAS is going. This is my no.1 anticipated TAS at the moment.
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 is actually some weird differences between "all levels" and "all exits". "all levels" means getting at least the A exit in all of the levels, however "all exits" means getting the B exit in some levels as well. There are some differences here, for example, in the hippo/bubble stage, there is a secret exit which returns you to the entrance of that level. Similarly, through the pipe glitch or other out of bounds glitches (like the bat + bubble glitch, or the bee glitch), you can take the B exit in levels where you normally couldn't Normally, the B exit will do absolutely nothing, and return mario to the entrance to that level. Should these be included as exits that needs to be completed? say that they aren't. In tree zone 2 there is a B exit in the level. But if you take the B exit from the bee glitch or the pipe glitch in the bee level, you can access the bonus level as if you took the B exit in tree zone 2, so the B exit in the bee level is redundant to the B exit in tree zone 2. Taking the B exit in the bee level saves a bit of time in the route, so which one should I do? Dillemmas like this don't exist when I say that I have to take at least the A exit in all levels (including secret/bonus ones). This part of the 100% definition was never really under debate, it's significantly easier to make a rock solid definition of 100% if it's "all levels" rather than "all exits"
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
Okay, since the new any%, I think SML2 is due for a 100% run. This means I will complete the A exit of every level. ( I call it the A exit because it is represented by the tile 4A in memory, alternatively, the 4B tile represents a secret exit, therefore, the B exit. Defeating a boss is equivalent to the A exit of a level as well, and getting the B exit on a boss will do absolutely nothing) Should I make a glitched 100%, or a non glitched 100%? If I make a non glitched 100% run, then there should be a third category which showcases relevant SML2 glitches, like the bell glitch, the pipe glitch, ect. Then what should this category be, and what restrictions should apply? What constitutes a glitch, or what glitched should be disallowed? If I make a glitched run, should I do the new pixel trick? The new pixel trick involves repeatedly hopping, and if done right, saves one pixel per hop. Should I consider this a speed/entertainment tradeoff, or should I just go with it? Keep in mind tht a 100% run will be at least 25 minutes. Any feedback would be appreciated.
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
(10:45:02) FerretWarlord: The schools of my childhood used Macs. (10:45:09) FerretWarlord: They crashed every 5 minutes. (10:45:42) FerretWarlord: I was also baffled by how you'd eject a floppy and it would say, "Hey, put that back!" (10:45:54) adelikat: that's what she said EDIT: found this one on my HD somewhere: (09:27:09) Brushy: The eve is the traditional day of Christmas celebration here in Finland. (09:27:16) Brushy: All the presents and food and stuff today. (09:30:04) andymac: seriously? (09:30:12) andymac: what's christmas for then? (09:30:23) AnotherGamer: Sitting on your ass (09:30:35) andymac: or should I say, What's boxing day for? (09:30:40) AnotherGamer: Sitting on your ass (09:30:51) andymac: agreed.
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 doubt you'll find many physics exploits. SM64 was horribly coded (the prevention of lage backwards long jumping speeds was already hacky code, they had to introduce artificial restrictions to prevent backwards speed increasing past a certain point, and other restrictions for preventing excessive forwards momentum as well. I think nintendo already knew how badly they implemented the long jump, it was just a matter of time before someone figured out HOW badly), whereas rare took a lot more care when making their games. In my experience, rare used hard limits for maximum speed (if speed is above x, make it x) unlike SM64 which imposed soft limits, (decrese speed by x if speed is above y), or asimptotical limits. Hard limits would prevent excessive speed like in SM64 straight away. However, I would look at glitches in Donkey Kong 64, because they might manifest themselves in the BK engine. (Maybe because they're both made by rare, they may have similar physics or collision code.) In my opinion, unless you find some insane level skipping glitches, the any% and 100% are too similar to warrant separate publications. 96 jiggies? Why not go the full 100? plus there is an already published 100%, so I vote for a 100%.
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
You seem to have forgotten that there are certain conditions required in order for two objects to recede faster than the speed of light. You just say that two objects ARE receding faster than the speed of light, and then forget to mention how, and exactly what occurs during this time. I think you are making the false assumption that you are in this scenario: you are at a referance point D, which isn't accelerating. You see point B travelling at 0.75c to the left and you see point A travelling at 0.75c to the right. Of course they will be able to communicate with each other, B sends a laser to point A at D, it will eventually reach A because A is only traveling 0.75c. From B's perspective, A is travelling slower than c, because of time dilation. However, in reality, D is accelerating, so different things occur. For example, the displacement between two objects can't increase faster than the speed of light forever for example (even if you are accelerating at 10^-50ms-2 and the object is a googolplex km away and travelling at 0.99999999999c directly away). Take these sorts of things into account, and you will find that there are no contradictions. I haven't really explained anything, because I can't visualise such a situation accurately, however, I know the these apparent contradictions come from the fact that you are no longer in an inertial reference frame. Also, I admit, my previous post was wrong in so many differnt ways. Probably so is this one, but I'll give it a try.
Measure once. Cut twice.