|  Evo Lution | | Title: | Evo Lution | | Category: | Demo/Wild | | Release Date: | 2014-07-19 | | Language: | English | | Machine: | PAL Only | | Code Type: | Machine code | | Distribution: | Unreleased | | Code by: | BSZ | | Designed by: | Stinky | | Credited (Code by): | bubis | | Credited (Code by): | TLC | | Notes: | AKA Evolution. Presented on the Wild compo at Arok 2014, requires special hardware. |
External links:
YouTube Video
YouTube Video (Live)
User Rating: 9.9/10 (16 votes)
| 
 |
|
| |
| | Evo Lution - The various wares of a Plus/4 Wild Demo (by BSZ) | Maga a Wild demó, mint ötlet nem új, sok egyéb platformon (C64, Spectrum, stb...) láthattunk már hasonlót. A "kedvenc típusra" viszont senki sem készített még ilyet (legalábbis nem tudok róla). A "téma" is a szokásos; vegyünk egy (8 bites szinten legalábbis) nagyobb háttértárat, és némi hardveres segítséggel töltsünk róla animációt. Egy ilyet - csak úgy, szórakozásból - már igen régen szerettem volna készíteni, a parti most adott egy kis lökést.
A hardver "alapötlete" amúgy nem a demó megvalósíthatósága, de ez is egy régebbi terv; a "nagyobb" háttértár illesztése lenne az alapja, egyéb platformokon ez is már régebben megoldott valamilyen szinten. (Csak "mi" vagyunk így elmaradva?) Ismereteim szerint direkt plus/4-hez ilyen sem készült még, ez is hiánypótló termék lenne. :) A soros buszhoz kapcsolható háttértárak ugyan rendelkezésre állnak, de ezek tulajdonképpen "multiplatform" megoldások, és egyiküknek sem az elsődleges "célgépe" a plus/4. A saját verziót TCBM buszos illesztésűnek képzeltem el (ez az, amit az 1551 használ), ami - természetesen - magával vonzza magának az interfésznek az elkészítését is.
A két történet nagyjából itt ér össze, annak ellenére, hogy egy "Evo Lution" típusú animáció lejátszáshoz az alap TCBM busz a szoftverrel megvalósított adatátviteli protokoll miatt "igencsak lassú". Viszont mivel a TCBM interfész a gép EXPANSION portjára csatlakozik, a leendő eszközömnek is oda kell kapcsolódnia. De! Ha már a gép rendszerbuszához készül bővítés, akkor van pár olyan ötlet, amit kár lenne kihagyni a készülő hardverből. (Hogy ezen a hardveren - ha elkészül egyáltalán - mi is lesz megtalálható, arról egyelőre nem nyilatkoznék, nagyon sok ötletem van, viszont kérdéses hogy majd "mi fér bele" a lehetőségekbe.) A koncepciót már másfél éve nekiálltam összerakni, még az előző ÁROK™ partira szerettem volna valami minimálisan működő hardvert összeállítani. Az elképzelés akkor is a Wild demó ötlet volt, de a hardvert úgy kezdtem el megépíteni, hogy a végeredmény minél nagyobb részét fel tudjam majd használni a bővítés készítésénél. Ez akkor néhány technikai probléma illetve időhiány miatt nem valósult meg, de az ötlet nem lett elfelejtve.
A készülő hardver prototípusa egyelőre a fiókban végezte, de jött a következő parti, amire nem akartunk "üres kézzel" menni, ezért a Wild ötletet előkaptam ismét. Idő már nem volt túl sok, így az lett a terv, hogy az eredeti hardver koncepciót teljesen lecsupaszítom, kizárólag a demóhoz szükséges képességeket rakom össze, most úgyis az a lényeg. Ráadásul "találtam" egy régebbi céges fejlesztést, ami a szükséges hardver szinte összes elemét tartalmazta, így minimális hardveres tervezést vett csak igénybe a dolog, a munka nagy része néhány firmware elkészítése volt. Ennek tudható be, hogy a háttértár szerepét egy CompactFlash™ kártya tölti jelenleg be, az eredeti tervekben a manapság már jóval elterjedtebb SD-Card™ volt / lesz a tároló. Illetve emiatt nem készült rengeteg fénykép az elkészítés menetéről sem, mert nem volt túl sok mozzanata az összeállításnak. A végeredményről azért készült pár fotó:
Maga a "szendvics" összeépítve:
Mindez hátulról, itt látszik a gép bővítő buszához kapcsolódó "csatlakozó" (8bitbaby, köszönet érte TLC-nek!), a SID kártya prototípushoz is ezt használtam:
Az illesztést egy meglehetősen egyszerű hardver végzi, a forrasztgatni való ennyiben ki is merült:
Mivel a "kedvenc gépünk" idén 30 éves, a jubileumra bekerült két eredeti Commodore alkatrész. :)
A "drótozás" egy kicsit ijesztőnek néz ki, de valójában nem vészes:
Az egész csatlakoztatva a géphez:
Azért elég nagy méretű lett a végeredmény, de a prototípusok már csak ilyenek. :)
A végére egy "tájkép":
Na de mi is lett itt összerakva? A "specifikáció" annyi volt, hogy egyrészt a plus/4 gyári hangja elég vérszegény, így ahelyett mindenképpen kell valami, másrészt a leendő videó képeinél az elérhető legjobb minőség volt megcélozva. A hang az egyszerűség kedvéért legyen mono, 44100 Hz-es 8 bites "sima" PCM, ebből a végén 12 bites felbontás lett, mivel a "talált" hardveren ilyen felbontású D/A van. A videó képkockái MCDFLI képek legyenek, ezek egyenként 16 KBYTE körüli adatmennyiséget jelentenek. A hang sávszélességigénye 88200 BYTE másodpercenként, a videóé viszont jóval több: 50 FPS esetén 800 KBYTE/másodperc. (Ez azért a valóságban "viccesen sok" az alap plus/4 számára. A hang 16 bitesként van eltárolva, de így is a komplett sávszélesség igény ~10%-át teszi csak ki, itt már nem volt jelentősége ezen spórolni.)
A bővítés oldaláról szükség van egy háttértárra, erről fogok töltögetni. Aztán kell egy megfelelő sebességű µC, ennek lesz a feladata a háttértár olvasása, illetve a hozzá kapcsolt D/A adatokkal való kiszolgálása. A nagy mennyiségű adatot viszont a plus/4 TED-jével kell "megetetni", itt viszont két probléma is adódik. Az egyik, hogy a gyári alapgépen nincs lehetőség külső DMA-ra, aminek a használatával a plus/4 RAM-jába lehetne az adatokat tölteni. (Ilyen sebességnél szóba sem jöhet a gép eredeti processzora, de amúgy is el lesz foglalva a megjelenítéssel.) A másik probléma, hogy hiába is lenne DMA, valószínűleg akkor sem lenne elegendő idő az adatok mozgatására, ha a gép CPU-ja végig le lenne állítva. (A gép belső memóriabusza 1.77 MBYTE/másodperc sávszélességű, de a TED-nek ebből igen nagy részre szüksége lesz! Én meg 0.8 MBYTE/másodperccel szeretném töltögetni...) Emiatt más megoldást kell keresni. A "más megoldás" alapja az, hogy a TED úgy van felépítve, hogy a grafikához szükséges adatokat nem csak a RAM-ból, hanem a ROM-ból is fel tudja olvasni. Ezért a bővítésnek tartalmaznia kell egy - megfelelő, ez esetben 512 KBYTE méretű - RAM memóriát is, amit a gép számára mint ROM be lehet lapozni, és ez működik az alapkiépítésű géppel is. De ha már külső RAM, azt egy "jó gyors" busszal célszerű kiszolgálni, amikor a plus/4 kér egy ciklust, akkor - mintegy mellékesen - megtörténhet az adatátvitel, az idő többi részét viszont a µC / háttértár megkaphatja. Tehát van három eszköz (háttértár, µC, RAM), kell egy negyedik, ami a gép és ezen alkatrészhármas közti kapcsolatot megvalósítja, ez egy programozható logika a célszerűség kedvéért.
A plus/4 oldaláról mindez úgy néz ki, hogy a bővítés RAM-ja az egyik ROM BANK helyén látszik, két 16 KBYTE-os szeletben. Ez a külső memória most 512 KBYTE, emiatt van két (5 bites) regiszter, amivel kiválasztható, hogy az alsó illetve felső 16 KBYTE-os ROM lapon melyik 16 K-s RAM szelet látsszon. (5 bit = 32 variáció, 32 × 16K = 512K.) Mivel a gépnek szüksége lesz az adatmozgatást menedzselő mikrovezérlővel is kommunikálni, ezt célszerűen a RAM-on keresztül lehet elvégezni. A bővítés úgy lett megcsinálva, hogy a belapozott 16 K-s RAM szelet megfelelő címére történő írás esetén nem csak a ROM alatt levő RAM-ba (a gép belső RAM-jába) történik meg az adatbeírás (mint alapesetben), hanem bekerül a kiírt adat a külső RAM megfelelő címére is. (Ezt így végiggondolva, használható a megoldás rendes RAM bővítésként is, annyi a megkötés, hogy csak a memória felső 32 KBYTE-ját lehet erre használni, mivel csak ott lehet ROM gyárilag.)
A videó lejátszás úgy lett felépítve, hogy - igazodva a 16 K-s lapmérethez - egy-egy kép 16 KBYTE helyet foglalhat el mindenestől. A plus/4 beállítja a kívánt 16 KBYTE-os lapot a ROM alsó szeletére, kideríti hogy milyen módon kell megjeleníteni, beállítja a megfelelő módot, megjeleníti a képet. Ezután megnézi, hogy az imént megjelenített képet hányszor kell megmutatni. Ha ez volt az utolsó alkalom, a következő képhez kiválasztja a következő 16 K-s lapot, majd jelzi a µC felé, hogy az előző lap már nem kell, oda tölthető a következő frame. Ezután a folyamat kezdődik elölről. A µC oldaláról eközben egyrészt zajlik a hang lejátszása, másrészt figyeli a megjelenítendő lapok állapotát. Ha "kiürül" egy lap, oda betölti a videó következő képkockáját.
Mivel minden frame "módjelző adata" tartalmazza azt, hogy milyen típusú az adott képkocka, így a videóban képkockáról képkockára tetszőleges módon keverhetők a grafikus üzemmódok, az "Evo Lution" tartalmaz HIRES, MULTICOLOR illetve MCDFLI típusú képeket is. (De bármilyen lehetne tulajdonképpen, az egyetlen megkötés, hogy 16 K-ba minden adatnak bele kell most férni.) A "módjelző" tartalmazza azt a számot is, hogy az adott képkocka hányszor kell hogy megjelenjen, így a videóban nincs megkötve a "frame-rate", a demó tartalmaz 50 illetve 25 FPS-es részeket is vegyesen.
Ez eddig pusztán "technikai specifikáció", de az egész semmit sem ér beltartalom nélkül. Ebben a szerepem annyi, hogy a témát én kértem; mivel Wild demó készül, legyen a téma is Wild. | The idea of a wild demo in itself is nothing new, we've seem them on many other platforms (C64, Spectrum, etc). However, no-one has created one on our favourite machine (at least not that I know of). The "theme" is the usual; take a large (at least in 8-bit terms) hard disk, and with some hardware help let's load up some animation. I wanted to do something like this for a while - just for fun - and now the party gave me a little bit of a boost.
Basic idea for the hardware is not the feasibility of the demo, but rather an older plan; to connect "larger" background storage, which is something that has been solved (more or less) on other platforms. (Are "we" the only ones so behind?) To my knowledge, nothing of the kind has been made for the Plus/4, so this is a niche product. :) Even though serial bus drives are available, those are actually "multi-platform" solutions, and none of them is targeting the Plus/4 directly. I imagined my own solution to be using a TCBM port (this is what the 1551 uses as well), which - of course - dictates the interface itself as well.
This is where the two stories meet, despite the fact "Evo lution" type software-based animations would be very slow because of the TCBM data bus protocol. However, since the TCBM interface connects to the EXPANSION port of the machine, my device would have to be connected there as well. But! As long as I'm preparing to bus expansion, I had a few ideas that would have been a pity to miss from forthcoming hardware. (At this time I'd rather not make any declarations about what would be on this piece of hardware - if gets completed at all, there are a lot of ideas, but question will be what is actually possible to implement.) I started to put the concept together about a year and a half ago, I wanted to have something with minimally functional to be ready for the previous Arok party. The idea was the Wild demo even back then, but I wanted to build the hardware so that it would share a lot of the functionality with the future expansion hardware. So back then due to some technical problems and lack of time this was not implemented, but the idea has not been forgotten.
The hardware prototype ended up in a drawer for the time being, but the next party came and we did not want to go "empty-handed", so I picked up the wild idea once again. Since there wasn't much time left, the plan became to completely strip the original hardware concept, and only leave the abilities that are necessary for the demo, since that's all that matters anyway. In addition, I "found" an older business development, which included almost all of the necessary hardware components, such as minimal hardware design, so the main part of the work was creating some firmware. This is why it's currently using a CompactFlash™ card for storage, in the original designs this was the more common SD-Card™. This is also why there hasn't been too many progress photos taken, since there weren't too many steps in the assembly. Here are some photos of the final result:
The "sandwich" itself put together:
From the back, here you can see the connector going into the expansion port (8bitbaby, thanks to TLC!), I used this for the SID card prototype as well:
The connection is done with a very simple piece of hardware, so that's all there is to solder:
Since our "favourite computer" is 30 years this year, we included two original Commodore components for this occasion :)
The wiring looks a little scary, but in reality it's no big deal:
The whole thing connected to the machine:
The final thing ended up being very large, but that's how prototypes are. :)
Finally a "landscape" photo:
So what has been assembled here? The "specifications" were: one, the Plus/4's built-in sound is poor, so instead of that we will definitely need something else, and two, for the video let's shoot for the best possible picture quality. For simplicity's sake, let the sound be mono, 44100 Hz 8 bit "plain" PCM, eventually this became 12 bits, because the hardware we found had D/A with this resolution. The frames of the video should be MCDFLI pictures, each of these take 16 Kbytes of data. The audio's bandwidth is 88200 bytes per second, the video's is much higher: in the case of 50 FPS it's 800 KBYTE/second. (In reality this is hilariously huge for a stock Plus/4. The sound is stored on 16 bits, but since it only takes about 10% of the bandwidth, there was no point to try to save more.)
From the expansion's side, we need background storage, where I'll be loading from. Then we'll need a suitably fast μC, whose job will be to read from the storage and pass the data to the attached D/A. The large amount of data has to be "fed" to the Plus/4's TED, and there are two problems that arise. One is that there's no way of doing external DMA on a stock machine, with which the data could be loaded into the Plus/4' RAM. (At such a speed the original processor is out of the question, but it will be busy with the display anyway.) Another problem is that even if there was DMA, there probably would not be enough time to move the data if the machine's CPU were off. (The machine's internal memory bus has 1.77 Mbytes/sec bandwidth, but the TED will need most of this! I wanted to load at 0.8 Mbytes/sec...) Therefore I had to find another solutions. This other solution is based on the fact that the TED is structured so that the data necessary for graphics can not only come from RAM, but also from the ROM. It is therefore necessary to include an expansion - appropriate size, in this case 512KB - RAM memory, which can be paged in to the machine as ROM. But if you have external RAM, it should be serviced by a "fast" bus when the Plus/4 asks for a cycle, then - almost as an afterthought - the transfer can happen, the rest of the time, however, can be given to the μC / storage. So we have three devices (storage, μC, RAM), and we need a fourth, which implements the connection between this machine and the three components, this is a programmable logic for the sake of expediency.
From the Plus/4's side it looks that there's an expansion's RAM shows at one of the ROM banks, in two 16-kbyte slices. This external memory is now 512KB, so there are two (5-bit) registers, which can select from the lower and upper 16 kbyte RAM ROM sheet with 16 Ks viewed as slices. (5 bits = 32 variations, 32*16K = 512K). Since the machine will need to communicate with the micro-controller which is managing the data movement, this can be done conveniently via the RAM as well. The expansion has been done in a way that when you write to the address of of paged-in 16 Ks RAM slice, it is not only written into the RAM under the ROM (the RAM within the machine) - as it would happen by default -, but the data is also written to the appropriate address on the external RAM. (Thinking this over, the solution can be used as a normal RAM extension, with the restriction that only the upper 32 Kbytes of memory can be used, since ROM can only appear there.)
Video playback has been designed so that - given the 16K page size - each image can occupy 16Kbyte space altogether. The Plus/4 sets the desired 16Kbyte page at the bottom slice of the ROM, then finds out how to display the image and displays it. Then it checks how often this frame should be displayed. If this was the last time, it selects the next image in the next 16 Ks space, and then indicates to the μC that the previous page is no longer needed, it can be used for the next frame. Then the process starts all over again. From the μC side, on one hand the sound playback is going, on the other hand it monitors the status of the pages. If one "empties up", then it will load the next video frame there.
Each frame's "mode indicator data" contains the type of the given frame, so within the video any frame can use any of the graphics modes. "Evo Lutoin" contains HIRES, MULTICOLOR and MCDFLI types of images. (But any type would work actually, the only requirement is that all data has to fit into 16K.) The "mode indicator" contains a number, which determines the number of times a given frame should be displayed, so the video's frame rate is not fixed, the demo contains 50 and 25 FPS parts intermixed.
This so far has merely been a "technical specification", but the whole thing is worth nothing without content. In that department my only role was asking for a theme; since this is a Wild entry, let the theme be The Wild as well. |
|
| |
| | Evo Lution - The contents of a Plus/4 Wild demo (by Stinky) | Eloszor is leszek olyan wild, hogy az ekezeteket mellozom, sry.
Szoval a wild ugye vadat jelent, ezert BSZ "rameroltette", hogy legyen termeszetfilm beutese a dolognak. Hosszas analis erolkodes utan (hogy nehogy felreertsd: szartam ra) szedtem a tecsorol (youtube) egy egeszen vallalhato rovidfilmet. Ebbol kellett (volna) frameket kiszedni. Elso korben VLC-vel probalkoztam, de az eredmeny finoman szolva is szanalmas lett, szoval jott a virtualdub. Csak, hogy ne legyen olyan szep az elet a virtualdub nem ette meg a tecsos formatumot, ugyhogy atkonvertaltam emesztheto allapotura. Remek, jottek a framek szepen, 12k+, totalcommander hosszasan gondolkodott mikor a dirbe leptem. Eljen a pc evo lution :O
Irtam egy rovid python scriptet ami felparameterezve meghivta Bubis JAVAs picture konverteret. Mindekozben BSZ nekiallt a prg file kiherelesenek, azaz a prg-bol a szukseges adatokat kiszedo programot hegeszteni. Sietnie nem kellett, mert Bubis konvertere sem tette, elozetes szamitasaim szerint ropke 3 nap alatt vegezni is fog a 12k frammel. For further reference: az eredeti elkepzeles MCDIFLI lett volna, igy a kepek igy keszultek.
Ekeszultek a kepek, elkuldtem BSZ-nek, csinalt belole probaverziot, ami olyan szornyu lett, hogy nincsenek ra szavak. Docogott, zajos volt, minden volt csak szep nem. Ezzel, hogy a klasszikus szoviccel eljek, max a banyaban arathattunk volna, lezavarjuk es feljon a szen. Volt 1-2 jelenet ami meg igy is elfogadhato volt, de mondtam BSZ-nek, hogy probalkozas cimen nem vagyok hajalando ujabb 3 napig jaratni non-stop a gepem, szoval nekialltam egy sajat konverternek, ami mar az uj koncepcio szeint "szimpla" interlace nelkul MCDFLI-t csinalt (volna). Ezt olyan szintre sikerult megcsinalni, hogy sacc/kb latszott, hogy mi lesz majd a videoban, befejezve nem lett a vegso kepek ujfent a Bubis konverterevel keszultek. Szerencsere az MCDFLI kepekkel nem kuzdott annyit (persze igy sem sietett). Kerestem meg par termeszetfilmet, majd kivalogattam beloluk par jol kinezo scenet -> virtualdub, photoshop, Bubis konverter.
Zenere ket otlet volt, az egyik a demoban hallhato solyomszem (Hawkeye), amire egeszen veletlenul bukkantam a remix oldalon, a masikat nem arulnam el, hatha lesz folytatas :P BSZ volt olyan kedves es visszadigizte a klasszikusan csak csitt-csatt konverternek hivott freq. hangjat, majd a digikonverter hangjat, majd a SID hangjat. A freq. + digikonverter + SID es MP3 osszefuzese nem volt nagy kaland, kb. 3 perc alatt megismerkedtem az Audacityvel (jo bonyolult egy program) es a 3. probalkozasra sikerult egy hallgathato (feherfuluek elhuzhatnak melegebbre) verziot osszerakni.
Orulunk Vincent, van video es van hang, node megsem vaghatjuk az userek arcaba, hogy nesze vazze video. Foleg, hogy ugye valamifele grafikus es zenei evoluciot kene bemutatni, szoval jott a brainstorming, nehany villamcsapas utan pedig osszeallt, hogy mit is ir a hogyishivjak. Elmagyaraztam a felesegemnek, hogy mit szeretnenk az elejere, majd nekiallt Cinema4D-vel animot hegeszteni. Jo felnapos kinlodas utan osszejott az anim, amin (anim amin haha, szojatek vazze!) annyira latszott, hogy a Cinama4D nem erre lett kitalalva, hogy gyorsan lekukaztam (felesegem azota sem heverte ki a megrazkodtatast). BSZ-el rogtonzott skype beszelgetes kereteben on the fly osszedobtam Unity3D-ben a bevezeto animot (ja, lekodoltam: frame mentes kodbol es egyeb nyalanksagok, jo moka volt es mindezt azert, mert scala szintu program azota sincs fostalicskara, so sad). Moral support nelkul nem ment volna, koszonet BSZnek erte :) Szoval akkor van bevezeto anim, video, meg zene. Ismet orulunk Vincent. Par aprosag es boldogok is leszunk. Apro pici python scriptek mindent megoldottak. Volt ugye morph es kepek felpakolasa/leszedese rasztersoronkent es az elkeszult framekkel felparameterezni Bubis konverteret. Nem volt nagy tortenet, de kb. egyszerubb volt ra sajat sw-t irni, mint barmilyen meglevo akarmiben osszehozni ugyanezt.
Abban a szerencses helyzetben voltunk, hogy BSZnek programja volt parti elott, szoval el kellett keszulni mar joval elotte a releaseval. Ez szerencsere sikerult is, meg fosbookra is jeleztem, hogy eleg jol allunk. Ilyen meg nem volt (es elnezve Csiot, hogy mit hegesztett meg partin sztem irigylesre melto), hogy valami ennyire idore elkeszult volna.
A videorol keszult egy biztonsagi video (muhaha) 25 fps-el BSZ altal visszadigizve. Ezt a verziot lathatjatok youtubon is, de persze fog keszulni egy normalis (MARGIT!) verzio 50 fps-el ami szinten kint lesz tecson. | First of all, I will be a little wild and omit accents, sorry.
Well, "wild" means "wild", so BSZ "forced" me to make the film nature related. After not dealing with it for a long time, I finally went on YouTube and got a passable short movie. I was supposed to get some frame from this. First I tried VLC, but the result were simply pathetic to say the least, so I tried VirtualDub instead. Just to make life easier, VirtualDub could not process the YouTube format, so I had to convert it to another format. Great, the frames are being processed, over 12000 files. TotalCommander though for a long time when I entered the folder. Hooray for Evo Lution of the PC :O
I wrote a small Python script which called bubis' Java converter with all the parameters. Meanwhile BSZ started taking the PRG files apart, taking the necessary data out of them. He didn't have to hurry, because bubis' software wasn't hurrying either: according to preliminary calculations the 12K frames would take a mere 3 days. For further reference: the original idea was to use MCDIFLI, so the pictures were done that way.
The pictures were done, I sent them to BSZ and he made a test version, which was so horrible that it's hard to find words for it. It skipped, it was noisy, it was everything except beautiful. To use the classic joke; we could have only won in a mine - we send the program down and the coal comes right up. There were one or two scenes which looked acceptable, but I told BSZ that I'm not willing to let my machine run for 3 more days for another test, therefore I started writing my own converter, which was going to produce "simple" non-interlaced MCDFLI pictures. This got done halfway, and we could roughly see what would be in the video, but it was never finalized, the final images were done using bubis' converter once again. Luckily it did not spend as much time on the MCDFLI images (though it did not hurry, of course). I looked for a few more nature movies, I picked a few good loooking scenes -> VirtualDub, PhotoShop, bubis' converter.
We had two ideas for the music: one can be heard in the demo (it's called Hawkeye), which incidentally came across on a remix site, the other I'd rather not say, since there might be a sequel: P BSZ was kind enough to digitize sounds of the freq. converter (which is usually referred to as the click-clack converter), then the digiconverter's sound, and the SID's sound. To merge the freq. + digi + SID and MP3 files was not a big deal. In about 3 minutes I acquainted myself with Audacity (a pretty complicated program) and on the third attempt I managed to put together a passable version (people with absolute hearing can can buzz off).
We're happy, Vincent, we have video and audio, but we still can't slap this in the users' face and say "here's your f*ckin' the video". Especially since we should be showing some kind of musical and graphical evolution, so we started brainstorming, and after a while we settled on the details. I explained to my wife what we'd like to have in the beginning, so she started up Cinema4D to make an animation. After a half day's work she came up with an animation (*note: a joke - play on words - is made here*), on which we could see that Cinama4D was not made for this stuff, so I quickly scrapped this (my wife still hasn't gotten over the shock). I chatted with BSZ over Skype and eventually threw the start-up animation in Unity3D (yeah, I had to code saving the frames and some other stuff, which was no easy task). Without moral support I could not have done it, thanks to BSZ for that :) So was have the intro animation, video and music. We're happy once again, Vincent. Just a few things and we'll be satisfied. A few tiny python scripts took care of everything. There was the morph, showing/hiding the images one raster line at a time, and creating the parameters for those frames for bubis' converter. It was not that big of a deal, but it was much easier to write my own software than using any other existing tool..
We were in the fortunate position that BSZ had other engagements before the party, so we had to complete the release long before the start of the party. Luckily we managed to do this, I even announced on Facebook that we're doing well. We've never managed to do this - being done on time - before (especially seeing what Csio was still doing on the party which IMHO is admirable).
A backup video (mwa-ha-ha) has been made at 25 fps, digitized by BSZ. This version is what you can see on YouTube, but of course we will prepare a proper 50 fps version which will also be out on YouTube. |
|
| |
| | Image Gallery | |
| |
Copyright © Plus/4 World Team, 2001-2024 |
