Hardware Upgrade Forum

Hardware Upgrade Forum (https://www.hwupgrade.it/forum/index.php)
-   Schede Video - Discussioni generali (https://www.hwupgrade.it/forum/forumdisplay.php?f=28)
-   -   [HWVintage] Retrogaming avanti tutta (https://www.hwupgrade.it/forum/showthread.php?t=991407)


Simon82 22-08-2006 09:45

Quote:

Originariamente inviato da Max_R
Beh dai :D Le Vsa100 supportano anche il rendering a 32 bit :p Comunque come giustamente è stato detto il Vsa100 sarebbe stato l'avenger perfetto...

Gia, e aggiungerei una cosa: il TBuffer poteva realizzare ottime cose come si vedeva sulla carta ma ormai penso che per quel genere di effetti essendo tutti da supportare in fase di programmazione dei titoli, avrebbe dovuto lasciare l'onere a Microsoft con le nuove api. Non era gia piu' un epoca in cui features proprietarie potevano sfondare se non quelle indipendenti dal software e dagli sviluppatori (vedi FSAA). 3Dfx in un certo senso voleva forse con il Tbuffer proporre effetti che da li a breve gli shaders avrebbero permesso aumentandone le possibilita'.

Max_R 22-08-2006 10:19

Quote:

Originariamente inviato da Simon82
Gia, e aggiungerei una cosa: il TBuffer poteva realizzare ottime cose come si vedeva sulla carta ma ormai penso che per quel genere di effetti essendo tutti da supportare in fase di programmazione dei titoli, avrebbe dovuto lasciare l'onere a Microsoft con le nuove api. Non era gia piu' un epoca in cui features proprietarie potevano sfondare se non quelle indipendenti dal software e dagli sviluppatori (vedi FSAA). 3Dfx in un certo senso voleva forse con il Tbuffer proporre effetti che da li a breve gli shaders avrebbero permesso aumentandone le possibilita'.

Perfetta per il mercato console ma anche per questa possibilità, già persa una volta, era ormai troppo tardi... Comunque nulla di così triste alla fine dato che se non fosse stata 3Dfx sarebbe stato qualcun altro... Nulla di grave perchè 3Dfx ha aperto la strada ed ha scritto la storia... Si sarebbe dovuta comunque adattare e mettere al passo con ati e nvidia e le schede dei tre produttori si sarebbero allineate a tal punto, per quanto riguarda la tecnologia (come è successo con ati e nvidia) che comprare l'una o l'altra non avrebbe più fatto la differenza... Il "miracolo" era già stato fatto e non si poteva ripetere... Nessun'altro potrà tuttora :)

Space Marine 22-08-2006 10:22

Certo che a pensarci, 666 megapixel e texel al sec nel 99 avrebberò spiazzato pure il gf256 (che faceva 480/480).
E' come se si fossero ritrovati un anno, un anno e 2 mesi indietro alla concorrenza.


Tralaltro perchè il v5 non l'han fatto a 183mhz invece che 166?

Space Marine 22-08-2006 10:24

Quote:

Originariamente inviato da Max_R
Perfetta per il mercato console ma anche per questa possibilità, già persa una volta, era ormai troppo tardi... Comunque nulla di così triste alla fine dato che se non fosse stata 3Dfx sarebbe stato qualcun altro... Nulla di grave perchè 3Dfx ha aperto la strada ed ha scritto la storia... Si sarebbe dovuta comunque adattare e mettere al passo con ati e nvidia e le schede dei tre produttori si sarebbero allineate a tal punto, per quanto riguarda la tecnologia (come è successo con ati e nvidia) che comprare l'una o l'altra non avrebbe più fatto la differenza... Il "miracolo" era già stato fatto e non si poteva ripetere... Nessun'altro potrà tuttora :)

Però diciamo che maggiore concorrenza dovrebbe portare ad un abbassamento di prezzi...

Considera che ora come ora il mercato delle schede video è praticamente al limite:
se uno dei 2 principali produttori dovesse fallire, lascerebbe all'altro la strada libera per il monopolio.

Max_R 22-08-2006 10:43

Quote:

Originariamente inviato da Space Marine
Tralaltro perchè il v5 non l'han fatto a 183mhz invece che 166?

Il Vsa100 è quello che è... Poco tollerante... Le memorie lo sono ancora meno... Se il Vsa100 avesse avuto il supporto per le ddr (Vsa101) si sarebbero aperti nuovi fronti credo... Ma la strada comunque sarebbe stata ancora lunga...

conan_75 22-08-2006 13:06

Quote:

Originariamente inviato da Space Marine

Tralaltro perchè il v5 non l'han fatto a 183mhz invece che 166?

La scheda era gia al limite, con tanto di alimentazione supplementare.

Crisp 22-08-2006 13:24

Quote:

Originariamente inviato da conan_75
Mmmmm, si e no.
Se non mi sbaglio G-Police lo giocavo a 800x600 con la Permedia2 che era ben precedente alla V2, diciamo coetanea della V1.

Però il permedia2 non aveva in hardware alcune funzioni di blending che molti giochi OpenGL invece sfruttavano e quegli effetti andavano emulati via software..
Ottima scheda invece nel 2D.

conan_75 22-08-2006 13:50

Quote:

Originariamente inviato da Crisp
Però il permedia2 non aveva in hardware alcune funzioni di blending che molti giochi OpenGL invece sfruttavano e quegli effetti andavano emulati via software..
Ottima scheda invece nel 2D.

Non avendo il collegamento a internet dovevo basarmi sui driver originali: con quelli l'unico gioco OGL che avevo provato era Q2: diciamo che andava benino come prestazioni, ma aveva dei problemi di stabilità, ovvero ogni tanto ero costretto a ricaricare le mappe perchè si corrompeva tutto.
In D3D era abbastanza stabile: giochi come G-Police, Whipeout 2097, Forsaken o Viper Racing andavano alla grandissima.
Ci girava così così addirittura NFS HP e alla grande Mortal Kombat 4 :eek:

Il 2D invece era pessimo: confrontato ad una Ati Rage 4Mb c'era un'abisso, ma anche la Virge andava meglio :(

sanford 22-08-2006 13:56

Quote:

Originariamente inviato da Space Marine

Tralaltro perchè il v5 non l'han fatto a 183mhz invece che 166?

Da quello che so io (se non ricordo male) non era tanto un problema di VSA100 ma dipendeva dal fatto che all'epoca 3DFX aveva i magazzini stracolmi di ram video a 166mhz, era in forte ritardo con l'uscita del Voodoo 5 e doveva contenere al massimo i costi, da qui la scelta di mettere il VSA a 166.

Il VSA100 dovrebbe reggere tranquillamente i 200 mhz o qualcosa in più ma ci vogliono memorie sdram da 5ns che all'epoca erano troppo costose da mettere su una scheda già costosa di suo. :(

Simon82 22-08-2006 14:01

Quote:

Originariamente inviato da Space Marine
Certo che a pensarci, 666 megapixel e texel al sec nel 99 avrebberò spiazzato pure il gf256 (che faceva 480/480).
E' come se si fossero ritrovati un anno, un anno e 2 mesi indietro alla concorrenza.


Tralaltro perchè il v5 non l'han fatto a 183mhz invece che 166?

Perche' imho il VSA100 costruito con il processo a 0,25u era gia' quasi limite a 166mhz cosi' come le strausate SDRAM da 6ns (?) che hanno messo perfino nel latte e biscotti al mattino. A quanto pare ne avevano gia' acquistate a montagne per montarle sulle V3 3000 aspettandosi probabilmente delle vendite eclatanti.
Se invece di spendere milioni di dollari in progettare nuove revision di V5 6000 avessero cercato di far produrre un VSA100 a 0,18 fin da subito e cloccarlo magari ad un ipotetico 200Mhz forse la V5 5500 avrebbe venduto un po' di piu' sebbene ormai la fine era segnata.

Siamo andati un po' ot? :stordita:

walter sampei 22-08-2006 14:08

ma chi era che dava sti ordini???

Simon82 22-08-2006 14:09

Quote:

Originariamente inviato da walter sampei
ma chi era che dava sti ordini???

Intendi le scelte in ambito marketing?

walter sampei 22-08-2006 14:38

esatto... mi sembrano a dir poco suicide :help:

Simon82 22-08-2006 14:49

Quote:

Originariamente inviato da walter sampei
esatto... mi sembrano a dir poco suicide :help:

A volte certe idee che sembrano pazze funzionano (vedi Nintendo e la sua politica di nicchia che mantiene comunque, si spera, fama e gloria anche se in questo e' il Giappone e soprattutto i giapponesi a fare la differenza) in altri casi fanno fallire le aziende. Per 3dfx alcune scelte sembrano talmente tanto suicide da apparire fin "strane" come se la morte dell'azienda fosse stata decisa ben prima.

Space Marine 22-08-2006 16:55

Ma come mai le 3dfx hanno la frequenza di core e memoria vincolate?
Non potevano mandare il chip a 183 mhz e lasciare la ram a 166?


P.S: non è tanto ot, stiam parlando cmq di schede da "retrogaming" :D

shodan 23-08-2006 09:44

Ciao a tutti,
approffitando delle ferie, ho condotto qualche nuovo test.

Le schede questa volta torturate sono state le 2 seguenti:
-)Radeon 8500 64MB 275/275 (core/mem)


La scheda in questione è una Hercules 8500 LE, quindi con clock di 250/238. Ho comunque decisa di testarla overcloccata alle frequenze di una Radeon 8500 BBA in modo da fare un confronto tra questa a la seconda scheda provata.
La scheda è stata testata con 2 revisioni di driver differenti: sia con i Catalyst 4.2 (che ricordavo andare molto bene su questa scheda), sia con gli ultimi che la supportano, cioè i Catalyst 6.5.

-)GF4 Ti 4600 128MB 300/330 (core/mem)


Questa scheda è la punta di diamante della linea GF4, indubbiamente una serie di schede molto riuscite. Il clock della memoria è leggermente più elevato di quello dettato dalle specifiche nVidia (330 Mhz invece che 325 Mhz); ho comunque deciso di lasciare la scheda con le impostazioni di default.
La scheda è stata testata con 2 revisioni di driver differenti: sia con i Detonator 43.45 (uno degli ultimi set a permettere l'abilitazione dell'early Z culling), sia con i Detonator 91.31 (gli ultimi WHQL). I driver 43.45 sono stati utilizzati sia con impostazioni di default che con l'early Z culling abilitato tramite Rivatuner.

Il sistema utilizzato è cambiato ed è il seguente:
-) AMD Athlon XP @ 2500 Mhz (200x12,5)
-) AsRock K7NF2-RAID (chip Nforce2 Ultra)
-) 512MB di RAM DDR 400 (256x2)
-) HD primario Quantum Atlas IV 18 GB SCSI-80 (per il s.o.);
-) HD secondario IBM 120 GB (per le applicazioni e il file di swap);
-) S.O. WinXP SP2.
Il sistema appena descritto dovrebbe evitare di rappresentare un collo di bottiglia per le prestazioni delle schede video analizzate.

Le 2 schede sono state provate con le impostazioni di default di ogni driver; le uniche modifiche sono state la disabilitazione del Vsync e, sui Detonator 43.45, l'abilitazione dell'early Z culling per una serie di test (i test con questa funzione indicata sono indicati nei grafici con un colore diverso).

I benchmark sintetici utilizzati sono stati:
-) Fillrate tester di Marco Dolenco;
-) 3DMark2001 SE.

I giochi utilizzati sono stati:
-) Quake 2 demo (impostazioni di default);
-) Quake 3 demo (impostazioni di massima qualità);
-) Quake 4 demo (impostazioni di bassa qualità);
-) Serious Sam SE (impostazioni di massima qualità tranne il filtro anisotropico, impostabile direttamente dal gioco);
-) Forsaken demo (impostazioni di default);
-) UT2004 demo (impostazioni di alta qualità);
-) Halo demo (impostazioni di default);
-) FarCry demo (impostazioni di media qualità);
-) CoD 2 demo (impostazioni di media qualità);
-) Battlefield 2 demo (impostazioni di media qualità).
La risoluzione utilizzata per tutte le applicazioni è stata di 1024x768x32@60Hz; fa eccezione il Fillrate Tester che è stato provato alla risoluzione di 1280x1024x32@60Hz. Dove l'applicazione lo permetteva, è stato sempre abilitato il filtraggio trilineare delle texture. I filtri AA e AF sono sempre stati disattivati.

Analizziamo prima di tutto il fill-rate di cui sono capaci le 2 schede. Rispettivamente, ecco i risultati del Fillrate tester e del 3DMark2001 SE...

Nel confronto fra le schede, vediamo che nei test pure, z e single-texture fillrate le 2 schede sono abbastanza vicine, con differenze probabilmente dettate dalle diverse velocità di clock; nei test di dual, triple e quad texturing la Radeon 8500 ha un crollo netto delle prestazioni (tanto da far pensare, come anche indicato da Yossarian tempo addietro, che in queste condizioni il chip che equipaggia la scheda, cioè l'R200, non sia in grado di utilizzare tutte le sue 4 pipeline di rendering).
La 8500 si rifà però nel test dei pixel shader 1.1, dove ha un punteggio molti più elevato della ti4600. I pixel shader 1.4 sono invece appannaggio esclusivo della 8500.
Nel confronto fra i driver, vediamo risultati tra loro simili, a esclusione di 2 test:
-) per la GF4 ti4600, i driver 91.31 hanno un risultato in triple-texture decisamente inferiore ai 43.45;
-) per la Radeon 8500, i driver 6.5 hanno prestazioni nel test ps 1.4 molto inferiori ai driver 4.2.
L'early Z culling non porta significative differenze.
In entrambi i casi penso che la differenza sia dovuta all'ottimizzazione dei driver per le nuove architetture, tutte con 1 sola TMU per pipeline (a differenze delle GF4 e Radeon 8500 che hanno un'architetture con 2 TMU per pipeline).


A differenza del test precedente, il 3DMark2001 utilizza, come unità di misura, il textel-rate, e non il pixel fill-rate. Infatti, se nel test precedente il pixel fill-rate dimunuiva all'aumentare della complessità (come da norma), nel test del 3DMark il risultato aumenta. Questo perchè il 3DMark _non_ misura il numero di pixel disegnati, ma il numero di sample di texture applicati ai vari pixel ogni secondo. Inoltre, a differenza del test precedente, questo benchmark è molto influenzato dalla bandwidth della memoria video. Nella situazioni di single-texture, dove la banda richiesta per textel applicato è la maggiore, la GF4 fa valere il suo migliore controller di memoria (4x32 bit, crossbar) contro quello meno evoluto della R8500 (2x64 bit, non so se crossbar anch'esso). In multi-texture, dove entrambe le schede possono applicare più textel senza dover ricorrere al multi-pass, le R8500 ricupera parecchio terreno, assestandosi vicino ai suoi limiti teorici (così come la GF4 ti 4600, del resto). Da notare che in questo test la R8500 dovrebbe avere un certo vantaggio, per lo meno teorico, dato che può applicare fino a 6 texture senza ricorrere al multi-pass, mentre la GF4 si ferma a 4 (questo è dovuto a come il 3DMark2001 esegue il test di multi-texturing).
In questo caso i driver si comportano indicativamente tutti allo stesso modo; anche l'abilitazione dell'early Z culling non apporta modifiche.

Ed ora gli altri test del 3DMark2001 SE...

Non lasciatevi ingannare della forte perdita subita dai nuovi driver nel test Nature: le maggiori prestazioni dei vecchi driver sono infatti dovute a "ottimizzazioni" alquanto discutibili, come mostrato da Unwinder (il creatore di Rivatuner). I nuovi driver, semplicemente, hanno rimosso queste "ottimizzazioni" (notare la virgolette! ;)).
Detto questo, vediamo come in questo test la GF4 sia notevolmente più veloce della R8500, nonostante quest'ultima dovrebbe avere prestazioni nel calcolo dei pixel shader più elvato.
Al variare dei driver ci sono alcune variazioni; in genere però queste sono limitate. Fa eccezione il test "advance pixel shader", dove la Radeon 8500, che in questo test usa i pixel shader 1.4, è penalizzata in una certa misura dai Catalyst 6.5 (in accordo con quanto indicato dal Fillarate tester). Da notare, invece, come l'abilitazione dell'early Z culling dia un bel boost alla GF4 nei test relativi al bump mapping.
Tra le 2 schede, la GF4 esce nettamente come vincitrice.

Infine, ecco lo score del 3DMark2001 SE...

Una cosa che mi ha stupito è vedere come la R8500 contenga le perdite passando ai nuovi driver (ricordate che il test nature, più lento sui nuovi driver, influenze pesantemente il risultato finale). Ciò indica che ci è stato in miglioramento netto negli altri game test (di cui però non ho conservato i risultati). Al contrario, la GF4 subisce un calo molto più marcato; nonostante questo però resta (ovviamente) più veloce.

Passiamo ai test sui giochi. Per prima analizziamo i giochi OpenGL...

La GF4 è decisamente più veloce della R8500, in particolare in Quake 4 (dove la 8500, tra l'altro, visualizza colori sballati e tende a bloccarsi). Anche negli altri test la differenza è notevole però, con gli ultimi Detonator, si affina in modo sensibile. Infatti, i nuovi driver causano alla GF4 una perdita netta in Q2 e una diminuizione, seppur più contenuta, anche in Quake 3 e in Serious Sam SE; gli ultimi Detonator causano inolte, con quest'ultimo gioco, moltissimi artefatti. Le ottimizzazioni relative allo Z culling non apportano variazioni significative. Entrambi i set di driver della 8500 mostrano invece prestazioni comparabili.
Da segnalare anche come solo i driver più recenti riescano a far girare Quake 4; in ogni caso, sulla 8500, come indicato sopra, il gioco si vede con colori sballati e il diventa instabile.

Ora è il turno dei giochi Direct 3D...

Iniziamo subito col dire che in questi test ho incotrato più problemi.
Infatti, dal lato della GF4, si vede chiaramente dai grafici che sia i driver 43.45 che i 91.31 hanno avuto problemi con Forsaken e Battlefield 2. Cursioso che i due set di driver abbiano avuto problemi con gli stessi applicativi...
I Catalyst si sono comportati decisamente meglio: anche se i 4.2 non hanno fatto girare né FarCry né Battlefield 2, i 6.5 non hanno avuto problemi di sorta, mostrando anche qualche significativo incremente prestazionale. Inoltre sono stati gli unici a far girare Battlefield 2.
Parlando delle performance, vediamo come i driver 43.45 si rivelino spesso più veloci degli ultimi WHQL; inoltre, in FarCry finalmente vediamo qualche beneficio tangibile dell'early Z culling.
Riguardo ai Catalyst, i 6.5 in genere si sono mostrati più veloci dei 4.2, in un caso addirittura in modo netto. Da notare che, in CoD 2, l'apparente peggiore performance di questo set di driver rispetto a quello più vecchio è da attribuire a una diversa impostazione delle texture, regolate automaticamente dal gioco in base alla memoria video. Il vecchio set di driver, infatti, riporta al gioco che la scheda ha 64MB di RAM video (corretto), mentre i Catalyst 6.5 riportano che la scheda ha 128MB di RAM video. Sinceramente non so se sia un bug o no, ma credo che sia una cosa voluta. In ogni caso, vedendo 128MB di RAM video, il gioco imposta le texture in modo che siano più dettagliate e questo, probabilmente, causa l'utilizzo della memoria AGP (che degrada le prestazioni). I risultati dei Catalyst 4.2, invece, sono relativi all'utilizzo di texture per un massimo di 64MB di RAM e quindi non sono direttamente comparabili a quelli della GF4, che utilizza le texture per 128MB (che ha interamente on-board).

Alla fine di queste prove, ci tengo a dire 2 cose:
-) da un lato sono sorpreso di vedere come schede ormai vecchie (il tempo passa... sono schede di 4-5 anni fa ormai) riescano a far girare in modo dignitoso diversi titoli appartenti al passato prossimo (FarCry, CoD 2, BattleField 2, Halo e, per la Ti4600, anche Quake 4).
-) dall'altro sono deluso dagli ultimi driver per GF4: in alcuni casi perdono parecchie performance rispetto ai vetusti 43.45 e la cosa pare non dipendere dall'impossibilità di riabilitare lo Z culling (funzione comunque disabilitata di default anche nei 43.45). In confronto, i Catalyst 6.5 hanno per lo meno garantito di mantenere le stesse prestazioni, con addirittura alcuni piccoli miglioramenti rispetto ai 4.2 (che all'epoca furono riconosciuti da tutti come una grande release). L'unico significativo peggioramento lo si ha nel calcolo dei pixel shader 1.4, comunque non usatissimi nei giochi (putroppo).

E' comuque importante ribadire che la GF4 rimane comunque più veloce, e in modo netto. Sarebbe però a questo punto interessante un confronto fra una R8500 con 128MB di RAM (cosa che ne migliora le prestazioni, dato che viene abilitato il memory interleave) e una GF4 Ti 4200 sempre con 128 MB di RAM. Credo che, utilizzando gli ultimi driver e le impostazioni di default delle 2 schede (soprattuto a livello di clock), il confronto sarebbe molto più serrato oggi che non di ieri (o, per meglio dire, di quanto avvenuto nel 2002).

A voi altre osservazioni / conclusioni...

Ciao. :)

walter sampei 23-08-2006 10:27

ottimo lavoro!!! :) sinceramente con la mia ti4800se portata a frequenze della ti 4800 normale mi trovo bene (solo che come driver ho i vecchi omega :read: )

conan_75 23-08-2006 10:44

Grandissimo!!!!!! :eek: :eek: :eek:
Il test che aspettavo da anni.

Finalmente scopriamo che:

1)La 8500 non è diventata più veloce della 4600 con l'aggiornamento dei driver (vi ricordate le menate dei fanboy sui fantomatici driver che ne avrebbero liberato tutta la potenza :rolleyes: ).
2)I 43.45, come ho SEMPRE detto, sono il set di driver più veloci per la 4x00.
Avevo fatto dei test all'epoca confermando questa teoria.
In Painkiller e FarCry ricordavo differenze marcate.

Simon82 23-08-2006 10:56

Ottimo lavoro! :)

Davvero due ottime schede considerando l'eta' risalente al 2002. Entrambe hanno segnato un periodo in cui ATI e Nvidia erano in gara ben piu' accesa di quelle che vediamo ora e in cui i benchmark venivano presi fin troppo alla lettera.

shodan 23-08-2006 11:38

Quote:

Originariamente inviato da conan_75
Hai toccato un punto molto interessante: sarà un caso, ma i flop più eclatanti sono proprio state le soluzioni 2D/3D combinate: Voodoo rush erano praticamente due schede video appiccicate con addirittura Vram separate (2Mb 2D - 4Mb 3D), scheda notoriamente buggata e prestazionalmente (inspiegabilmente) mai al livello della V1 nonostante in teoria integrasse proprio una V1.

Si, il rush è stato un fallimento.
Un po' per meriti altrui (dato che lo accoppiavano spessissimo agli Alliance AT25 o AT3D che come velocità/qualità 2D erano pessimi), ma molto per demeriti propri. Come ha già sottolineato era più lento del Voodoo1, immagino a causa di clock inferiori; nel rendering in finestra le sue performance calavano ulteriormente a causa della memoria framebuffer condivisa con il chip 2D (ricordo che la memoria aggiuntiva dedicata al rush serviva esclusivamente allo stoccaggio delle texture). Un punto a favore del rush fu, però, quello di avere il setup dei triangoli direttamente in hardware (a contrario del Voodoo1).
Quote:

La Banshee era riuscita benino, ma anche questa in 3D non era eccelsa, anzi mi pare avesse le prestazioni di una V2 uscita decisamente prima sul mercato... con la TNT2 proprio non reggeva il confronto.
Vero anche questo, ma non doveva scontrarsi con il TNT2, bensì con il TNT. Per carità, era più lenta anche di questa, ma in modo non eccessivamente marcato; nei giochi in single-texture (la maggioranza, all'epoca) era più veloce di una Voodoo2 e, solo a volte e grazie ai driver più ottimizzati, anche alla TNT. Inoltre la qualità 3D delle immagini che generava (escludendo i comunque significativi 32bit del TNT), era a mio avviso superiore a quella del chip di Nvidia (soprattutto il filtraggio trilineare). Insomma, personalmente credo che abbia fatto il suo dovere (anche tenendo conto dei tanti giochi GLIde che c'erano all'epoca), anche se sicuramente si poteva fare di più.
Quote:

La V3 2000 integrava il primo 2D valido di 3DFX, però in 3D era scarsetta, all'incirca andava come due V2 SLI, però queste ultime erano uscite decisamente da tempo sul mercato ed erano ormai sorpassate.
Be', il motore 2D delle Voodoo3 era lo stesso della Voodoo Banshee (con clock maggiorati). In altre parole, sia la Voodoo Banshee che la Voodoo3 avevano un ottimo motore 2D, con la piena accellerazione delle librerie GDI/GDI+. A livello prestazionale giudico il motore 3D ottimo, soprattutto considerando che non era un'architettura 2x1 ma 1x2. Nulla da dire però sul fatto che il feature set fosse ormai vecchiotto, mentre la TNT2 (specie nella versione Ultra) univa grande velocità alla nuove feature in voga nel periodo.
Quote:

La V4 praticamente è stato il più grosso flop dopo la Rush: nella sua fascia di prezzo non aveva senso di esistere.
La V5 era valida, ma uscita troppo tardi.
D'accordissimo su entrambi i punti.

Ciao. :)


Tutti gli orari sono GMT +1. Ora sono le: 06:31.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
Hardware Upgrade S.r.l.