Leadtek GeForce4 Ti4600

[Raven]

Originariamente inviato da teolinux
[b]

• primo punto
• secondo punto

ehmmmm...

[Eraser|85]

Originariamente inviato da teolinux
[b]

• primo punto
• secondo punto

OT

• Primo, bello.
• Secondo, utile
• Terzo, Grazie, non lo avevo mai provato

[(IH)Patriota]

Originariamente inviato da topinoz
[b]Hai ragione: sono stato troppo "vago" con il giudizio. "Ci gioco benissimo" per me vuol dire che ha finito MOHAA e durante tutte le missioni non ho riscontrato nulla che mi facesse pensare alla frase "ca**o ho buttato via 50 euro" oppure "questi programmatori potevano vendere patate invece di fare videogiochi", ovviamente x quanto riguarda la tecnica e la grafica. Siamo di fronte ad una "customer satisfaction" ... Gli aspetti tecnici e numerici per me contano poco (FPS, risoluzione ecc. ecc.), sono troppo dipendenti dall'HW, é chiaro che (IH)Patriota ha qualche problema poiché io a 800x600 con i settaggi praticamente tutti a palla non ho avuto il benché minimo problema e drop di FPS. A 1024x768 invece iniziava ad essere scattoso nei livelli (splendidi) dei boschi innevati, ma ragazzi parlo di una MX400, non di una GF3Ti! Tanto x completare ho un 15" (ecco xé a 800x600), DDR 256Mb e un Athlon XP1600+, il tutto messo insieme da una gigabyte VTXH+. Tutto ovviamente senza overclock. Sara' xé io sono stato abituato ai giochi degli anni '80 ma io francamente non capisco come mai si debba giudicare cosi' male un gioco che va a 18fps, soprattutto in scene molto complesse. Onestamente se il gioco mi va' a 20 fps costanti non ci sputo sopra, quello che mi fa' arrabbiare sono i _drop_ di fps, quelli si sono fastidiosi! Guardate FS2002, hanno pure messo il limitatore di FPS, cosi' da non disturbare in caso di forti variazioni dello stesso .

NOn credo proprio di avere "problemi" al mio hardware visto che i bench in 3Dmark sono in linea con chi ha configurazioni simili alla mia (89003D Mark , default settings 1024x768)
Se le tue valutazioni fossero un filo piu' oggettive e non soggettive potremmo tentare di fare un confronto. Giocare a 800x600 o a 1024x768 è molto diffrente , non usare l' AntiAliasing o usarlo a 4x fa molta differenza , ho capito che per te gli aspetti tecnici e numerici "contano poco" , ma purtroppo per confrontarsi è necessario usare criteri oggettivi e non soggettivi , come ho gia' scritto sopra.

Io non giudico male un gioco che fa 18 Fps , ho solamente detto che Mohaa sfrutta l' Hw in modo molto aggressivo impegnando molte risorse Hw per girare adeguatamente.

E per adeguatamente non intendo certo 20 fps che non saranno MAI costanti ma avranno sbalzi notevoli (motivo per cui vengono implementati i limitatori di FPS che diminuiscono il delta tra max e min Fps diminuendo l' affetto freeze fps .Tra l' altro anche Mohaa e' limitato a circa 100Fps)

Per concludere , come ho gia' scritto nel mio precedente post , se ti senti gratificato a giocare ad 800x600 senza AA ecc. ecc.. non intendo certo farti cambiare idea , se vuoi confrontare dei dati numerici e discutere su quelli ok , se devo ancora leggere che per te un gioco che fa 10fps (che ancora non so come hai misurato) gira "benissimo" chiudo la trasmissione perche' ho il forte sentore che non ci capiremo mai e sarebbe inutile flame stare qui a discuterne.

[cdimauro]

Originariamente inviato da topinoz
[b]>>1) Non hai mai programmato in assembly a certi livelli
>>2) Non sai come funziona un compilatore e come ottimizza il codice

No comment

>>Un essere umano è in grado di ottimizzare il codice MOLTO, ma MOLTO meglio di qualunque compilatore esistente.

[b]

Parole tue.

Infatti sono proprio le mie...

[b]

Ti sfido a creare un eseguibile a mano da parecchie migliaia di linee di C++ e farcelo stare in 512k e con la stessa velocita' di esecuzione.

Con l'Amiga facevo anche di meglio: ho scritto decine di migliaia di linee di codice direttamente in assembly per i giochi che stavo sviluppando, le altre applicazioni di supporto, ed ero in procinto di terminare un emulatore 80186 (questo era il progetto più grosso in assoluto)... Se t'interessano i numeri, posso andare a rispolverare tutto quel materiale e conteggiare le linee e le dimensioni dei sorgenti...

[b]

Lascia perdere, andresti in pensione senza neanche aver visto partire una task.

Infatti sarebbe da pazzi! Se devo tradurre un sorgente C++ tutto in assembly, tanto vale crearlo partendo direttamente da questo linguaggio: cambia anche l'approccio alla stesura del codice e il modo in cui si affrontano e risolvono certi problemi. Avresti sicuramente meno grattacapi e perderesti meno tempo...

In ogni caso lo spazio occupato sarebbe sicuramente minore e la velocità maggiore...

[b]

Quello che l'uomo puo' ottimizzare sono piccole routine o ISR.

Esattamente: il 90% del tempo impiegato da un'applicazione risiede in meno del 10% del codice...

E' per questo che ormai si tende a scrivere tutte le applicazioni in un linguaggio ad alto livello, e una volta che tutto funziona si provvede, eventualmente riscrivendo solamente le parti in critiche in assembly.

Ormai l'imperativo è di sviluppare applicazioni funzionanti nel minor tempo possibile...

[b]

Non a caso SSE2/3Dnow sono nate per diminuire il tempo di esecuzione delle funzioni piu' frequenti e quindi piccole.

Hum. Piuttosto sono nate dall'esigenza di poter sviluppare del codice che trattasse in maniera veloce e omogenea grandi quantità di dati. Se il motivo fosse stato semplicemente quello che hai descritto, sarebbe bastato l'aggiunta di qualche altra unità di elaborazione intera e floating point. E' l'approccio al problema che s'è voluto cambiare e risolvere in maniera più elegante, pratica, economica e performante...

[b]

PS: anche io pensavo come te che l'uomo con il linguaggio macchina poteva scrivere il SW perfetto,

Con il linguaggio macchina sicuramente sarebbe più difficile che con qualunque altro...

Tra l'altro non è certamente il linguaggio impiegato che può permettere di creare il software "perfetto" (che di per sé, per definizione, non può esistere): uno vale l'altro. Con ogni linguaggio puoi fare quello che fai con un altro linguaggio, e viceversa...

Comunque ho capito cosa volevi intendere...

[b]

ma mi sono dovuto ricredere perchè questo dipende dalla complessita' e dalle dimensioni del prodotto che vuoi creare

Esattamente. D'altra parte l'analisi del problema e la scelta delle risorse/strumenti ottimali per la sua soluzione non è cosa di poco conto nell'ambito di progetti di una certa levatura...

[b]

e penso che fare un "giochino" non sia uno scherzo...

D'accordo. Ma sarà per il fatto che provengo dai tempi del Vic 20, per me non sarebbe un problema usare interamente l'assembly per creare un'applicazione o un gioco. Con l'Amiga, come ho già detto, ci stavo lavorando e sta sicuro che né ora né mai mi sarei potuto permettere di utilizzare un linguaggio ad alto livello per arrivare allo scopo, perché le performance sarebbero calate paurosamente (e la memoria disponibile non sarebbe bastata per farci stare tutto)...

Oggi, come ho già detto, i tempi sono diversi: Zio Bill ci ha insegnato che bisogna tirare fuori il codice funzionante. Alla velocità penseranno i computer moderni, che sono ogni giorno sempre più veloci...

[cdimauro]

Originariamente inviato da Lifeisoutside
[b]
ehm, solo una precisazione, lui parlava di assembler, non di linguaggio macchina, che non è la stessa cosa... (100011001010000 vs add A, B) cmq i compilatori ottimizzano per bene, ma non penso siano perfetti, così come non è perfetta una persona, certo che però fare giochi in assembler vai via di testa (e in lm non esiste proprio )

Assembly <> assembler.

Assembly = linguaggio (sintassi e semantica).

Assembler = compilatore (di un sorgente scritto in linguaggio assembly)

I compilatori oggi fanno un buon lavoro. Ma ripeto: quello che riesce a tirare fuori un essere umano quanto ad ottimizzazioni non è paragonabile.

Per i giochi, beh, sì: si può andare fuori di testa a scriverli interamente in assembly. Ma fino a qualche anno fa era la norma...

[cdimauro]

Originariamente inviato da topinoz
[b]Si, ma da quello che mi ricordo:
assembler : tool x sviluppo programmi in linguaggio macchina

In questa definizione però rientrano praticamente tutti i compilatori...

[b]

assembly (language): il linguaggio usato per scrivere prg

Esattamente.

[b]

linguaggio macchina: traduzione per noi italiani di "assembly language"

No: sono due cose diverse, due linguaggi diversi...

[b]

100101010111 : linguaggio binario

Se utilizzo una sfilza di numeri simile a questa, sto scrivendo un programma in linguaggio macchina

[b]

ADD A,B ecc.ecc.: sono istruzioni

Così, invece, lo scrivo in linguaggio assembly...

[b]

Molte volte si scambia assembler per assembly, ma ci si capisce lo stesso

Purtroppo è così, ma mi dà parecchio fastidio perché sono due cose nettamente diverse.

[b]

Per cui linguaggio macchina è ok

Mi oppongo!

[Lifeisoutside]

Originariamente inviato da cdimauro
[b]

Assembly <> assembler.

Assembly = linguaggio (sintassi e semantica).

Assembler = compilatore (di un sorgente scritto in linguaggio assembly)

I compilatori oggi fanno un buon lavoro. Ma ripeto: quello che riesce a tirare fuori un essere umano quanto ad ottimizzazioni non è paragonabile.

Per i giochi, beh, sì: si può andare fuori di testa a scriverli interamente in assembly. Ma fino a qualche anno fa era la norma...

Eh, avevo capito, è giusto anche quello che ho scritto io, il nostro libro di testo di arch degli elab parla di assembler (sottointendendo linguaggio) e di assemblatore per il compilatore, lo stesso hanno fatto il nostro prof di teoria e quello di laboratorio, che lavora al mit, io non mi sento di contraddirli e uso i loro termini, cmq capisco anche assembly per linguaggio e assembler per compilatore (che secondo me in inglese si capisce meglio così )
si vabbè ma se guardi i giochi fatti prima del 1983 credo, poi con l'ansi c dovrebbero essere diminuiti quelli in assembler, penso, boh, di sicuro "Spacewar" non era in alto livello.
cmq non so se nelle vostre considerazioni avete tenuto conto la portabilità del gioco, vabbè non sarà imporntatissima, però se uno vuol fare un gioco per pc e mac in assembly assembler o come vuoi ti tocca farne due.

[cdimauro]

Originariamente inviato da Lifeisoutside
[b]
Eh, avevo capito, è giusto anche quello che ho scritto io, il nostro libro di testo di arch degli elab parla di assembler (sottointendendo linguaggio) e di assemblatore per il compilatore, lo stesso hanno fatto il nostro prof di teoria e quello di laboratorio, che lavora al mit, io non mi sento di contraddirli e uso i loro termini,

I professori incutono sempre un certo timore e riverenza. Io comunque in un'occasione ho corretto il mio professore di linguaggi di programmazione che aveva scambiato i due termini in un discorso...

[b]

cmq capisco anche assembly per linguaggio e assembler per compilatore (che secondo me in inglese si capisce meglio così )

Appunto.

[b]

si vabbè ma se guardi i giochi fatti prima del 1983 credo, poi con l'ansi c dovrebbero essere diminuiti quelli in assembler, penso, boh, di sicuro "Spacewar" non era in alto livello.

Considera che perfino per la Playstation (1), i giochi che sfruttano al meglio l'hardware sono stati scritti in assembly... Questo per farti un esempio, ma posso assicurarti che fino a qualche anno fa l'assembly imperava, particolarmente nei sistemi arcade e nelle console. Nei computer come l'Amiga, i giochi scritti in C rappresentano la classica mosca bianca...

[b]

cmq non so se nelle vostre considerazioni avete tenuto conto la portabilità del gioco, vabbè non sarà imporntatissima, però se uno vuol fare un gioco per pc e mac in assembly assembler o come vuoi ti tocca farne due.

Questo già è un discorso diverso. Ovviamente se l'obiettivo è di realizzare un gioco multipiattaforma, giocoforza è necessario l'utilizzo di un linguaggio ad alto livello.

Poi, ripeto, oggi si tende a sviluppare velocemente delle applicazioni funzionanti, e non si bada più alle ottimizzazioni...

Ecco perché mi si storce il naso quando leggo che le schede video attuali arrivano ad erogare una portenza di diversi teraflops: ma dove li usano? Dovremmo avere dei giochi che utilizzano il raytracing e con un dettaglio degli oggetti fenomenale...

[naitsirhC]

Discussione molto interessante e istruttiva... però:
Hardware Upgrade Forum > Hardware Upgrade > News > Leadtek GeForce4 Ti4600.

Non sarebbe male se si parlasse anche della mews in questione.
Grazie.
Statemi bene.

[naitsirhC]

News! Piiiiccolo errore di sbaglio....
Ops!

[cdimauro]

Originariamente inviato da naitsirhC
[b]Discussione molto interessante e istruttiva... però:
Hardware Upgrade Forum > Hardware Upgrade > News > Leadtek GeForce4 Ti4600.

Non sarebbe male se si parlasse anche della mews in questione.
Grazie.
Statemi bene.

In effetti siamo usciti un po' dal seminato, ma non mi pare così grave la cosa. Stavamo parlando delle performance delle schede grafiche e del fatto che non vengono sfruttate come si deve perché ormai si tende ad ottimizzare poco i giochi...

Alla fine non abbiamo proprio divagato o raccontato barzellette... Siamo sicuri che la GeForce4 Ti4600 verrà sfruttata come si deve dai giochi di prossima generazione?

E' questo che ci ha portati a parlare anche di altro...

D'altra parte è una cosa normale parlare anche di altro: le news servono spesso come spunto per parlare anche di altre cose interessanti, altrimenti i messaggi si ridurrebbero a 2 o 3...

Comunque, se dobbiamo attenerci esclusivamente all'argomento delle news è bene saperlo a priori, così ci si regola per il futuro...

Saluti anche a te