102
-
Zoleeca #62 " Hanem csak azért kétlem mert ha ilyet meg lehetne csinálni már rég megcsinálta volna valaki. Ez szerintem nyilvánvaló."
Szerintem ne ebből induljunk ki. Hiszen akkor soha semmit nem találnának ki (fel). Viszont ettől függetlenül kételkedem ebben az egészben...
Frayer: szerintem elég sok cég/fejlesztő foglalkozik tömörítéssel ha nem is magyarországon. Elég nehéz elhinni, hogy ilyen óriási ötleteid vannak úgy hogy még be sem fejezted a tanulmányaidat. Persze ettől még lehetnek, de meg kell értened hogy sokan kételkednek...és az hogy egy ilyen topicba csak úgy felveted a dolgot, már önmagában furcsa. Egészen addig amíg valami működő cuccot nem mutatsz fel, szerintem hanyagolni kellene a dolgot. Anélkül is kérdezhettél volna forrásokat hogy kvázi konkrétan elmondod mit is akarsz csinálni, és akkor nem kellene hallgatnod a sok szkeptikust.
Mindazonáltak kíváncsi lennék, hogy hol és mit is tanulsz pontosan, hanyadéves vagy és esetleg hány éves. Persze nem muszáj válaszolni, csak érdeklődöm. -
r4pt0r #61 Én már láttam olyan játékot ami kb. 90kb és 300mb lesz miközben futattod. Csakhogy ezt úgy érte el hogy minden textura, minden hang lényegében egy algoritmus volt. Nem tartalmazott lényegében semmit. Meg is kérdezték tőlük hogy nem tudnak e rendes tömörítést csinálni de aztán írták hogy nem nagyon mert amit ők csináltak játék, abban csak olyan dolgok voltak amit függvényekkel meg tudtak csinálni.
pl.
tömörítsd be a bibliát, és aztán egy karakterszámra megegyező doksit de csak A betű legyen benne. Hát a másodiknál igen jól lesz a tömörítés az elsőhöz képest.
Szerintem csak olyan dolgot lehet hatalmas hatásfokkal tömöríteni amit le lehet vezetni egy képletre, de szerintem ennek az az ára hogy ne legyenek benne "kiszámíthatatlan dolgok". És hát egy film csak ilyenekkel van tele.
Én nem értek a témához ez tény, ezért nem is annyira a leírtak alapján mondom hogy tévedsz, és feleslegesen pocsékolod az időd. Hanem csak azért kétlem mert ha ilyet meg lehetne csinálni már rég megcsinálta volna valaki. Ez szerintem nyilvánvaló.
De ez csak szigorúan szvsz.
-
turul16 #60 Cél hardware engem is érdekelhet majd :) , De most nem keresek melót. -
#59
Ha tényleg célhardver készülne rá, mondjuk a procikba beépítve, miért ne?? hiszen a zip, meg divx kedvéért hoztak létre speciális utasításokat is a procikba.
Akkor leszarom az sse utasításokat és neki állok a bitléptető operátorokkal szórakozni, szar lassú lesz, de remélem ki tudom dumálni hogy miért, és meg tudom magyarázni,hogy ennél lehet 10 szer gyorsabb is, hardveres gyorsítással meg gondolom 100 szor is. -
L3zl13 #58 Egyet értek az előttem hozzászólókkal. Szerintem is kamu.
Az nem érv, hogy túl lassú a C-ben írt kód. És azzal sem értek egyet, hogy akár a kész programnak képesnek kell lennie real-time kicsomagolásra.
Ha 3 hónap alatt tömörít be fél percnyi tetszőleges HD anyagot kb száz kByteba (ha 180 perc 20-30MB akkor fél perc kb 80kByte), akkor is kész lennél, hiszen mint mondtad az algoritmus az ötlet lényege, és nem a kód.
De nem. Te inkább SSE leírásokra vadászol, mikor még azt sem tudod működik-e a valóságban, amit kitaláltál, és főként NEM TUDSZ FELMUTATNI ÍGY SEMMIT.
Vásárlót akarsz? A nagy szoftvercégek, és videós oldalak pontosan ugyanannyit fizetnének a tetűlassú változatért, mint a villámgyors SSE-t használó ASM kódért, hiszen őkat csak 2 dolog érdekli.
1. Lássák, hogy nem kamu.
2. A licenc jog.
Az optimalizálást ők is meg tudják csinálni ha kell.
-
#57
Itt van egy kis leírás, hogy mások is értsék a dolog lényegét:
A cantor halmaz
Nem én találom ki ezeket a dolgokat, én csak erre írok egy algoritmust. -
#56
Hmm.
Nem tudom mi bajod van az entrópia fogalmával, a huffman kódolás is entrópia kódolás.
Pedig létezik az egységesített eljárás.
Érdekes, én meg mindenhonnan ezt hallom a suliban,hogy egységesített, egységesített, és az UML a leíró nyelve. Ez egy grafikus ábrázolás, egységes,hogy mindenki aki részt vesz vagy később kapcsolódik a fejlesztésbe könnyen áttláthatja.
SF.NET en is ezzel dolgoznak sokan a dokumentálást is ezzel végzik.
Lényegtelen.
Nem azt mondtam hogy a mandelbrot halmazból vettem az 5letet, hanem egy a mandelbrothoz közel álló felfedezésből, amihez köze van a kantor halmaznak is.
Igen, egy dimenziós számsorban érvényes a kantor por, talán a bitek, egyesei és nullái nem egy egydimenziós sorozatot alkotnak?
Igenis, a világunk hemzseg a paradoxonoktól.
Vannak ellentmondásos események, kimenetelek, mint mondjuki a kvantummechanikai kétréses kísérlet eredményei, amit a mai napig nem oldottak meg, ez a kísérlet aszerint változtatja eredményeit, hogy te a megfigyelő vonatkoztatásban figyeled.
Akkor ott van a shrödinger macskája elméleti paradoxon. A matematikában ott volt a pozitron matematikai leírásában, amikor még fel sem fedezték és többen hülyeségnek mondták mert ez így lehetetlennek tünt, aztán mégis.
Ezzel csak azt akarom mondani,hogy a világ amiben élünk teli van olyan dolgokkal amik elméletileg, matematikailag nem lenne lehetséges, de attól még úgy mennek a dolgok ahogy mennek.
Kösz a referenciákat, áttanulmányozom vizsgák után.
Én csak annyit mondok,hogy nem kell hinni nekem, meg ez amúgy sem egy komoly eredmény, a tömörítéstől nem oldódik meg a gáz ára, vagy nem lesz kevesebb éhezés a világban.Szimplán ha elkészül szebb lesz a video a nappaliban.
Majd ha elkészülök aki akar az ott lehet mert úgy is be akarom majd mutatni, talán az egyik egyetemen a nyilvánosságnak. Azért én is érzem hogy pár dolgot megváltoztatna az informatikában.
Azért mertem ide írni erről a forumba mert már biztos vagyok benne hogy működik, hogy ne legyen az, hogy nagyot mondok és aztán meg sehól semmi, aztán meg jól beégek. Pedig írtam már elég sokat ebbe a forumba. Páran már ismernek,hogy nem csinálok segget a számból.
Programozásban sajnos nem vagyok olyan jó mint amilyen szeretnék, volt hogy vizsgán sem mentem át ezekből elsőre. De azért lassan haladok, max sokat fogok debugolni. -
#55
Teny, hogy osszehordott egy-ket dolgot a srac, de en azert nem huznek le senkit csupan feltetelezesekbol kiindulva majd tenykent kezelve. Lattam en mar kep es 3D mozgasfelismerot is olyan manustol aki anno ~10 evvel ezelott a "hello world"-ot hetekig nem tudta megerteni valamint nagysagrendekkel tobb zoldseget hordott ossze.
Most a kinai kormany vendegszeretetet elvezi es egy ottani egyetemen tanitja a talalmanyat eleg szep jovedelem mellett.
-
kay3 #54 LOL :D Frayer, percekig sírva röhögtem...
Csak néhány apróság:
- tanuld meg az entrópia definícióját, és akkor nem fogsz ellentmondásos dolgokat írni (és gondolni) róla
- idén végzek infó szakon, de esküszöm soha nem hallottam még "Száraz teszt logikai emuláció"-ról, ami "az implementáció és az analízis között" lenne, kérlek mutass linket egy erról szóló leírásra, nagyon érdekel mi ez
- miféle "egységesített szoftverfejlesztési eljárás"? van egy csomó szoftverfejlesztési paradigma, mindegyik másra jó, nincs egységesített. írd le melyikre gondoltál
- a procik utasításkészleteiről rengeteg infó van
- a Mandelbrot halmazok _nem_ véletlenszerű struktúrák, hiszen egy jóldefiniált függvény írja le őket
- a világunkat nem paradoxonok írják le, ez simán faszság. paradoxonok azért léteznek, mert a világ leírásához használt modellek nem tökéletesek, továbbá a létezésükből nem következik hogy a te programod jó lesz. tanulnod kéne logikát is
- Einstein ikerparadoxona a fizika (konkrétan az idő) paradoxona, köze nincs az információelmélethez
- a Cantor-halmazokat folytonos, egydimenziós térben értelmezzük, és inkább analitikai érdekességnek számít. nem is értem hogy sikerült ezt összehozni a tömörítési eljárásokkal
- szeretném látni azt a levezetést ami a Cantor halmazokat használja fel egy zajos csatornán a bithibaarány megállapítására
- az asszociatív tömbök egyetlen hardveres megvalósításáról tudok, ez pedig a prociban lévő TLB (Translation Lookaside Buffer), és nem lehet programozni. a szoftveres asszociatív tömbök meg közismerten piszok lassúak, ezen kb elvérzett az egyik hozzászólásod
- olyan "gcc plugin" ami csinál neked saját programnyelvet nincs és nem is lesz soha
- "tesztek" (elágazások) nélkül nem lehet olyan programot írni ami csinál is valamit
- news flash: a c++ kódba lehet asm betéteket tenni (igen, sse utasításokat is)
természetesen ha bármikor (legyen mondjuk 10 éven belül) demózol nekem egy a lenti feltételeknek megfelelő _működő_ be- ÉS kicsomagoló programot aminek én adhatom a bemenetét akkor leborulok előtted, de van egy olyan érzésem hogy erre nem lesz szükség :)
ja, még valami: majd figyelj arra hogy a programod kicsomagoljon egy HD képet 40msec-onként (általad választott processzoron), mert ha ennél lassabb, akkor a 24fps nem fog menni :)
Azért jól szórakoztam. És minden elismerésem: élénk a fantáziád, ami egy fontos dolog, de azért ne csinálj magadból hülyét :) -
Drawain #53 Poénból rákerestem, AMD főoldaláról három kattintással le lehet szedni a keresett doksikat. Belinkelem ide, ezzel is támogatva az "erőfeszítéseid":
AMD Software Optimization Guide
Ajánlom a 9. fejezetet (szép példák is vannak asm-ben, hogy ne érje szó a házat...) -
spR #52 Hat szereny velemenyem szerint Te kamuzol, (vagy csak szimplan idiota vagy, mar ne is haragudj) de ha telleg csak a az SSE-n mulna a dolog, hat tessek:
http://softpixel.com/~cwright/programming/simd/sse.php
http://www.tommesani.com/Docs.html
(aztan nehogy az legyen a kifogas, hogy angolul van, egyebkent google rogton kikopte)
Amugy dez-nek igaza van, meg barki, aki kicsit is jartas a programozasban, azonnal vagja, hogy egy fejlesztesnel az optimalizacio a legutolso lepes. Irdd meg az uber-algoritmusodat C++ -ban, tok mindegy, hogy milyen lassu lesz (amugy bitenkenti logikai operatork asm-ban sem lesznek gyorsabbak) aztan ha mukodik biztosan, akkor kezdd el optimalizalni.
De megen fenntartom, hogy szvsz Te itt csak hulyited a T. torzskozonseget, vagy fogalmad sincs, hogy miket beszelsz, plane ilyen kijelentesek utan:
"sima c++ meg egyéb nyelvekkel nem igen lehet proci szinten kavarni a bitekkel"
Megis mit gondolsz, a C++-ban irt kodot, (ami gepi kodra fordul), gonosz manok hajtjak vegre a processszor helyett? :)
-
Drawain #51 Komolyan mondom el nem tudom képzelni, hogy valaki ennyire fontos, hatékony és komplex dolgot fejlesszen ki, ha képtelen megtalálni egy publikus referenciát az intel oldalán:
Intel® 64 and IA-32 Architectures Software Developer's Manuals
Van az oldalukon máshol is még jónéhány referenciakönyv, ha ez kevés lenne.
Személy szerint egyébként sem tudok komolyan venni valakit akinek ennyire pocsék a helyesírása... -
#50
Eloszor az jutott eszembe, amiket irtal, hogy a Bibiaban hihetobb dolgokat olvastam, de a magam parasztos elmeleti oldalarol megkozelitve az jutott eszembe, hogy hiszen pl a Mandelbrot halmaz is vegtelenul komplex, es vegul is egy nem tul bonyis algoritmus irja le! Vagy is ha egy kep abrazolasara talalunk nehany szaz "kozelito" fraktal fuggvenyt akkor akar kepkockankent/kulcskepkockankent par szaz byte-tal leirhatunk mindent.
Aztan meg az jutott eszembe, hogy nem igaz hogy ezt nem csinalta mar meg valaki!;))) -
Zoleeca #49 Ha én bármi hasonló volumenű dolgot fejelsztenék, akkor a lehető legtitkosabban tenném ezt...ugyanis ha "hihető" hogy valaki ilyet csinál az a "gonosz feketeöltönyös fickóknak" már tökmindegy hogy télleg meg tudja-e csinálni, vagy csak kitalálta. -
Zoleeca #48 "Én nem egy profi programozó csapat vagyok.
Hobby szinten kezdtem el fejleszteni, programozást is még csak tanulom, igaz már évek óta, de még nem vagyok benne olyan jó."
Asszem ezt elolvasva egyre inkább azt képzelem, hogy csak kitalálod az egészet...
Ne legyen igazam...de ha télleg ilyesmit csinálsz akkor télleg szükséged lesz valamiféle védelemre, mert túl sok embernek nem áll érdekében az ilyesmi...
De szerintem erre neked is gondolnod kellett volna...vagy még túl fiatal vagy...ha ez pedig így van akkor méginkább gyanús a dolog. -
#47
-
dez #46 Már kiderült, lekenyereztek néhány fejest a Paramountnál 150 millió dollárral, hogy adják fel a függetlenségüket. -
#45
Mindenről a MS tehet arról is ha esik, ha fúj, ha villámlik, ha tűz van, ha hurrikán... stb SZÁNALMAS -
Wittgen #44 Már több, mint 6 éve abbahagytam a programozást, úgyhogy érdemben hozzászólni ezekhez a hozzászólásokhoz nem tudok már 
De legalább értem, miről van szó
-
dez #43 Nem, te ezt írtad:
"sima c++ meg egyéb nyelvekkel nem igen lehet proci szinten kavarni a bitekkel"
Pedig lehet. Csak persze nem lesz a lehető leggyorsabb, de az első cél, hogy működjön, egy ilyen teljesen új eljárás. -
dez #42 Talán indulj el innen: link
Szerintem így gyakorlat nélkül éppenhogy az SSE-s asm-mel tennéd ki magad a nehezen felderíthető bugoknak, de te tudod... -
Villanypásztor #41 Ha tényleg működik a dolog, akkor teljesen felesleges itt az assemblerrel szenvedned. (bár szvsz többet érne ha az ebbe fektetett energiából inkább megtanulnál hatékony kódot írni C-ben)
Megírod olyan sebességűre, amilyenre sikerül, felbérelsz néhány gorillát, hogy ne öljenek meg, felrakod egy laptopra a progit és bemutatod valami pénzes csókának. Ha tényleg működik, akkor úgyse érdekel senkit amit összegányolsz assemblerbe, részben mert megírják mások, részben meg mert úgyis célhardver készül rá azonnal.
Amúgy az az érzésem, pár év múlva nem leszel büszke erre a topikra... -
#40
Dzsilett, most mondom,hogy ezek a c++ operátorok lassúak, és nem optimalizáltak, gyakorlatilag 8086 os utasítások lesznek belőlle, gcc-vel leforgatva.
De akkor már jó lenne ha lenne valami see kiterjesztett támogatás hozzá a gcc hez vagy valami más c++ compillerhez, nekem mindegy, csak kezelje a sztandard c++ és api hivás könyvtárakat. -
#39
Nekem jók lennének friss asm kódok, a legjobban egy teljes sse utasításkészlet referenciának örülnék, asm kódokkal. Mivelhogy assembly volt az első programozási nyelv amiben tanultam, 10 éve. Leszámítva a basic-et c-64 en, amit én nem neveznék programozási nyelvnek, inkább scriptnek.
Na mindegy, ha tudsz sse referenciát akkor linkeld már be, google erre nemjó, intel oldalain semmi.
Ha publikusak, akkor honnan a faszból tudjam meg? Az intelnek is elvileg az lenne az érdeke hogy mindenki hozzáférhessen mivel így biztosított minél több programban az intel procik támogatása. Na jó amd is támogatja az sse-ket.
C++ ban sokkal nehezebb megírni mint asm-ben, mert teljes egészében bitekkel dolgozik a kód, és hát c ben a bitléptető operátorokkal szórakozni, átkonvertálni, fejben kiszámolni hogy mikor milyen bitsorozatra milyen c++ kódot írjak az elég komplex és nagy lenne a hibalehetőség is.
A c++ az jó, de csak ha beágyazott asm kódokkal írom meg a magját ami az adatokkal dolgozik, az egyébb funkciók meg c ben lesznek lekódolva.
2. Száraz teszt logikai emuláció, tudod, ami az egységesített sw fejlesztési eljárásban az implementáció és analízis között van. -
dez #38 a.m. operátorokat :)
Ezek:
& AND
| OR (inkluzív)
^ XOR (exkluzív OR)
<<(x) shift balra x bittel
>>(x) shift jobbra x bittel
~ egyes komplemens (invertálás)
(Nem keverendők a logikai operátorokkal (&&, ||, stb.).)
Érdekes, ha egy számtech tanár nem ismeri ezeket... -
dez #37 Miféle szoftveres emulációról beszélsz? -
dez #36 Mit értesz az alatt, hogy túl szakiknak szól? A vonatkozó asm utasítások leírása? Ha igazán optimális kódot akarsz, kénytelen leszel megismerkedni vele. Majd, egyszer... Most először írd meg sima C-ben! Itt a bitenkénti logikai operatárokat használhatod. Működjön, aztán lehet majd optimalizálni... -
#35
Én lossless 48khz 24 bites hangal számoltam HD video révén 30fps el 24 bites színmélységgel.
De nem az a lényeg,hogy mekkora a kiinduló értékek mérete, hanem hogy milyen gyorsan tud dolgozni a processzor, mennyi időbe telik az adatok helyreállítása a kezdeti állapotba.
Negatív hatás : rekurzív az algoritmus, ezért többször át kell futni a kódon, egymás után akár több százszor is.
Pozitív hatás: Az algoritmus soros szervezésű és nem vizsgálja meg a környezetében lévő több ezer bájtot, minden egyes bit-szekvencián.
Ezért egy iteráció gyorsaságát inkább csak a memória sávszél fogja korlátozni, főleg ha meg tudom oldani hogy tesztelő operátoroktól mentes legyen a kód.
Szoftveres emulációval jól ment eddig a dolog, de foggalmam sincs hogy pontosan milyen gyors lesz a kód egy valódi procin. -
#34
Linket tudnál adni? Mert az is teljesen nonszensz, hogy 2000-3000 megába beleférjen (legalább az 5szöröse kéne hozzá), de ez a 20-30 mega az ugyanmár kategória. Egy 32 bit színmélységű 1920*1080-as lossless kép kereken 8 mega. Kb 3 ilyen kép férne el az általad leírt 20-30 megában, ami 24fps-t nézve 1/8-ad másodpercet jelent, nem 180 percet. Ráadásul a hang bele sincs kalkulálva :) -
#33
Rendben, Food/LFG lesz ;) -
Juszufka #32 Szia! Ha kész a programod, és félsz, hogy nem tudsz belőle pénzt teremteni, csak szólj!
Vállalom az értékesítését a bevétel 0,0001%-áért cserébe. Hidd el, én zsírgazdag lennék, szerintem ez jelent valamit. -
FoodLFG #31 Frayer:
Vagy te vagy a megváltó, vagy csak hülyeségeket beszélsz. Én nem tudom eldönteni, mert egy szót sem értek abból amit írsz. De az biztos, hogy amíg nem lesz itt a kezünkben a működőképes codec, vagy annak egy feltört változata (tökmindegy), addig az átlag ember szemében te csak egy esgés fórumozó vagy, aki nagyokat mond.
Az is kicsit vicces, hogy mindeközben a vizsgaidőszak miatt aggódsz. o.O
Mindenesetre drukkolok.
jameg elneveznéd az algoritmusodat (Food)LFG-nek, a nevem után ? thx -
#30
Hidd el haver kerestem.
De vagy túl szakiknak szól, vagy ősrégi asm kódokba botlottam ami ősrégi utasítás készletet használ.
Azt viszont tudom,hogy hardwareben otthonosan mozogsz, adhatnál nekem linkeket erre vonatkozólag.
Ami érdekel, gyors műveletek bitekkel, bitsorozat keresése, bitek állapotától függő kódvégrehajtás, olyan ami gyorsan működik.
Ha lehet minél kevesebb jmp,jnz meg egyébb tesztelő elágazásokkal, azt tudom,hogy ezek sok proci időt vesznek el mert a tesztelt eredménytől függő vizsgálat megbontja a soros pipelineokat. Erre azt találtam ki,hogy a sorban lévő bitek értékét ha lehet egy egyszerű sse utasítással betöltöm egy 8 bites "al" regiszterbe és ezt a regisztert használom referenciának egy asszociatv tömbben ami a szükséges kódszekvenciára mutat, így megsporolva egy tesztelő operátort mint a jnz, asm-ben.
Amúgy talán még egy olyan plugin vagy valami is jól jönne amit be tudok építeni a gcc-be és általa sse készletre optimális kódokat tudok írni, sima c++ meg egyéb nyelvekkel nem igen lehet proci szinten kavarni a bitekkel, a short int, meg char-nél nem nagyon vannak kisebb típusok :(, mivan ha nekem épp 2 vagy 3, 4 bitet kell vizsgálnom, de szélsebesen??? Ilyenkor mi a teendő? Tanár nem tudja, senki nem tudja :S azér ez már durva, okosabbak azt mondják, nézzek utánna a kiterjesztett utasításoknak amik bitekkel operálnak, de google nem sokat segít.
erre azt találtam ki -
#29
Nemreg olvastam egy cikket az XBOX torteneterol, es abban az volt hogy a jatekgep projekt gyak versenyzett egy letoltos videossal, es a jatekgep nyert. Nos azota a Micro jo par milliardot vesztett ezen az uzleten, ahogy azt valamelyik alkoto meg is mondta, majd kilepett projrktbol. A letoltos video meg azota valaszeg befutott volna. Szal az hogy a Mikrobi ebben a temakorben mozog nem ujkeletu. -
dez #28 "nincs sok infó a procik kiterjesztett utasítás készleteiről, ehez meg kellene mert elég speciális bitekkel dolgozó kódja van. Amit találtam az régi ASM kódok mmx re meg kibővített pentiumra. De az lófasz az ss4 korában."
Viccelsz??? Teljesen publikus a dolog. Talán kezdd a világmegváltást a google megismerésével... ;) -
dez #27 Ez a fraktálos ötlet nem új. Pl. én is elkezdtem írni egy ilyen tömörítőt úgy 16 évvel ezelőtt (szilveszterkor bulizás helyett, mert izgatott a dolog :P). De túl lassú lett volna. Legalábbis akkor.
"és ezt annyiszor játszod el ahányszor csak akarod és mindig kisebb lesz az eredmény"
Nem, egy idő után természetesen a kapott számhalmaz már nem kisebb, hanem nagyobb.
-
#26
Nemtom, én nem az a gyerek vagyok abból a topikból.
1,
1 bitbe az én megoldásommal nem lehetne, a tömörített adat tartalmazza a rekurzió számlálót, több stream szekvenciát is el kell határolni egymástól és azoknak is le kell írni az állapotait, meg hogy hól kezdődik és hól van vége, stb.
Egy bitbe nem, de egy két százba már be lehet tömöríteni.
Pontosan nem tudom milyen sebességgel, de ahogy előzetesen számolom, kb másodpercenként úgy 50-80 megabájtot be tudna csomagolni, egy 1 ghz-s procival 2,7 Gb/s es memória sávszélen. Ha sikerülne megoldanom a bitekkel dolgozó sse utasításokkal való munkát, csak 8086-os bitléptető utasításokkal 10X lassabb a dolog.
2.
Azon vagyok, de előbb hagy készüljön már el.
3.
Egyértelmű hogy e nélkül semmit sem érne :D -
dez #25 Biztos tök véletlenül állt a Paramount a HD_DVD mellé (előzőleg elvből mindkettőt támogatta...), amikor már éppen nyerni készült a Blu-ray... Többszörös eladások, stb. Most meg megint közel patthelyzet... Így az emberek többsége továbbra is kivár, nem vásárol. Biztos ez a jó a kiadóknak is... -
Addict #24 Nem szerzek komoly vasarlot, amig nem latom a kesz termeket. Amugy meg nehogymar kulfoldi kezbe keruljon egy ekkora ertek. Eloszor add el nekem, aztan ha jo, akkor add el a Google-nak, ok? -
assdf #23 ui: az a topic több mint két éve kezdődőtt a nagy bizonygatások ellenére a mai napig nem létezik ez az eljárás, ahogy a tiéd sem fog sohasem. Remélem nem joysoft vagy vagy derx csak épp más néven...