I find it sad that all the bosses are spared. Especially, Mother Brain since shes the heart of this operation.
Well, except for the part where samus blows up the whole planet. Why she usually bothers with the bosses before laying that cute little armageddon device is beyond me.
again, I'm in favor of obsoleting the low% run for now. If a more up-to-date successor appears, we can still reinstate a non-glitched low% category.
now where did this come from?
pleasant surprise, I'll hit the yes button after watching :)
edit: bonus points for excellent energy management, avoiding the speed booster (and thus the pause trick), finally letting the metroid know what hit 'em and wrecking every room on tourian even before the bomb went off.
But I have to deduct a couple of points for slightly missing the announced 100% goal. :p
still, yes vote. A worthy successor to the old low%.
sorry, somehow missed the speedbooster part (and surely others), I only watched it on my second monitor while getting some work done. I'll watch it again when I have more time though.
syncs fine with Impossible 1.5.
Nice health and ammo management, I liked the close call at ridley's doorstep. I also liked the cute little tricks you used that find no use in regular SM.
Why didn't you get space jump early though? Turned out to be slower?
We've had full games on a quad-run. Then we had one level on six games.
Next, someone will make a movie that'll simultaneously play 60 games until right after the title screen?
for the record, I voted no. Same reasons as stated on the quad-run and a few more that were already mentioned.
my surname is pretty rare, there are only a dozen families with that name. googling my full name only yields about 6 pages about me: university pages, old amiga software I wrote during my teenage years and uploaded to aminet, some mailing lists I've posted on, Realbot for Counter-Strike I've worked on during the pre-source-times, qdq and a couple of changelog or bugzilla entries of different open source projects.
nothing to be too proud of, not even a doppelgänger.
about the genesis / M68000: the CPU is something between 16 and 32 bit. The CPU registers are full 32 bit, and there are many ASM instructions working on full 32 bit words (MOVE.l, ADD.l etc), while others (like multiplication) only worked on 16 bit. Still, it's word size is 32 bit.
The M68020 added the missing instructions for 32 bit words as well as a 32 bit data bus.
P.JBoy wrote:
I don't really see why you should need more than 32-bit, especially with DMA and all.
First of all, in today's games with huge worlds, you'll need native data types with high ranges at reasonable precision. 32-bit-types just don't cut it.
Second, how is DMA supposed to help with small word size? Are you confusing word size with address length?
edit: damn, too slow ;)
rough translation. Basically, what he wants is to create a codec that understands sprites and sprite-movements to allow small movie files without quality loss.
I've been watching every published TAS for some time. I've begun to hate the codec used in TASes. The image quality of the old games isn't the best, but even those simple pictures are distorted by agressive compression.
I've thought about simple ways to evade those compression problems. Unfortunately I lack the knowledge to convert those ideas to programs; that's why I address you. To hear an opinion, to get some tips. If I get positive replys, I'll send the idea to the xvid team.
The problem is, that the codec I thought about would only work in 2D games.
The method is similar to the movie function of halflife and halflife 2, only that my method doesn't require additional programs of files for playing movies.
The idea:
2D games consists of sprites that repeat themselves. That fact makes it possible to rasterize the game (or rather the image). After repeated objects are detected, only positional information is saved. The object is saved only once in the video file. [Tub: I couldn't grasp the sense of the following sentences, hence no translation. Looks like some incoherent thoughts about implementation details.]
Procedure:
The emulator creates a RAW video. In periodic intervals, a picture will be extracted and analysed. It creates a raster and attempts to find dublicate or mirrored objects, and saves them as a lossless picture. [Tub: some more details omitted]
If there is support from the developers of the emulators, emulation internals could be used as an information source for sprite movements. It's also possible to dump the objects directly to save the image matching process. Since most older consoles use palettized images, that format should be supported to save more space.
I hope for positive replies and critics. I'll try to add pictures in the next few days to make it easier to understand
My reply:
we already have a format that can save exact sprite positions and is very, very small: the emulator movies. They don't even save sprite images, they just record keypresses, thus they're usually the smallest movie files possible.
You'll need to install the emulator, obtain the rom (we cannot distribute roms for copyright reasons) and download a very small movie file (usually a couple of kB). You'll get lossless picture quality.
What you're suggesting would be a more generalized approach for such simple movies. First of all, it's nowhere in any mpeg standard, thus it's quite improbable that the XviD-guys would use it. You'd have to create your own, seperate codec.
And that's where the trouble starts: your codec will be a specialized solution that isn't wide-spread and has to be installed by the audience. But, if they're willing to install something, they can just install the emulators.
So after all, it'd be a lot of work for little gain. Emulator movies are much better, for those who know how to use them. For everyone else, we provide AVIs - easy to watch, but at the cost of filesize and quality loss.
We're just playing around with their engine, we're not actually creating anything ourselves.
I disagree. Would you also say that Beethoven never created anything, as he was just playing around with notes?
Any kind of creation, artistically or otherwise, is based on previous works. Even just combining previous works in a clever way can be a noteworthy achievement. That's what enables a society to evolve.
so how should the server verify that the input the client sends has really been entered in real-time? You could just modify the emulator to send the button-presses of a pre-made TAS instead of your real-time input. Heck, you could even use something like AutoIt to fake the button presses and use an unmodified emulator..
With even more work you could make the server send some kind of random seed, so a pre-made tas would desync. But you'd have to figure out the RNG of each game to do that: lots of work.
Still, cheats like memory-watch, auto-fire or even complicated macros or lua-scripts cannot be prevented just by sending the input stream to a server.
how many are you planning to buy? If you wish to buy lots, keep away from standard configurations.
You could save money as well as ~10 Watts on the hard disks and CD-Roms if you get one USB CDRom for all the computers, then boot them from CD. It's cheaper to buy a gig of RAM and keep the OS in memory than to buy a hard disk. Less noisy, too.
Of course that'll only work if you know how to create a bootable linux CD that'll copy itself to a tmpfs before remounting the root fs.
When it comes to cases, the cheapest way would be a freaky home-made rack mount, if you know how to do that.
Another thing to consider: cheap isn't always good. You'll want to calculate price per processing power. A dual-core Athlon64 X2 may add ~20 Watt and 10 bucks to a machine, but may double the processing power. You'll need to hunt down some CPU benchmarks (tomshardware.com?) and compare prices.
That's not a SuperMetroid hack and it won't run on a SNES-Emulator. The graphics in that video are way too demanding for a SNES.
They did reuse some sprites from SM, but that's about it.
It'll probably turn out to be a windows exe. (either that or a hoax :p)
although the "fastest time" possible is rarely reached, there's a difference in the wording: "100% kills" uses an absolute value instead of a general goal. Saying this "aims for 100% kills" is as misleading as saying "aims for sub-5-minutes" on a 6-minute run.
This movie aims for most kills, not 100%.
(then again, I'm aware of the technical limitations of categories)
that looks cool :)
is there some reason not to get X-Ray early on your way from Speed Booster to Wrecked Ship? Can't afford the energy/power bombs at that point?
edit: ah well, if it's slower, too bad. Still looks cool!
