[C++] Opengl Library maken

[Verwijderd]

Hello,

Ik werk momenteel aan een reeks OpenGL functies om op een 'eenvoudige' manier OpenGL te kunnen programmeren in C++.
Kheb al een functie die een cubus tekent op een bepaald coordinaat met een bepaalde grootte, kleur en rotatie. Alsook eentje voor een eenvoudig assenstelsel.
M'n bedoeling is om een programma van max. 64kb te maken dat toch héél knappe grafix tevoorschijn tovert. (er zo'n soort wedstrijd).

Wat zouden jullie suggereren? Kortom: Wat zouden jullie graag nog vereenvoudigd zien?
Functies die ik nog ga maken:
- geometrische figuren (bol, piramide, vlakken, ...)
- fps counter

't Gene ik misschien ga proberen(afzonderlijk van m'n project):
(hierover heb ik reeds source-code en tutorials gevonden)
- inlezen van textures
- openen van models
- blending
- fog

Als SDK gebruik ik de laatste nieuwe beta van Dev-C++ 5. Die kan je vinden op de Bloodshed website: www.bloodshed.net.
Dev-C++ is bijna even krachtig (maar veel overzichtelijker) als MS Visual C++, tgrote verschil is dat Dev-C++ gratis is(en zelfs open-source).

Als jullie suggesties hebben voor het automatiseren van intro's/engine/demo's, laat me dit dan weten. Bvb: "een scene-systeem dat een soort script inleest met de verplaatsing van de object, de camera-movement, belichting, ...."

[Verwijderd]

Check de source van glut dan ook maar eens. Staan iig goede voorbeelden in voor de geometrische objecten.

Je kan ook ns Ogre checken voor goede voorbeelden van scene management enzo.

[.oisyn]

Tja, als opengl en directx programmeur is jouw lib dus totaal nutteloos voor mij. Want wat moet ik nou met bijvoorbeeld een kubus teken functie? Ook voor 64k intro's lijkt het me redelijk nutteloos, aangezien dat toch uit non-reusable code bestaat (je moet er immers alleen in stoppen wat je daadwerkelijk gebruikt, en generalizatie zorgt over het algemeen voor meer code dan code wat een specifiek probleem aanpakt)

Wat misschien wel handig is is idd een soort scripting systeem, en dan bedoel ik niet hoe iets verplaatst moet worden, maar weer op welk moment welk effect aangeroepen moet worden met welke parameters

[Verwijderd]

Tja, als opengl en directx programmeur is jouw lib dus totaal nutteloos voor mij. Want wat moet ik nou met bijvoorbeeld een kubus teken functie?

Ook voor 64k intro's lijkt het me redelijk nutteloos, aangezien dat toch uit non-reusable code bestaat (je moet er immers alleen in stoppen wat je daadwerkelijk gebruikt, en generalizatie zorgt over het algemeen voor meer code dan code wat een specifiek probleem aanpakt)
Volgens mij klopt dit niet: je source wordt toch veel kleiner als je repititieve dingen in functies zet? Natuurlijk moet de gehele scene-structuur geprogrammeerd worden, maar je gaat toch niet telkens voor elke cubus 6 vlakken tekenen? Als je op die manier dan een bol ofzo gaat tekenen, dan is dat onbegonnen werk(ik zie me nog geen bol uit vlakken opbouwen zonder een functie te maken die op de wiskundige formule van een bol is gebaseerd?! Voor wiskundige figuren gebruik je toch wel een formule, die je dan in een functie giet zodat je deze niet telkens opnieuw moet programmeren voor elk object!? Dit is een van de basis

Wat misschien wel handig is is idd een soort scripting systeem, en dan bedoel ik niet hoe iets verplaatst moet worden, maar weer op welk moment welk effect aangeroepen moet worden met welke parameters
Dat klopt ja, maar als je zegt welk effect er wordt aangeroepen, dan wordt dit effect toch gemáákt, dus dan verschijnt/verdwijnt er toch een object? Bvb: particles zijn ook objecten hee.

[Creepy]

Verwijderd schreef op 22 oktober 2002 @ 19:56:
Tja, als opengl en directx programmeur is jouw lib dus totaal nutteloos voor mij. Want wat moet ik nou met bijvoorbeeld een kubus teken functie?

Ook voor 64k intro's lijkt het me redelijk nutteloos, aangezien dat toch uit non-reusable code bestaat (je moet er immers alleen in stoppen wat je daadwerkelijk gebruikt, en generalizatie zorgt over het algemeen voor meer code dan code wat een specifiek probleem aanpakt)
Volgens mij klopt dit niet: je source wordt toch veel kleiner als je repititieve dingen in functies zet? Natuurlijk moet de gehele scene-structuur geprogrammeerd worden, maar je gaat toch niet telkens voor elke cubus 6 vlakken tekenen? Als je op die manier dan een bol ofzo gaat tekenen, dan is dat onbegonnen werk(ik zie me nog geen bol uit vlakken opbouwen zonder een functie te maken die op de wiskundige formule van een bol is gebaseerd?! Voor wiskundige figuren gebruik je toch wel een formule, die je dan in een functie giet zodat je deze niet telkens opnieuw moet programmeren voor elk object!? Dit is een van de basis

Wat misschien wel handig is is idd een soort scripting systeem, en dan bedoel ik niet hoe iets verplaatst moet worden, maar weer op welk moment welk effect aangeroepen moet worden met welke parameters
Dat klopt ja, maar als je zegt welk effect er wordt aangeroepen, dan wordt dit effect toch gemáákt, dus dan verschijnt/verdwijnt er toch een object? Bvb: particles zijn ook objecten hee.

Als ik jou lib meelink dan krijg ik HEEL je lib mee, ook als ik niet alle functies uit jou lib gebruik, terwijl ik wil dat alleen de gebruikte functies meegenomen worden. Dus schrijf ik alles opnieuw net zolang totdat ik deze functies zelf heb en ze rechtstreeks kan gebruiken zonder allerlij extra libs mee te moeten compilen.

Daarbij komt nog dat dingen zolas kubussen, bollen etc. redelijkt triviaal zijn. Ook dingen zoals textures laden etc. Iemand die een 64K intro kan coden die gebruik maakt van OpenGL zal een library hiervoor niet nodig hebben, maar zal hier zeer waarschijnlijk zelf al een source code library voor hebben waar gebruik van gemaakt wordt.

Stel: jij maakt een functie om textures te laden. (bmp, jpg, gif,tga etc.).
Stel: ik ga een 64K into maken en gebruik alleen gif textures, dan schrijf ik dus zelf een functie om een gif als texture te gebruiken omdat die gegarandeert kleiner zal zijn dan jou algemene functie.

[madwizard]

Creepy schreef op 22 oktober 2002 @ 20:20:
Als ik jou lib meelink dan krijg ik HEEL je lib mee, ook als ik niet alle functies uit jou lib gebruik, terwijl ik wil dat alleen de gebruikte functies meegenomen worden. Dus schrijf ik alles opnieuw net zolang totdat ik deze functies zelf heb en ze rechtstreeks kan gebruiken zonder allerlij extra libs mee te moeten compilen.

Een library bestaat uit 1 of meerdere object files (.obj), normaal gesproken worden alleen die object files waaruit je iets gebruikt meegelinkt. Ik geloof dat sommige compilers (VC++ met /Gy switch ?) dat zelfs op functieniveau kunnen.

[.oisyn]

Verwijderd schreef op 22 oktober 2002 @ 19:56:
Volgens mij klopt dit niet: je source wordt toch veel kleiner als je repititieve dingen in functies zet? Natuurlijk moet de gehele scene-structuur geprogrammeerd worden, maar je gaat toch niet telkens voor elke cubus 6 vlakken tekenen? Als je op die manier dan een bol ofzo gaat tekenen, dan is dat onbegonnen werk(ik zie me nog geen bol uit vlakken opbouwen zonder een functie te maken die op de wiskundige formule van een bol is gebaseerd?! Voor wiskundige figuren gebruik je toch wel een formule, die je dan in een functie giet zodat je deze niet telkens opnieuw moet programmeren voor elk object!? Dit is een van de basis

Dat is niet wat ik bedoel. Bovendien ben je imho erg stom bezig als je de vlakken (quads eigenlijk) apart gaat tekenen terwijl je beter vertex buffers kan gebruiken
Ik had het meer over algemene probleemaanpak, niet zozeer over bepaalde functies die je in hetzelfde programma vaker aanroept (dat is natuurlijk wel voordeliger)

Als je echter een lib gaat schrijven dan is dat niet voor 1 programma, maar voor meerdere programma's. Een aanpak van een bepaald probleem moet je dan generalizeren, om de lib zo bruikbaar mogelijk te maken. Dit resulteert echter ook in meer code, wat je in een 64k (of 4k ) intro al helemaal niet kunt gebruiken

Ten tweede, wat moet je met een kubus of bol generatie-functie? Kan me niet voorstellen dat je dat ooit nodig hebt om een beetje intro van niveau te maken (ik zie nooit simpele kubussen of bollen in die intro's )

Dat klopt ja, maar als je zegt welk effect er wordt aangeroepen, dan wordt dit effect toch gemáákt, dus dan verschijnt/verdwijnt er toch een object? Bvb: particles zijn ook objecten hee.

een effect is meer iets wat je zelf moet implementeren, niet zozeer een object of iets dergelijks (tenminste, zo zie ik het). Een particlesysteem zie ik dan ook als 1 object, ipv alle particles los (lijkt me irritant om die allemaal apart te specificeren)
Een klein voorbeeldje:

C++:

class Effect
{
public:
    virtual ~Effect ();
    virtual void alterParameters (const EffectParameters & p);
    virtual void render (float frameTime) = 0;
};


class ParticleSystem : public Effect
{
public:
    ParticleSystem ();
    ~ParticleSystem ();
    void alterParameters (const EffectParameters & p);
    void render (float frameTime);
};

Effect * createParticleSystem (const EffectParameters & s)
{
    ParticleSystem * e = new ParticleSystem ();
    ...
    return e;
}


int main ()
{
    registerEffect ("ParticleSystem", createParticleSystem);
    ...
    return 0;
}

en in je 'script' geef je aan wanneer een effect aangemaakt moet worden en met welke parameters, welke parameterwijzigenen op welk moment doorgegeven moeten worden, en wanneer ie moet stoppen... Beetje het standaard muziek-programma idee, zoals de oude modtrackers

[madwizard]

De makers van de demo .the .product (farb-rausch) hebben een info pagina over hun demo waar ze enkele screenshots van een tooltje laten zien dat ze gemaakt hebben om de bewegingen etc. te maken. Zo'n tool is natuurlijk weer een programma op zich maar je zou bijvoorbeeld zoiets kunnen maken in combinatie met een engine die dan de output van die tool gebruikt om de scenes te animeren.
Wat ook handig is voor demos is een texture generator die met fractals of andere methodes runtime realistische textures maakt.

[Verwijderd]

Als ik jou lib meelink dan krijg ik HEEL je lib mee, ook als ik niet alle functies uit jou lib gebruik, terwijl ik wil dat alleen de gebruikte functies meegenomen worden. Dus schrijf ik alles opnieuw net zolang totdat ik deze functies zelf heb en ze rechtstreeks kan gebruiken zonder allerlij extra libs mee te moeten compilen.
Idd, dat klopt wel, maar die lib wordt heel klein hoor. En je kan er gewoon de functies uithalen die je nodig hebt.

Daarbij komt nog dat dingen zolas kubussen, bollen etc. redelijkt triviaal zijn. Ook dingen zoals textures laden etc. Iemand die een 64K intro kan coden die gebruik maakt van OpenGL zal een library hiervoor niet nodig hebben, maar zal hier zeer waarschijnlijk zelf al een source code library voor hebben waar gebruik van gemaakt wordt.
Textures ga ik niet plaatsen in die 64kb intro, tenzij ze gebaseerd zijn op een wiskundige formule(wat perfect mogelijk is). Ook ga ik geen andere libs gebruiken, want die zijn meestal te groot(200kb ofzo) om het bestand op 64kb te houden(vermits er meestal via dll's wordt gewerkt ,zoals glut).

Stel: jij maakt een functie om textures te laden. (bmp, jpg, gif,tga etc.).
Stel: ik ga een 64K into maken en gebruik alleen gif textures, dan schrijf ik dus zelf een functie om een gif als texture te gebruiken omdat die gegarandeert kleiner zal zijn dan jou algemene functie.
Die texture-functie komt niet in dat 64kb-progje, dat is voor 'grotere' projecten. En idd, je moet natuurlijk voor elk type texture een routine maken, maar alvorens je begint te programmeren weet je wel (meestal) wat voor bestandsformaat je gaat gebruiken. Ik gaf JPG puur als voorbeeld (het leek me een logisch gekozen formaat, omdat gif eerder bedoeld is voor cartoon-achtige plaatjes en jpg voor foto's)

[Verwijderd]

Dat is niet wat ik bedoel. Bovendien ben je imho erg stom bezig als je de vlakken (quads eigenlijk) apart gaat tekenen terwijl je beter vertex buffers kan gebruiken
Ik had het meer over algemene probleemaanpak, niet zozeer over bepaalde functies die je in hetzelfde programma vaker aanroept (dat is natuurlijk wel voordeliger)
Vertex buffers? Plz explain! (ik ben slechts beginnend opengl coder hee)

Als je echter een lib gaat schrijven dan is dat niet voor 1 programma, maar voor meerdere programma's. Een aanpak van een bepaald probleem moet je dan generalizeren, om de lib zo bruikbaar mogelijk te maken. Dit resulteert echter ook in meer code, wat je in een 64k (of 4k ) intro al helemaal niet kunt gebruiken
het blijft een gewone lib met eenvoudigefuncties om eenvoudige taken te verhandelen, zoals bvb: een assenstelsel tekenen onder bepaalde hoek en op bepaalde coordinaten.

Ten tweede, wat moet je met een kubus of bol generatie-functie? Kan me niet voorstellen dat je dat ooit nodig hebt om een beetje intro van niveau te maken (ik zie nooit simpele kubussen of bollen in die intro's )
Ik nam dat puur als voorbeeld, maar om wat te bewijzen dat je met die functie al heel wat kan doen:


Download(met src): http://users.pandora.be/kenvh/opengl/SineCubes.zip


Download(met src): http://users.pandora.be/kenvh/opengl/WavingCubes.zip


een effect is meer iets wat je zelf moet implementeren, niet zozeer een object of iets dergelijks (tenminste, zo zie ik het). Een particlesysteem zie ik dan ook als 1 object, ipv alle particles los (lijkt me irritant om die allemaal apart te specificeren)
Een klein voorbeeldje:
[ code ]
en in je 'script' geef je aan wanneer een effect aangemaakt moet worden en met welke parameters, welke parameterwijzigenen op welk moment doorgegeven moeten worden, en wanneer ie moet stoppen... Beetje het standaard muziek-programma idee, zoals de oude modtrackers
aha, thanks, ik ken zelf nog niet zoveel van klassen *schaam*

[Verwijderd]

madwizard schreef op 22 oktober 2002 @ 21:16:
De makers van de demo .the .product (farb-rausch) hebben een info pagina over hun demo waar ze enkele screenshots van een tooltje laten

...

Thanks, daar was ik al es die gasten zijn zowat m'n bron van inspiratie

[.oisyn]

kenh: kun je misschien voortaan op de gebruikelijke manier quoten? (dus de gequote tekst tussen [quote]..[/quote] tags zetten)? Deze manier leest namelijk enorm irritant, ook omdat je er niet bijzegd tegen wie je het nou hebt

[.oisyn]

[nohtml]

Verwijderd schreef op 22 oktober 2002 @ 22:20:
Vertex buffers? Plz explain! (ik ben slechts beginnend opengl coder hee)

een vertex buffer is een buffer waar je vertices in staan (ingewikkeld he ). Vertices pushen met glVertex & friends is langzaam. Ik weet niet precies meer welke extensie het is (in de win32 api zit opengl 1.1, daar zit ie niet standaard in), GL_EXT_VERTEX_BUFFER geloof ik (ik programmeer zelf tegenwoordig altijd in DirectX 8, werkt veel lekkerder), maar in plaats van die gl* functies aan te roepen stop je al je data in een array, en die array geef je door aan een gl teken routine.

[Verwijderd]

.oisyn schreef op 22 oktober 2002 @ 22:51:
[nohtml]
[...]


een vertex buffer is een buffer waar je vertices in staan (ingewikkeld he ). Vertices pushen met glVertex & friends is langzaam. Ik weet niet precies meer welke extensie het is (in de win32 api zit opengl 1.1, daar zit ie niet standaard in), GL_EXT_VERTEX_BUFFER geloof ik (ik programmeer zelf tegenwoordig altijd in DirectX 8, werkt veel lekkerder), maar in plaats van die gl* functies aan te roepen stop je al je data in een array, en die array geef je door aan een gl teken routine.

Heb je zo'n voorbeeldje van een array? Of een DirectX framework? Dat zou ik éééénig vinden :):)

[Verwijderd]

Kheb iets handigs gevonden:
http://upx.sourceforge.net/

Het is een exe packager, en maakte m'n 12kB executable tot 6kB! Voor elk type bestand kan je een aangepaste packager kiezen op de site. De ene doet het beter met .sys, de andere met .tif, etc.

[.oisyn]

joh, waar denk je dat al die demo'ers het mee inpakken

Verwijderd schreef op 22 oktober 2002 @ 23:04:
[...]


Heb je zo'n voorbeeldje van een array? Of een DirectX framework? Dat zou ik éééénig vinden :):)

nope, mag je helemaal zelf uitzoeken

[Verwijderd]

Ik heb ondertussen het begin van een particle class-systeem, maar de code compiled nu tot 410kB!!! 't Enige verschil is dat ik een klasse aanmaakte en een array van 100 particles (later werk ik met pointers). Weet iemand hoe het komt dat m'n source zo groot is?

Je kan de source vinden op:
http://users.pandora.be/kenvh/opengl/ParticalEngine1.zip

Dit is het programma:

[Verwijderd]

ik zou het niet met zekerheid kunnen zeggen. maar een simpele mogelijkheid zou kunnen zijn dat je nu gl-functies gebruikt die je voorheen niet gebruikte, die nogal wat code vergen.

edit: ik lees hierboven dat je een proggie van max 64k wil maken. Dat is allemaal wel leuk een aardig, maar als je dan gebruik maakt van de bestaande openGL library (die ongetwijfeld een stuk groter is) vind ik dat niet zo heel erg boeiend. Als je alle 3d-code zelf schrijft is het idd een hele prestatie.

[madwizard]

Als ik je code in VC compile wordt ie 44kb, aan de mapfile te zien ligt dat voor een groot deel aan de libc & math routines. In demos worden deze functies vaak niet uit de standaard libs gehaald maar handmatig toegevoegd zodat alleen het hoognodige meegenomen wordt.

[.oisyn]

Tips:

- release build
- optimise for code size
- shared standaard lib (de runtime dll heeft iedereen wel, maar hoort er in principe wel bij)
- en voor je windows.h include deze definieren: WINDOWS_LEAN_AND_MEAN en VC_EXTRA_LEAN
- je executable inpakken met upx, maar daar was je al achter

[Ericston]

Verwijderd schreef op 23 oktober 2002 @ 19:35:
Ik heb ondertussen het begin van een particle class-systeem, maar de code compiled nu tot 410kB!!! 't Enige verschil is dat ik een klasse aanmaakte en een array van 100 particles (later werk ik met pointers). Weet iemand hoe het komt dat m'n source zo groot is?
[...]

Compile je debug informatie mee?

Verwijderd schreef op 23 oktober 2002 @ 19:42:
ik zou het niet met zekerheid kunnen zeggen. maar een simpele mogelijkheid zou kunnen zijn dat je nu gl-functies gebruikt die je voorheen niet gebruikte, die nogal wat code vergen.

Hij linkt tegen de OpenGL dll.
Het is trouwens ook onzin dat je .exe veel groter wordt omdat je meer verschillende functieaanroepen hebt. Als je tegen een statische library linkt worden volgens mij alle functies sowieso meegebakken.

edit: ik lees hierboven dat je een proggie van max 64k wil maken. Dat is allemaal wel leuk een aardig, maar als je dan gebruik maakt van de bestaande openGL library (die ongetwijfeld een stuk groter is) vind ik dat niet zo heel erg boeiend. Als je alle 3d-code zelf schrijft is het idd een hele prestatie.

Ja, het zou inderdaad een prestatie zijn als ie een hardware accelerated proggel kan schrijven zonder gebruik te maken van een API. Nog iets verder en je zegt dat C een cheape wrapper voor assembly is.

[madwizard]

Ook kun je met de linker de alignment van de PE sections instellen (/FILEALIGN:512 ofzo, 512 is geloof ik het minimum als het moet draaien op alle windows versie). Je code wordt er niet kleiner van maar er komt minder padding tussen de sections en dat kan wat schelen (al zal een packer dat waarschijnlijk ook al voor je doen).
Met de VC library gelinkt als DLL (en filealign 512) komt ie op 6.5 kb, met eigen opstartcode & sin functie is ie 5.5 kb.

[.oisyn]

Ik heb ooit eens een simpel directx 8 demo'tje gemaakt, die is net iets over 64k

de executable
screenshots



.edit: kan trouwens nog een stuk kleiner, ik link nu namelijk met d3d8x.lib omdat ik 1 functie eruit gebruik om de projectiematrix op te zetten... was luiigheid, kan ik ook wel zelf een functie voor maken

.edit2: whehehe, heb m eens gecompiled zonder die lib, dan wordt ie (ingepakt) 12k

linkermuisknop is trouwens sneller bewegen, rechtermuisknop langzamer
met + en - genereer je nieuwe textures

[Verwijderd]

Verwijderd schreef op 23 oktober 2002 @ 19:42:
ik zou het niet met zekerheid kunnen zeggen. maar een simpele mogelijkheid zou kunnen zijn dat je nu gl-functies gebruikt die je voorheen niet gebruikte, die nogal wat code vergen.

edit: ik lees hierboven dat je een proggie van max 64k wil maken. Dat is allemaal wel leuk een aardig, maar als je dan gebruik maakt van de bestaande openGL library (die ongetwijfeld een stuk groter is) vind ik dat niet zo heel erg boeiend. Als je alle 3d-code zelf schrijft is het idd een hele prestatie.

Ik gebruik nog steeds dezelfde functies, eb enkel die uit de OpenGL library (dus geen glut ofzo). M'n vorig programma was slechts 12kb, maar nu dat ik er een klasse aan toevoegde is het de lucht ingeschoten

[Verwijderd]

madwizard schreef op 23 oktober 2002 @ 20:05:
Als ik je code in VC compile wordt ie 44kb, aan de mapfile te zien ligt dat voor een groot deel aan de libc & math routines. In demos worden deze functies vaak niet uit de standaard libs gehaald maar handmatig toegevoegd zodat alleen het hoognodige meegenomen wordt.

Aha! Thanks! Dat lijkt me handig om te beginnen zoeken en trimmen :):):)
Maar:
- libc=?
- die math was ervoor ook al ge-include

[.oisyn]

Verwijderd schreef op 23 oktober 2002 @ 20:26:
[...]


Ik gebruik nog steeds dezelfde functies, eb enkel die uit de OpenGL library (dus geen glut ofzo). M'n vorig programma was slechts 12kb, maar nu dat ik er een klasse aan toevoegde is het de lucht ingeschoten

is het puur alleen die klasse? Kun je eens beschrijven wat je precies gedaan hebt?

[Verwijderd]

Ik heb:
- Een klasse gemaakt om een particle aan te maken en te bewerken (kleur en coordinaten)
- Een header gemaakt voor de declaratie van deze particle klasse
- Een functie aangemaakt om een vlak (rechthoek) te tekenen (net zoals die voor de cubus)
- Een array van 100 particles aangemaakt
- ?
Volgens mij zie ik iets over het hoofd, kweet alleen niet wat

[Verwijderd]

Kheb hetvolgende gedaan:
De klasse en alle bijhorende code verwijderd.
Resultaat: Nog steeds 396kB

[Verwijderd]

Blijkbaar ligt het aan de instellingen van de compiler: Ik gebruik de beta versie van Dev-C++ en had vandaag een MS VC++ project geimporteerd. Hierdoor zijn ws de instellingen van de compiler aangepast zonder dat ik het wist

[Verwijderd]

Damn zeg, ik heb nochtans geen verandering gevonden

[madwizard]

Probeer eens een mapfile uit je linker te halen, daarin staat precies wat waar in de output zit.

[Verwijderd]

madwizard schreef op 23 oktober 2002 @ 21:22:
Probeer eens een mapfile uit je linker te halen, daarin staat precies wat waar in de output zit.

Hoe noemt die? Waar vind ik die? (in de /bin map, waar de linker zit, zijn enkel exe files)

[.oisyn]

een mapfile wordt gegenereerd bij projectcompilatie... moet je even tussen de linkeropties kijken (je gebruikt gcc neem ik aan? de linker-option -Map [file] moet je dus gebruiken)

[madwizard]

Bij de linker die VC gebruikt is het een kwestie van /MAP:filename.map toe te voegen aan de linker opties (in VC is er ook gewoon een configuratie-optie voor). Hoe het in dev-c++ moet weet ik niet, ik geloof dat de compiler de linker aanroept (geen aparte linker stap dus), die moet op 1 of andere manier aan de linker vertellen dat ie een mapfile moet maken (ld.exe heeft wel een optie -Map {FILE}).

[Verwijderd]

.oisyn:
Wil je ook de source van die demo verspreiden? Ik zal em wel eens willen zien

[Verwijderd]

Verwijderd schreef op 23 oktober 2002 @ 21:58:
.oisyn:
Wil je ook de source van die demo verspreiden? Ik zal em wel eens willen zien

Check de links hierboven
En hier is een overzicht:
http://users.pandora.be/kenvh/softcat_opengl.htm

[.oisyn]

Verwijderd schreef op 23 oktober 2002 @ 21:58:
.oisyn:
Wil je ook de source van die demo verspreiden? Ik zal em wel eens willen zien

nou hij is nogal afhankelijk van mijn eigen libs, die ik niet wil verspreiden (ook omdat ze onvolledig zijn enzo). Maar als je wilt kan ik wel een uitleg posten/mailen over hoe ik het gedaan heb (niet hier, daar is het te offtopic voor )

Verwijderd schreef op 23 oktober 2002 @ 22:02:
Check de links hierboven
En hier is een overzicht:
http://users.pandora.be/kenvh/softcat_opengl.htm

hij had het over die van mij
[rml].oisyn in "[ C++] Opengl Library maken"[/rml]

[Verwijderd]

Meel maar naar xkb[at]hypernation.net als je wilt Vooral die texture generatie is erg interessant.

[Verwijderd]

Verwijderd schreef op 23 oktober 2002 @ 22:26:
Meel maar naar xkb[at]hypernation.net als je wilt Vooral die texture generatie is erg interessant.

Die texture generatie wil ik ook wel es zien. Zou je het naar kenvh at hotmail dot com willen sturen?

[.oisyn]

mwa dan kan ik het net zo goed hier uitleggen natuurlijk

allereerst: download eens aarbei's textuur gevaarte. Proggie van aardbei (bekende nederlandse demogroep) om textures te genereren. Mijn lib zit ongeveer hetzelfde in elkaar. Je hebt in principe 2 typen functies: generators en modifiers

Een generator genereert een texture aan de hand van bepaalde parameters
Een modifier heeft een of meerdere textures als input en doet bepaalde berekeningen daarop, en dat resulteert weer in een andere texture

Die berekeningen zijn in principe gewoon simpele wiskundige berekeningen, waarmee je gewoon moet experimenteren om een mooi resultaat te krijgen. Veel van die berekeningen hebben niet echt een betekenis, maar er komen soms wel mooie dingen uit. Zo kun je bijvoorbeeld de pixels van een texture (T) verplaatsen aan de hand van 2 andere 8-bits textures (X en Y), waar je voor elke pixel in T een verplaatsing doet aan de hand van de waarde van die pixel in X units naar rechts en de pixel in Y units naar onderen. Je werkt dus gewoon met waarden tussen 0 en 255 in plaats van de daadwerkelijke kleur

Als jullie willen kan ik wel de generators die ik heb gemaakt beschrijven

[Glimi]

* Glimi gaat om het kampvuur zitten, stopt met chanten en wacht op het spannende verhaal waarmee oisyn ons allemaal een fijne nacht gaat bezorgen

[.oisyn]

hier een voorbeeldje van het verhaal wat ik hierboven vertelde (spannend he glimi )

Linksboven is de texture die je gaat displacen. Die is gegenereerd dmv het cell algoritme (lijkt een beetje op een voronoi diagram)
Rechtsboven en rechtsonder zijn de displacements in respectivelijk de x en de y richting. Deze 2 textures zijn subdivision plasma's

Linksonder is het resultaat. Voor elke pixel in de uitvoer worden de x en de y waarden opgehaald uit de textures rechts. Dit zijn waarden tussen 0 en 255, die je nog moet vermenigvuldigen met een bepaalde factor (dit is ook een parameter van de functie). Vervolgens ga je naar de huidige positie in het origineel, maar schuift dan nog x naar rechts en y naar onderen. En die pixel stop je vervolgens op de huidige positie in de uitvoer

[Verwijderd]

heel naais, zelfs 1337! thanks!

[.oisyn]

nu ik toch bezig ben



Rechts is het resultaat van de vorige, met een emboss filter eroverheen. Links zie je het resultaat van de vorige, geshade met rechts. Dat geeft een mooi glanzend effect

Het emboss filter werkt door voor elke pixel de uitkomst van deze matrix te nemen:

code:

1  0  -1
1  0  -1
1  0  -1

Zo'n matrix is simpelweg een lijstje met factoren, waarmee je de pixels moet vermenigvuldigen. De huidige pixel staat in het midden van de matrix. Hier staat dus:
resultaat = linksboven + links + linksonder - rechtsboven - rechts - rechtsonder

Voor het shade effect heb je een soort van opzoektabelletje nodig (ook te genereren). Als de waarde van de shade-layer 128 is, dan treed er geen kleurverandering op. Bij een waarde van 0 is het resultaat zwart, en bij 255 is het resultaat wit. Daartussen moet je gewoon interpoleren. De combinatie emboss en shade wordt veel gebruikt om mooie glanzende textures te genereren

[Verwijderd]

Een handige tip:

Het programma "3D Exploration" is een soort van mesh-browser, die alle bekende mesh formaten kan inlezen (dxf, 3ds, raw, x, ......)
het superhandige aan dit programma is dat het ook naar pure c++ code kan exporteren, zodat je het object onmiddellijk kan gebruiken in je programma.
Je kan kiezen tussen verschillende niveau's: Data only, Sample app, Display list

Je vind het programma (30 day trial) op:
http://www.xdsoft.com/explorer/

[Verwijderd]

Ik ben momenteel bezig met een programma om scenes in elkaar te steken:

http://users.pandora.be/kenvh/misc/SceneThingy.zip

http://users.pandora.be/kenvh/misc/SceneThingy.jpg

't Programma gaat later een c++ bestand aanmaken met daarin een array met alle acties die er in het filmpje moeten gebeuren (vb: initialiseren van klassen en het bewerken van hun eigenschappen).

Het object.ini bestand ziet er zo ongeveer uit:
["Cube",["Coordinates","Size3D","Angle3D","Color"],"3D Cube"]
["Rectangle",["Coordinate","Size2D","Angle3D","Color"],"2D Rectangle"]
["ParticleEffect1",["Coordinates","Size3D","Angle3D","Color"],"Particle effect 1"]
Het leest alle objecten in , en welke eigenschappen het programma moet vragen aan de user bij het creeeren van zo'n object. Per object komt dan ook nog es een bestand, met alle operaties die eraan kunnen worden toegevoegd. Zoals bvb Cube1.Rotate(...)

Dit programma ga ik hoogst waarschijnlijk publiek maken, zodat anderen er ook nog iets aan hebben. De twee aanzichten in het programma zullen wel in 2D zijn.
(omdat de programmeertaal die ik gebruik voor deze applicatie niet met opengl werkt).

Suggesties?
Zou ik bij elk object in het aanzicht-venster ook telkens de naam plaatsen? Of dit als een optie toevoegen?

[Verwijderd]

Ik vraag me af hoe ik een midi bestand in de exe kan plaatsen?

[madwizard]

Verwijderd schreef op 26 oktober 2002 @ 17:35:
Ik vraag me af hoe ik een midi bestand in de exe kan plaatsen?

Je kunt het in je resource file stoppen of als raw data in je programma zetten (scheelt weer wat bytes).
Hangt ook een beetje af welke API je gebruikt om het af te spelen.

[Verwijderd]

madwizard schreef op 26 oktober 2002 @ 18:56:
[...]

Je kunt het in je resource file stoppen of als raw data in je programma zetten (scheelt weer wat bytes).
Hangt ook een beetje af welke API je gebruikt om het af te spelen.

De API die ik gebruik noemt "winmm" en leest enkel bestanden in... ik heb een oplossing gevonden:
Ik lees met een programmaatje(wat ik reeds maakte) alle bytes in en schrijf deze weg als een array in een header file.
Bij het openen van de exe schrijft hij telkens de binary data in een midi file weg, die hij op het einde terug wist.

[Verwijderd]

Vraagje:

Stel dat ik aan de hand van een wiskundige formule een 50x50 matrix vul met rgb-waarden, hoe kan ik deze dan in OpenGL openen als texture? (of: hoe kan ik deze omzetten naar bruikbare texture data)?

[.oisyn]

glTexImage2D ()

lijkt me vrij simpel en standaard

[Verwijderd]

.oisyn schreef op 27 oktober 2002 @ 22:02:
glTexImage2D ()

lijkt me vrij simpel en standaard

Kan je dat effe uitleggen?
Stel je voor dat ik zulk array heb:

float MijnTexture[50][50][3];

[madwizard]

Zoiets denk ik:

C++:

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB,
             50, 50,
             0, GL_RGB, GL_FLOAT,
             MijnTexture);

[.oisyn]

Verwijderd schreef op 27 oktober 2002 @ 23:00:
[...]


Kan je dat effe uitleggen?
Stel je voor dat ik zulk array heb:

float MijnTexture[50][50][3];

ja sorry hoor maar dat is gewoon basic opengl
kijk eens op nehe.gamedev.net of zoek op google naar andere opengl tutorials

[Verwijderd]

Picture update (en programma-link ook)
Suggesties zijn welkom!!!
http://users.pandora.be/kenvh/misc/SceneThingy.zip



(Edit 2)
Het werkt zo: je maakt objecten waarop je acties kan toevoegen in de scene. Deze objecten staan in het (editeerbare) ini bestand, en elk object heeft zijn eigen ini bestand met de mogelijke acties die je erop kan uitvoeren.
Dit programma gaat later gewoon c++ code genereren om dan in een 3D scene in te bouwen. De gegenereerde code zal een array van scene-operaties zijn, die het programma lineair inleest (de scene operaties zélf zijn daarom niet altijd lineair, vermits deze via klassen werken).

Het is ook mogelijk dat ik het programma zou uitbreidt zodat er ook kan ge-exporteerd worden naar programmeercode in andere talen (Visual Basic), maar dit is nog onzeker, vermits ik zélf enkel C++ code nodig heb. (dat hangt ervanaf ... maw wat jullie voorstellen).

[Verwijderd]

Voor de geinteresseerden:

Er is een nieuwe versie uit van SceneThingy, waarmee je de gemaakte scenes kan exporteren naar C++ code en XML. Aan VB export wordt nog gewerkt.
Ook kan je natuurlijk de scenes opslaan en openen. Er is een .sc (scene) bestand in de zip, voor diegene die gewoon de look and feel es willen testen ipv een hele scene zelf te bouwen.
Ik hoop dat iemand hier iets aan heeft.
De Lite versie zal gratis zijn, maar de Pro versie zal een soort 3D engine bevatten, zodat je met dit programma er filmpjes voor kan maken. Dus voor de Lite versie zal je zelf programma-code moeten schrijven(er is reeds een C++ voorbeeldprogramma bij waarin uitgelegd staat hoe je zo'n scene kan verhandelen in C++).

Edit: nog es bedankt aan diegene die me tips gaven ivm OpenGL meer tips & suggesties zijn steeds welkom!

[Verwijderd]

Het is al een jaar oid niet geupdate, maar voor OpenGL demos gebruik je een demosystem zoals de mijne: DemoGL : http://www.demogl.com

C++ oriented en speciaal voor het makkelijk bouwen van effect based demos, dus waarbij je een effect bouwt in een class en die dmv het demosystem scheduled (script) en rendert.

(Oja, OpenGL / win32 only wel open source, dus je kunt er naar hartelust van alles aan wijzigen. )

[Verwijderd]

Verwijderd schreef op 05 november 2002 @ 08:53:
Het is al een jaar oid niet geupdate, maar voor OpenGL demos gebruik je een demosystem zoals de mijne: DemoGL : http://www.demogl.com

C++ oriented en speciaal voor het makkelijk bouwen van effect based demos, dus waarbij je een effect bouwt in een class en die dmv het demosystem scheduled (script) en rendert.

(Oja, OpenGL / win32 only wel open source, dus je kunt er naar hartelust van alles aan wijzigen. )

Dat ziet er heel nice uit Maar dat van mij vereist geen kennis van C++ ofzo (de Pro versie alleszinds)
De bedoeling is ook om de executable heeeeel klein te houden, onafhankelijk van eender welke dll (behalve de opengl dll). Vermits dit m'n basis is om een 64kb intro te maken.
Kheb ook al een programma om via wiskundige formules textures te maken