Hvordan vælger jeg de bedste OpenGL® -projekter?

Uanset om det er med henblik på arbejde, uddannelse, generel udvikling eller bare nysgerrighed, er der et par retningslinjer, der kan følges for at hjælpe med at vælge de bedste OpenGL® -projekter. Generelt skal projektet have krav, der er inden for området færdigheder for den programmør eller team, der vil arbejde på det. Derudover bør projektkonceptet være klart, og resultaterne er veldefinerede for at undgå unødvendigt kodning, der kan betragtes som unødvendigt. De specifikke hardwarekrav skal også staves, fordi den nøjagtige type OpenGL® -programmering undertiden kan dikteres af målhardwaren. Projektet bør også involvere et afsnit af OpenGL®, der er interessant for programmereren, især når man beskæftiger sig med projekter, der stort set er akademiske. Simple OpenGL®-projekter, såsom at udvikle en to-Dimensionelt (2D) vinduesystem kan være fremragende øvelser i funktionel udvikling, mens andre projekter, såsom at skabe en fysikbaseret renderer, kan kræve et meget specialiseret niveau af teknisk og matematisk detalje. Projektets detaljer skal undersøges, før det tages op for at sikre, at der ikke er et enkelt element, der kan blive en stødestok, når det skrider frem.

Den faktiske del af OpenGL®, som projektet også kan være vigtige med. Nogle dele af OpenGL®, såsom Shaders, er meget involverede og kræver undertiden et helt separat sæt færdigheder til at mestre. Programmerere, der ikke er interesseret i eller erfarne inden for OpenGL® -programmering, som projektopkald måske ønsker at undgå projektet helt.

For OpenGL® -projekter, der er målrettet mod specifikke hardwareplatforme, er det vigtigt at vide nøjagtigt, hvad hardwareer, og hvordan de applikationer, der skrives, kan testes på dem. Hvis hardware endnu ikke har nået forbrugermarkedet, kan projektet ikke testes effektivt, før enten en prøve af hardware stilles til rådighed, eller en softwareemulator leveres. Oftere end ikke er en emulator til hardware tilstrækkelig.

Når man beskæftiger sig med OpenGL® -projekter, der vil blive brugt til kommercielle formål, er kontrakter og andre betingelser normalt lagt i starten af ​​projektet. Dette er måske ikke altid tilfældet for samfundsudviklede projekter og akademiske projekter. Hvis der er en mulighed for, at softwaren eller kildekoden til projektet vil blive distribueret i en eller anden form, er det vigtigt at etablere den nøjagtige kontekst, hvor programmererne passer ind i projektet, så der ikke er nogen juridiske eller andre misforståelser i fremtiden.