In evidenza per te:

Non cerchi le solite news sulla tecnologia? Allora benvenuto su Forumzone! :ok:

Menu principale
Menu

Mostra messaggi

Questa sezione ti permette di visualizzare tutti i messaggi inviati da questo utente. Nota: puoi vedere solo i messaggi inviati nelle aree dove hai l'accesso.

Mostra messaggi Menu

Messaggi - mikepedo

#1
Grazie! Ma si tratta di un concetto che poi andrebbe applicato da chi realmente conosce la programmazione e l'hw 3D.
Non saprei, questa idea di lavorare sulla geometria ce l'ho da anni, ma chiaramente servirebbe qualcuno che abbia realmente la capacità di fare un tentativo.
Di fatto una scheda 3dfx la puoi vedere come un renderizzatore che elabora qualsiasi cosa gli viene inviata, perchè non ha complessi sistemi per ridurre l'overdraw. Lo scopo è inviarle soltanto quello che è realmente visibile e necessario.
#2
Aggiungo: questo algoritmo potrebbe anche essere migliorato, effettuando un "cutting" dei triangoli parzialmente visibili, così da inviare solo la parte visibile di esso... e per fare questo si potrebbe ragionare su una tecnica a tiles applicata alla geometria... ma un passo alla volta! Se qualcuno avesse la capacità ed il tempo di provarci...
Sta di fatto che sarebbe un bel beneficio per chi ha installato una 3dfx in un sistema potente: sfruttare questa potenza per alleggerire la vecchietta!
#3
Citazione di: Glide il 21 Giugno 2023, 20:13:36Ciao mikepedo,

è sempre un piacere rileggere un tuo thread :). L'idea è interessante, se ho compreso bene il tuo fine: utilizzare i sistemi assemblati ad hoc per utilizzare oggi schede 3dfx e, nello stesso tempo, dotati di CPU performanti (Athlon o Core), spostando su queste ultime il carico di lavoro legato a funzionalità grafiche che i chip 3dfx non supportano. Questo vuol dire ampliare il bacino dei giochi supportati...

Ciao ciao

Piacere mio! In realtà lo scopo non è aumentare il bacino dei giochi supportati, ma aumentare le prestazioni in-game, allo scopo di permettere una buona giocabilità anche dei giochi più recenti, ma già "compatibili" diciamo.
Sostanzialmente l'algoritmo dovrebbe permettere di inviare alla scheda video soltanto i triangoli visibili (e per semplicità, anche i parzialmente visibili) scartando quelli totalmente nascosti. Non è una tecnica TBR per interderci come aveva PowerVR, che di fatto lavorava nella fase di rendering: questo è un codice che lavora nella fase geometrica e quindi totalmente software, dal momento che le schede 3dfx non supportato il T&L in hw.

I vantaggi sono molteplici:
-minor numeri di triangoli inviati alla scheda video, quindi minor banda passante necessaria (ne giovano soprattutto le schede PCI33)
-risparmio di fill rate (meno triangoli da renderizzare)
-risparmio di bandwidth (minor scritture del frame buffer)

La cosa bella di questo approccio è che le modifiche lato driver interessano solo la gestione geometrica della scena, mentre tutto quello che viene a valle può restare così com'è.
Ora, sulla fattibilità dell'idea alzo le mani, servirebbe qualcuno che abbia idea di come implementarlo.
#4
Ciao a tutti, oggi mi sono un pò divertito a chiedere a chatGPT di scrivermi un codice di HSR software, gestito dalla cpu. In buona sostanza, gli ho chiesto una cosa semplice, ovvero che la cpu, durante la fase di trasform, clipping and lighting, determini quali siano i triangoli visibili e quali quelli nascosti, tenendo presente che alcuni di essi possano essere trasparenti. Inoltre, per non creare troppa attesa alla scheda video (altrimenti solo al termine di tutti i test avrebbe inviato i soli triangoli visibili alla scheda), gli ho detto che ogni qualvolta un triangolo risulta visibile dal test di profondità lo deve anche immediatamente inviare alla scheda video, mentre solo quelli sicuramente nascosti li dovrà scartare. Chiaramente è un metodo semplice che non azzera l'overdraw, ma penso possa venire incontro alle cpu meno potenti, e inoltre, se non ricordo male, i giochi venivano programmati con delle tecniche front to back, ovvero iniziare l'elaborazione geometrica dai triangoli più prossimi al soggetto: così si avrebbero alte probabilità di inviare alla scheda video i soli triangoli realmente visibili...
Si tratta pertanto di una tecnica di HSR applicata ai triangoli, senza andare a lavorare sui singoli pixel. Tradotto: soltanto i triangoli completamente nascosti vengono scartati, mentre se anche un solo pixel di un triangolo sarà visibile, l'intero triangolo sarà elaborato.
In ogni caso, ecco il risultato! Qualcuno che abbia voglia di ragionarci su???  :o

#include <iostream>
#include <vector>

struct Triangle {
    float x1, y1, z1; // Coordinate del primo vertice
    float x2, y2, z2; // Coordinate del secondo vertice
    float x3, y3, z3; // Coordinate del terzo vertice
    float transparency; // Trasparenza del triangolo (0.0 - 1.0)
};

// Dimensioni del frame buffer
const int framebufferWidth = 800;
const int framebufferHeight = 600;

// Buffer di profondità
float depthBuffer[framebufferWidth][framebufferHeight];

// Funzione per il calcolo dell'area di un triangolo
float CalculateTriangleArea(float x1, float y1, float x2, float y2, float x3, float y3) {
    return std::abs((x1*(y2-y3) + x2*(y3-y1) + x3*(y1-y2)) / 2);
}

// Funzione per determinare la visibilità di un triangolo e inviarlo immediatamente alla scheda video se visibile
bool CheckAndRenderTriangle(const Triangle& triangle) {
    // Calcolo dell'area del triangolo
    float area = CalculateTriangleArea(triangle.x1, triangle.y1, triangle.x2, triangle.y2, triangle.x3, triangle.y3);
   
    // Iterazione sui pixel all'interno del bounding box del triangolo
    int minX = std::min({triangle.x1, triangle.x2, triangle.x3});
    int maxX = std::max({triangle.x1, triangle.x2, triangle.x3});
    int minY = std::min({triangle.y1, triangle.y2, triangle.y3});
    int maxY = std::max({triangle.y1, triangle.y2, triangle.y3});
   
    bool visibleTriangleFound = false; // Flag per indicare se è stato trovato un triangolo visibile
   
    for (int y = minY; y <= maxY; y++) {
        for (int x = minX; x <= maxX; x++) {
            // Calcolo delle coordinate baricentriche del punto
            float alpha = CalculateTriangleArea(x, y, triangle.x2, triangle.y2, triangle.x3, triangle.y3) / area;
            float beta = CalculateTriangleArea(triangle.x1, triangle.y1, x, y, triangle.x3, triangle.y3) / area;
            float gamma = CalculateTriangleArea(triangle.x1, triangle.y1, triangle.x2, triangle.y2, x, y) / area;
           
            // Verifica se il punto è all'interno del triangolo
            if (alpha >= 0 && beta >= 0 && gamma >= 0) {
                // Calcolo del valore Z interpolato
                float interpolatedZ = alpha * triangle.z1 + beta * triangle.z2 + gamma * triangle.z3;
               
                // Verifica la visibilità del punto tramite il buffer di profondità
                if (interpolatedZ < depthBuffer
  • [y]) {
                    depthBuffer
  • [y] = interpolatedZ;
                   
                    // Invio del triangolo alla scheda video per il rendering
                    // ...
                   
                    visibleTriangleFound = true; // Indica che è stato trovato un triangolo visibile
                   
                    // Esci dalla funzione, inviando solo il primo triangolo visibile
                    return true;
                }
            }
        }
    }
   
    return visibleTriangleFound; // Restituisce true se è stato trovato almeno un triangolo visibile
}

int main() {
    // Inizializzazione del buffer di profondità
    for (int y = 0; y < framebufferHeight; y++) {
        for (int x = 0; x < framebufferWidth; x++) {
            depthBuffer
  • [y] = std::numeric_limits<float>::max(); // Valore iniziale massimo
        }
    }
   
    // Esempio di utilizzo
    std::vector<Triangle> triangles; // Vettore dei triangoli della scena
   
    // Aggiungi i triangoli della scena al vettore 'triangles'
    // ...
   
    // Itera sui triangoli e invia i triangoli visibili alla scheda video
    for (const Triangle& triangle : triangles) {
        if (CheckAndRenderTriangle(triangle)) {
            // Se è stato trovato un triangolo visibile, passa al triangolo successivo
            continue;
        }
       
        // Se nessun triangolo visibile è stato trovato, determina i restanti triangoli
        // ...
    }
   
    return 0;
}
#5
Allora ecco altre chicche.

Questo è il demo rilasciato al lancio della Voodoo 5 per mettere in mostra il FSAA. Notare la differenza ;)

Messaggio dalla redazione:
Contenuto non disponibile in quanto rimosso da server esterno o server esterno off line


Questa è la massima qualità raggiungibile con i driver standar

Messaggio dalla redazione:
Contenuto non disponibile in quanto rimosso da server esterno o server esterno off line


Questa con i Mikepedo 1.0 hihi

Messaggio dalla redazione:
Contenuto non disponibile in quanto rimosso da server esterno o server esterno off line
#6
Questo post mi ha fatto ripensare ad un vecchio indirizzo ftp che non utilizzo da un sacco di tempo.
Lo utilizzavo per appoggiarci le più svariate cose, sia ludiche che di lavoro.
Ma soprattutto ho ritrovato diversi screenshoots di una mia Voodoo5 agp che utilizzavo all'epoca per provare i miei driver Mikepedo! Ve li ricordate? Ahahah!
Beh, leggendo vari datasheet avevo scoperto che era possibile aumentare drasticamente la qualità delle texture tramite lod bias, cosa che l'hw Voodoo gestiva in maniera egregia.

Credo che l'immagine parli da sola... All'epoca mi cadde la mascella! Parliamo di quanto??? 10 anni fa? :okduo:

Messaggio dalla redazione:
Contenuto non disponibile in quanto rimosso da server esterno o server esterno off line


EDIT: dimenticavo: Aquanox a 800x600, 32 bit e FSAA 2X su una Voodoo5 agp.
#7
Sono fuori dal giro 3dfx da un pezzetto ormai... Ma continuo a seguire sempre le evoluzioni...
Sono collegato insomma :okduo:
#8
Citazione di: Max_R;177292Sempre che non ci fossero features (o addirittura api) specifiche, vedi environmental bumpmapping matrox. Sono d'accordo quindi con il tuo discorso per quanto riguarda il 2D ma solo in parte per il 3D!

Forse non mi sono spiegato bene. Il mio discorso serviva per dire che quando noi facciamo uno screenshot, quello che poi diventa un file bitmap, jpg ecc... non è quello che realmente vediamo a schermo, ma quello che sta nel frame buffer, quindi compreso di tutte le features del chip video, tranne delle caratteristiche del DAC di convertire l'immagine!
Ecco che se quel file lo visioniamo con una identica scheda video va bene, ma se io metto uno screenshot qui sul forum della mia Voodoo3, e te poi te lo guardi con una TNT2, ecco che non è la stessa cosa! Compreso? Anche il DAC fa, anzi faceva, la differenza!
#9
Volevo puntualizzare una cosa: in passato, quando esistevano solo i monitor vga e le schede di conseguenza avevano il DAC, per valutare con efficacia la qualità dell'immagine non era corretto fare uno screenshot, perchè in questo modo si salvava su file solo il frame buffer (quindi immagine in digitale) bypassando proprio il DAC della scheda video.
Di conseguenza, salvare uno screenshot di una Matrox e visionarlo con una Nvidia non rendeva di certo giustizia alla casa canadese, viceversa, beh, si faceva un bel regalo ai californiani!!!
#10
Avevo deciso di farmi un pc con la 5500, e così cercando dei driver mi sono imbattuto qui...
Di certo è stato il sito più entusiastante che mi sia mai capitato di trovare, dove c'era veramente tanta gente appassionata per 3dfx. Non a caso è diventato una risorsa importantissima anche fuori Italia :okduo: