Aggiungerei che del materiale si trova nel sito 3dfx di Flaconfly, ma ad occhio mancano i sorgenti D3D, mentre l'OpenGl sembra vecchiotto. Riguardo i Glide si trovano i recenti.
Se può essere utile, c'è la versione disassemblata dell'ultimo ICD OpenGL.
Purtroppo se non ricordo male di sorgenti c'era poco e niente... io posso cercare se trovo qualcosa nei miei archivi. Ti aggiorno.

EDIT: penso di avere trovato TUTTO.
Ho i sorgenti D3D, OGL, GLIDE, forse anche di più!
Quanto leggerai sentiamoci, anche privatamente!

Un saluto.

Dopo 17 anni dall'ultimo post...
Avrò a breve la possibilità di testare la Voodoo5 6000 agp versione russa su sistema Conroe, quindi cpu molto più potente dell'Athlon.
Vediamo un po'! Aggiornerò il post!

A bazzicare poco qui mi aggiungo anche io! Ma leggendo questa notizia beh... tanta roba!
Posso essere d'aiuto?? 

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.

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!

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.

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??? 

#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;
}

Allora ecco altre chicche.

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



Questa è la massima qualità raggiungibile con i driver standar



Questa con i Mikepedo 1.0 hihi

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?



EDIT: dimenticavo: Aquanox a 800x600, 32 bit e FSAA 2X su una Voodoo5 agp.

Sono fuori dal giro 3dfx da un pezzetto ormai... Ma continuo a seguire sempre le evoluzioni...
Sono collegato insomma