hello,
at first: this is no mention about the person who encode TAS. It is a mention about the codec(s) himself.
second: my english doesn't reach for this kind of complex text, so please don't be angry about my dumpishness.
Ich sehe seit langen mir regelmäßig (jede) TAS an, die veröffentlicht wird. Dabei beginne ich aber mehr und mehr den Codec, der in den TAS verwendet wird, zu hassen. Die Bild-Qualität der damaligen Spiele ist nicht die beste, doch selbst diese Einfachheit wird mit einer brachialen Komprimierung auf ein "unschönes" Ergebnis getrimmt.
Ich habe mir (nach meinen Aggressionen) immer wieder Gedanken gemacht, wie man auf einfache Art und Weise diesem Kompressionproblem entgeht. Leider habe ich nicht erforderlichen Kenntnisse, um meine Ideen in Programme um zusetzten, deswegen wende ich mich direkt an Euch. Um eine Meinung einzuholen, oder den einen oder anderen Tipp zu erhalten. Bei positiver Resonanz, werde ich die Idee an das Team von Xvid schicken.
Einzigster Haken, das von mir erdachte Coding würde nur in 2D Spielen funktionieren.
Am ehesten ähnelt dieses verfahren der Moviefunktion von Halflife und Halflife 2. Nur das in meinen Fall keine zusätzlichen Programme oder Dateien benötigt werden, zumindest nicht für das Abspielen.
Hier meine eigene Idee:
Spiele im 2D Bereich bestehen aus Sprites die sich mehr oder weniger wiederholen, diese Tatsache macht es möglich das Spiel (oder viel mehr das Bild) zu rastern. Nach dem Objekte, als ein Objekt mit häufiger Anzahl erkannt wurden, werden nur noch Positioninformationen nachgeladen. Das Objekt ist also nur noch einmal in der Videodatei gespeichert, dafür aber die Positionen. Meiner Rechnung nach, sind Positionen kleiner, als Bildinformationen. Da sich die Objekte gegenseitig überlagern um einen 3D Effekt zu erzeugen, muss auch eine 3D Umgebung erzeugt werden. Oder man gibt den Bildern eine weitere Information ,welche die Ebenennummer angibt. Da sich aber die Ebenennummern ändern können, bin ich mir über den eigentlich erhofften Komprimierungsgewinn nicht sicher.
Ablauf:
Der Emulator erzeugt ein Video im RAW Format(sollte es die Möglichkeit geben, kann es auch Life gemacht werden).
In regelmäßigen Abständen wird ein Bild herausgenommen und analysiert. Dabei wird ein Raster erzeugt und versucht, wiederkehrende oder spiegelnde Objekte zu finden und als Bild ohne Verlust zwischen gespeichert. Das Raster kann Manuell, oder auch automatisiert erzeugt werden. Objekte die permanent und hauptsächlich im Film zusehen sind, werden als perma Objekte behandelt und nur ausgeblendet wenn es angeben wird. Damit ist zum Beispiel die HP Anzeige des Helden gemeint. Beispiel:
Die Anzeige unten im Bild hat im Verlauf des Spieles keine bis wenig Veränderungen,
eine logische Aufgliederung der einzelnen Objekte als einzelne Bilder, würde einen Speicher- und Optischenvorteil aufweisen können.
Sollte es Unterstützung von den Entwicklern der Emulatoren geben, so könnte eine Informationsquelle erzeugt werden, die die Positionsänderungen der einzelnen Objekte ausgibt . Vielmehr wäre es auch möglich die Objekte direkt herausladen zu lassen um, das Rastern zu sparen. Da die meisten Konsolen bedingt durch ihr alter auf Farbpaletten Objekte färben, wäre es nur zu praktisch eine solche Funktion einzubetten um wiederum Speicherplatz zu sparen.
Dabei könnten Objekte direkt vom abspielenden PC eingefärbt werden und das Resultat wäre dem Original gleich.
Ich hoffe aus positive Resonanz und Kritik. Damit das ganze auch besser zu verstehen ist, werden die nächsten Tage weitere Bilder mit veröffentlicht.
See you soon.
-Blackerking
OKay here an english translation:
I see me regularly since long (each) TAS, which is published. Here I start but more and more the codec, in the TAS used to hate. The image quality of those games is not the best, but even this simplicity is get trimmed by high compression and the results are bad.
I have (after my aggression) always thought how easily this way escapes compression problem. Unfortunately I do not have the necessary skills to take my ideas into programs or codecs, so I turn to you directly. I want to hear your opinion and maybe some feedbacks. In a positive response, I will present this idea to the team of Xvid.
Only One thing is important: the imaginary Coding will only work in 2D games.
This procedure is similar to the movie function of Half Life and Half Life 2nd Only in my case, no additional programs or files are required, at least not for playing.
My own idea:
The most 2D games consist of sprites which are more or less repeated. This fact makes it possible to grid the game (or much more the image). After these objects are rasterized they can just repeatet(in the movie), but the positioninformation of these object is smaller than the hole image. The object is only once in the video file, but the positions count really. Some Objects do hide other objects, this fact can be a result of an 3D enviroment or objects gets levelnumbers which can change in film. I am not sure which solution is the bettest space saver.
procedure:
The emulator produced a video in RAW format (If it is possible, it can also be made in realtime).
At regular intervals, a picture is taken and analyzed. It creates a grid and tried to recurring or reflective objects to find and as a picture without loss between. The grid can manually, or automatically be generated. Objects permanent and mainly in the film to watch are known as perma objects and only indicate when it disappears. Thus, for example, the HP display of the hero meant. Example:
The ad at the bottom of the image has in the course of the game little to no change,
a logical breakdown of individual objects as individual pictures, would be a storage and optical advantage which may.
Should there be support from the developers of the emulators, they could be a source of information generated, the position changes of individual objects spends. Maybe the emulators can take the emulated sprites and save as singlesite, so the grid-procedure is not longer needed. Since most of their consoles due to old objects colour palettes, it would be just such a practical perspective to function again to save space.
I hope for positive feedback and criticism. To make the whole even better to understand, the next few days i will add some more pictures.
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.
I know(and use) this possibility. But also i think these website stands for entertaining.
And these bad coded movie (e.g. Super Metroid for SNES) have not quality enough to stands for entertaining.
Joined: 11/22/2004
Posts: 1468
Location: Rotterdam, The Netherlands
What you yourself could also do is provide lossless x264 encodes to those who want the extra quality. It's quite nice, and the only thing that separates it from "true" lossless video is the colorspace (but this is entirely a non-issue) and the chroma subsampling.
When I heard they were going to take part in Google Summer of Code, I suggested to them that they should use this opportunity to implement 4:4:4 and 4:2:2 support. If you're interested, go have a look.
