[VB] Simpele game maken

[ddkiller0900]

Ik wou zo een simpel 3d spel maken, eerst een soort demo met 1 level en paar dingen dat mannetje al kan doen of zo en daarna uitbreiden. Nu vind ik zelf wel dat je nergens een tutorial vind om een spel te maken, liefst nederlandstalig. Iemand enige ervaring hiermee?

[LauPro]

Ik kan je alvast een ding zeggen: Visual Basic is Traag!!!!

Mare je kan wel wat maken met Direct3D enzo, maar dat wordt een diaserie dat zeg ik je nu alvast

[.oisyn]

hmmz
[topic=348173]

^{* .oisyn alert *}

[LAN]

Misschien kun je antwoorden vinden op je vragen in de help-file (versie: visual basic) van de DirectX SDK (Te downloaden bij microsoft).
Er staan een paar DirectX Graphics Visual Basic tutorials in.

Succes.

[ddkiller0900]

In wat zouden jullie dan een game maken? Wat is niet te moeilijk maar je moet er wel soort First person shooters mee kunnen maken.

[Verwijderd]

hoe komt het toch dat die topics elke maand weer 3x terugkomen

kan je nog andere progtalen behalve VB,
bijv c, of c++ ?

[whoami]

Op woensdag 12 juni 2002 06:14 schreef ddkiller0900 het volgende:
In wat zouden jullie dan een game maken? Wat is niet te moeilijk maar je moet er wel soort First person shooters mee kunnen maken.

Ik denk dat je het een heeeel klein beetje onderschat...

Heb je al programmeerervaring?

[Exirion]

Op woensdag 12 juni 2002 06:14 schreef ddkiller0900 het volgende:
Wat is niet te moeilijk maar je moet er wel soort First person shooters mee kunnen maken.

Geloof me: die twee dingen gaan niet samen. Je moet een hele dosis programmeerervaring hebben om zoiets in je eentje te kunnen realiseren.

[Gerco]

Op dinsdag 11 juni 2002 23:40 schreef LauPro het volgende:
Mare je kan wel wat maken met Direct3D enzo, maar dat wordt een diaserie dat zeg ik je nu alvast

Vooroordeel nummer 1 en ook het minste waar.

VB is inderdaad trager dan C++, daar valt niet over te twisten. Maar als je een game maakt met Direct3D of DirectDraw, doen DIE het tekenwerk waar VB zo traag in is. In gewoon rekenwerk (het enige wat je app hoeft te doen bij een Direct* game) is het maar 5% tot 10% trager dan c++ code.

Ze gebruiken niet voor niets nagenoeg dezelfde backend-compiler.

[Verwijderd]

Misschien is www.gameskool.nl iets?

[Janoz]

Op woensdag 12 juni 2002 08:45 schreef Gerco het volgende:

[..]

Vooroordeel nummer 1 en ook het minste waar.

VB is inderdaad trager dan C++, daar valt niet over te twisten. Maar als je een game maakt met Direct3D of DirectDraw, doen DIE het tekenwerk waar VB zo traag in is. In gewoon rekenwerk (het enige wat je app hoeft te doen bij een Direct* game) is het maar 5% tot 10% trager dan c++ code.

Ze gebruiken niet voor niets nagenoeg dezelfde backend-compiler.

Tekenen is 1 ding. Bij 3d applicaties komt echter veel meer kijken dan alleen het 'polypushen'. Ik ben benieuwd hoe snel jij je colission detection, NPC AI, datastructuren in VB wilt gaan krijgen...

Aan je post zie ik een ander vooroordeel. Dat is namelijk dat veel mensen denken dat je met een paar Direct3D of openGL commando's zo een 3d app bij elkaar hebt. Dat is mischien wel zo met een leuk draaiende kubus, of een model viewer, maar verwacht echt niet dat je daar een game mee maakt...

[Glimi]

Op dinsdag 11 juni 2002 23:47 schreef .oisyn het volgende:
hmmz
[topic=348173]

^{* Glimi alert *}

LOL het grappige is, is dat men vaak VB wil gaan gebruiken, voor een 3d game waarbij je dus rekening moet gaan houden collision detection en meer van zulke dingen.
Dit vergt echt wiskundig rekenwerk. Elke sterke wiskundige programmeur die ik ken, gebruikt geen VB

waarom begint men nooit met een simpele versie van pong, een platform spelletje, digger of nog beter liero Allemaal niet zo heeel moeilijk maar erg leuk om te maken en een goed opstapje

[Verwijderd]

C++ lijkt me het meest geschikt en ook niet al te moeilijk...

[Gerco]

Op woensdag 12 juni 2002 09:07 schreef Janoz het volgende:
Tekenen is 1 ding. Bij 3d applicaties komt echter veel meer kijken dan alleen het 'polypushen'. Ik ben benieuwd hoe snel jij je colission detection, NPC AI, datastructuren in VB wilt gaan krijgen...

Ik weet ook wel dat het niet zo snel zal zijn als in C++ (of Delphi, of om het even welke taal dan ook) en met objecten werken in VB is gewoon traag, geen twijfel over mogelijk. Maar dat het niet mogelijk is om in VB iets redelijk snels neer te zetten is gewoon kolder.

Aan je post zie ik een ander vooroordeel. Dat is namelijk dat veel mensen denken dat je met een paar Direct3D of openGL commando's zo een 3d app bij elkaar hebt. Dat is mischien wel zo met een leuk draaiende kubus, of een model viewer, maar verwacht echt niet dat je daar een game mee maakt...

Wie zei dat? Ik weet echt wel hoe Direct3D werkt, ik heb inderdaad nog nooit een game ermee gemaakt, maar ik weet wel degelijk hoe de Direct3D API eruit ziet en wat je allemaal zelf moet doen.

Het 3D werk is niet eens het meeste, de game-engine is het moeilijke stuk. Vergeleken daarbij is het 'poly-pushen' een kleingheidje.

Het enige wat ik uit de wereld wilde helpen is dat VB per definitie te traag zou zijn om iets werkbaars te maken, dat een game maken niet 'even' gedaan is en dat je daar mee voor nodig hebt dan polypushen hoef je mij niet uit te leggen.

Ik snap ook wel dat je kan denken dat ik zo'n "YAY! Ik ken VB, volgende week heb ik Quake4 af" n00b ben, gewoon vanwege het feit dat ik niet per definitie negatief ben over VB, maar ik kan je verzekeren dat je dan aan mij de verkeerde hebt.

--- [hmmz, ik geloof dat ik in een slecht humeur ben vandaag] ---

[Janoz]

Ik zeg ook absoluut niet dat VB not the way to go is. Wat ik alleen vaak zie is dat mensen hun taal keuze van hun kennis laten afhangen (dat geldt voor VB-ers, maar ook voor C++-ers) ipv van het probleem. Je bent gek als je een 3d-game wilt maken met VB, maar je bent net zo gek als je je simpele frontend in C++ gaat schrijven.

Het 3D werk is niet eens het meeste, de game-engine is het moeilijke stuk. Vergeleken daarbij is het 'poly-pushen' een kleingheidje.

Dat is kennis die bij heel veel mensen ontbreekt . Ik ga er dan ook meestal van uit dat iemand dat niet weet, en deze kennis was uit je eerste reactie ook niet op te maken..

[Sponge]

Op dinsdag 11 juni 2002 23:40 schreef LauPro het volgende:
Ik kan je alvast een ding zeggen: Visual Basic is Traag!!!!

Mare je kan wel wat maken met Direct3D enzo, maar dat wordt een diaserie dat zeg ik je nu alvast

Ik heb een hekel aan mensen die dat beweren

Uiteraard, er zijn een paar kleine dingen die langzamer zijn, maar als je de juite variabelen kent en zorgt voor zo min mogelijk variabele conversies, is het net zo snel als C++...

Sin, Cos, Tan al die instructies zijn het zelfde voor C++ en VB, wat gebruik je het meest met DX programming? Juist.

De tijd die je bespaard door met VB te programmeren is zeker die paar FPS lager wel waard.

(En ja, Quake3 moet je niet verwachten.) Check www.truevision3d.com of www.revolution3d.de...

[Gerco]

Op woensdag 12 juni 2002 11:47 schreef Janoz het volgende:
Dat is kennis die bij heel veel mensen ontbreekt . Ik ga er dan ook meestal van uit dat iemand dat niet weet, en deze kennis was uit je eerste reactie ook niet op te maken..

Dat snap ik, ik reageerde denk ik ook wat heftig. Jij had niet kunnen weten dat ik die kennis wel heb, komt waarschijnlijk door mn slechte humeur van vanochtend .

Ik kan er alleen niet zo goed tegen als mensen VB horen en dan gelijk gaan gillen "Slecht! Traag! voor n00bs!", zonder dat ze ooit een regel VB code gezien hebben. Ik zeg niet dat jij dat doet, jij komt wel over als iemand die eerst nadenkt en een groot voorstander is van "The right tool for the right job", zoals ik.

Ik zeg niet dat VB wel goed is ofzo, maar het is geschikt voor een hoop dingen (gemakkelijk UI's in elkaar klikken, eenvoudige buisness logica, etc) en een hoop dingen niet (grote projecten zoals Access ofzo, al valt daar over te twisten). De taal is niet de meest consistente die ik ooit gezien heb en de error handling is om te huilen. Maar verder vind ik het in grote lijnen prettig werken, als je een beetje om de beperkingen heenkijkt.

[Sponge]

Veel beperkingen zijn te omzeilen met de Winapi of Varptr(), VarptrArray(), StrPtr(), waardoor je pointers kunt gebruiken

[MewBie]

offtopic:
[quote]
Op woensdag 12 juni 2002 09:25 schreef Glimi het volgende:
waarom begint men nooit met een simpele versie van pong, een platform spelletje, digger of nog beter liero Allemaal niet zo heeel moeilijk maar erg leuk om te maken en een goed opstapje
[/quote]

hehe Liero rulezz, vooral 2spelers

geloof me VB is veel te traag voor een spelletje, ik heb een keer geprobeerd om een vlak soepel te laten bewegen in VB wat me in 4 weken tijd niet gelukt is, dus ik weet zeker dat je een 3d spelletje in VB kan vergeten

[Janoz]

Mischien ligt dat meer aan jou dan aan vb

[Sponge]

Even wat plaatjes van VB games... ik doe ze niet als IMG hierin want dat geeft alleen maar ellende voor de layout en maakt het laden weer trager...

http://voodoovb.dnsalias.net/vbgcontest/pc2.jpg
http://voodoovb.dnsalias.net/vbgcontest/game1full.jpg
http://voodoovb.dnsalias.net/vbgcontest/Screenshot1.jpg
http://voodoovb.dnsalias.net/vbgcontest/screenshot03.jpg
http://www.truevision3dsdk.com/gallery/bigpic.asp?sLink=default&sPic=Screenshot010&sPrjName=&sCreator=
http://www.revolution3d.de/
http://www.revolution3d.de/r3dhp/dImages/dShots/screen1.jpg
http://www.revolution3d.de/r3dhp/dImages/dShots/screen140.jpg

[.oisyn]

Op woensdag 12 juni 2002 13:37 schreef Janoz het volgende:
Mischien ligt dat meer aan jou dan aan vb

lol, maar d'r zit idd wel een kern van waarheid in

modelviewers en dingen waarbij je gewoon al je poly's tekent zonder enige space partitioning zijn in vb best wel goed te doen... alleen een FPS is geen modelviewer

Je zult visible surface determination erin moeten bouwen, collision detection & response (en misschien nog volumetric lighting ), en daar is vb nou net niet goed in.

In die gevallen moet je gigantische hoeveelheden aan data verwerken en daar berekeningen op loslaten... en dan kom je toch wel aan de minpunten van VB, namelijk het gemis van pointers en die smerige runtime checks. Natuurlijk kun je met objecten werken, maar van die impliciete get en let functies voor 'variabelen' wordt je ook niet bepaald vrolijk

Maar ik wil toch echt vb gebruiken. Oh grote .oisyn, wat zou jij mij aanraden

Zoek eens naar blitzbasic of darkbasic. Zelf geen ervaring mee, maar het zijn basic-achtige taaltjes die precies voor dat doel ontworpen zijn...
Of gebruik maken van een voorgeprogrammeerde engine met COM support. Dan kun je ze gewoon in VB gebruiken en daarin je gamecode schrijven (wat ook prima te doen is in VB) (ook geen ervaring mee overigens, maar ze zijn er volgens mij wel)

Dus google ze

[ddkiller0900]

En als ik nou eens met Quest 3D en 3D Studio Max zoiets maak, zou dat niet iets zijn? Het moet ofwel 3D zijn maar bv iets in 2D wil ik best wel leren want 2D is makkelijker dan 3D. Als ik 2D zou willen doen, welk programma raden jullie mij aan en bijbehorende tutorials? Met google stuip ik op vanalles, maar wat is eenvoudig in gebruik. Stel 2D, spel zoals mario of zo van vroeger op de gameboy, iets meer interactive natuurlijk of vechtspelletje gelijk mortal kombat 3. Wat is best geschikt?

[Sponge]

Eh, sorry maar Darkbasic is dus nog verschrikkelijker dan VB dus he? Blitzbasic heb ik echter nog nooit gebruikt

Sowieso voor elk spel heb je programmer kennis nodig, tenzij je Klik n Play wilt gebruiken (www.clickteam.com uit m'n hoofd?) Op dit moment ben ik bezig met een programmeer wedstrijd (daarom geen screenshot), waar ik maar liefts 11777 particles heb in VB, allemaal gebaseerd op classes, waardoor het iets langzamer zou gaan.

Als je programmeert zoals VB het eist, is VB bina gelijk met C++..zoals ik eerder zei het zit in de conversies tussen variabelen

x = x + 5
x =+ 5

blijft altijd nog ongeveer:

mov eax, [x]
add eax, 5
mov [x], eax

voor VB of C++ (of Delphi, Java, etc.)

offtopic:
Hoe kom jij nou aan 3DSMax?

[Gerco]

Op woensdag 12 juni 2002 14:10 schreef 41.6C.6D.61.72 het volgende:
mov eax, [x]
add eax, 5
mov [x], eax

Niet dit?:

code:

add DWORD PTR[x], 5

disclaimer: ASM is een tijd geleden

[Sponge]

Op woensdag 12 juni 2002 14:13 schreef Gerco het volgende:

[..]

Niet dit?:

code:

add DWORD PTR[x], 5

disclaimer: ASM is een tijd geleden

Klopt, volgens mij. Zo doet VB dit idd, maar je hebt Masm, Nasm, Tasm, Nasi, Bami..en al die varianten

Ik nam de Nasm syntax maar aan. Die kent geen PTR dacht ik, wel DWORD 5, maar bij Nasm moet Add dacht ik altijd NAAR een register to (ook een tijdje geleden voor mij, geprobeert om te kijken of m'n fractal planet generator dll(voor QW), sneller was dan die in VB...viel wel mee eigenlijk)

[Exirion]

Op woensdag 12 juni 2002 14:13 schreef Gerco het volgende:
Niet dit?:

code:

add DWORD PTR[x], 5

disclaimer: ASM is een tijd geleden

Yup, die extra moves zijn overbodig
Je kunt gewoon direct een geaddresseerde dword ophogen.

[Gerco]

Op woensdag 12 juni 2002 14:19 schreef Exirion het volgende:
Yup, die extra moves zijn overbodig

Nou... door die moves gaat het optellen wel een stuk sneller... (over de tijd die de moves kosten heb ik het even niet, laat staan het probleem dat er waarschijnlijk geen register vrij is )

[Exirion]

Op woensdag 12 juni 2002 14:21 schreef Gerco het volgende:
Nou... door die moves gaat het optellen wel een stuk sneller... (over de tijd die de moves kosten heb ik het even niet, laat staan het probleem dat er waarschijnlijk geen register vrij is )

Jah, moet je weer gaan pushen en poppen. Ook niet fijn

Bovendien maken die moves het echt niet sneller hoor

Die moves kosten 2 clockcycly geloof ik, en adden op een geaddresseerde dword iets van 5 cycli? Het is een tijd geleden

[Gerco]

Wat zou VB eigenlijk van x = x + 1 maken?

code:

inc DWORD PTR[x]

of

code:

add DWORD PTR[x], 1

[Gerco]

Op woensdag 12 juni 2002 14:23 schreef Exirion het volgende:
Bovendien maken die moves het echt niet sneller hoor

Ik zei: "door die moves wordt het optellen sneller" en daarachter zei ik dat ik geen rekening heb gehouden met de tijd die de moves kostten.

maw. ik zei gewoon: "Optellen in een register is sneller dan in het geheugen"

[Exirion]

Op woensdag 12 juni 2002 14:26 schreef Gerco het volgende:
maw. ik zei gewoon: "Optellen in een register is sneller dan in het geheugen"

Ohw, je trapte even een open deurtje in

[.oisyn]

Op woensdag 12 juni 2002 14:10 schreef 41.6C.6D.61.72 het volgende:
Eh, sorry maar Darkbasic is dus nog verschrikkelijker dan VB dus he? Blitzbasic heb ik echter nog nooit gebruikt

zoals ik al zei, ik heb er geen ervaring mee

Op dit moment ben ik bezig met een programmeer wedstrijd (daarom geen screenshot), waar ik maar liefts 11777 particles heb in VB, allemaal gebaseerd op classes, waardoor het iets langzamer zou gaan.

Als je programmeert zoals VB het eist, is VB bina gelijk met C++..zoals ik eerder zei het zit in de conversies tussen variabelen

no offense, maar particles zou nou niet echt bepaald moeilijk om te implementeren, zelfs in vb niet

Wat wel interessant is is hoe je bijvoorbeeld het volgende stukje code in VB zou implementeren, op een snelle manier:

code:

bool BSPNode::traceBox (tracedata_t * td, const Vector & v0, const Vector & v1, const Vector & halfSize) const
{
    if (type == NODE_SOLID)
    {
        td->t = 0.f;
        return true;
    }
    
    else if (type & (NODE_EMPTY | NODE_VOID))
        return false;


    Vector temp, dir;
    float addDist;
    tracedata_t td1, td2;
    bool hit1, hit2;

    if (plane->normal.x >= 0.f)
        addDist = plane->normal.x * halfSize.x;
    else
        addDist = -plane->normal.x * halfSize.x;

    if (plane->normal.y >= 0.f)
        addDist += plane->normal.y * halfSize.y;
    else
        addDist -= plane->normal.y * halfSize.y;

    if (plane->normal.z >= 0.f)
        addDist += plane->normal.z * halfSize.z;
    else
        addDist -= plane->normal.z * halfSize.z;

    float d0 = v0.dot (plane->normal) - plane->dist;
    float d1 = v1.dot (plane->normal) - plane->dist;

    dir.sub (v1, v0);
    if (dir.dot (plane->normal) < 0.f)
    {
        if ((type & NODE_AAFLAG) || ((d0 + addDist) <= 0.f))
            hit1 = false;

        else if ((d1 + addDist) >= 0.f)
            hit1 = front->traceBox (&td1, v0, v1, halfSize);

        else
        {
            float dt = (d0 + addDist) / (d0 - d1);
            temp.addScale (v0, dir, dt);

            if (hit1 = front->traceBox (&td1, v0, temp, halfSize))
            {
                if (td1.t == 0.f)
                {
                    td1.planeNormal = plane->normal;
                    td1.nodeID = id;
                }
                else
                    td1.t *= dt;
            }
        }

        if ((d1 - addDist) >= 0.f)
            hit2 = false;

        else if ((d0 - addDist) <= 0.f)
            hit2 = back->traceBox (&td2, v0, v1, halfSize);

        else
        {
            float dt = (d0 - addDist) / (d0 - d1);
            temp.addScale (v0, dir, dt);

            if (hit2 = back->traceBox (&td2, temp, v1, halfSize))
            {
                if (td2.t == 0.f)
                {
                    td2.t = dt;
                    td2.planeNormal = plane->normal;
                    td2.nodeID = id;
                }
                else
                    td2.t = (1.f - dt) * td2.t + dt;
            }
        }           
    }
    else
    {
        if ((d0 - addDist) >= 0.f)
            hit1 = false;

        else if ((d1 - addDist) <= 0.f)
            hit1 = back->traceBox (&td1, v0, v1, halfSize);

        else
        {
            float dt = (d0 - addDist) / (d0 - d1);
            temp.addScale (v0, dir, dt);

            if (hit1 = back->traceBox (&td1, v0, temp, halfSize))
            {
                if (td1.t == 0.f)
                {
                    td1.nodeID = id;
                    td1.planeNormal = plane->normal;
                }
                else
                    td1.t *= dt;
            }
        }

        if ((type & NODE_AAFLAG) || ((d1 + addDist) <= 0.f))
            hit2 = false;

        else if ((d0 + addDist) >= 0.f)
            hit2 = front->traceBox (&td2, v0, v1, halfSize);

        else
        {
            float dt = (d0 + addDist) / (d0 - d1);
            temp.addScale (v0, dir, dt);

            if (hit2 = front->traceBox (&td2, temp, v1, halfSize))
            {
                if (td2.t == 0.f)
                {
                    td2.t = dt;
                    td2.planeNormal = plane->normal;
                    td2.nodeID = id;
                }
                else
                    td2.t = (1.f - dt) * td2.t + dt;
            }
        }           
    }

    if (hit1)
    {
        if (hit2)
        {
            if (td1.t < td2.t)
            {
                *td = td1;
                return true;
            }

            *td = td2;
            return true;
        }

        *td = td1;
        return true;
    }

    if (hit2)
    {
        *td = td2;
        return true;
    }

    return false;
}

En dit wordt dus per frame echt vaak aangeroepen.
(note: ik bedoel natuurlijk niet letterlijk deze functie, maar ik heb dit alleen maar gepost om aan te geven hoe belangrijk pointers/references zijn en dat je zonder runtime checks of vage property functies bij de membervariabelen moet kunnen komen. Dit is trouwens een axis aligned bounding box (AABB) collision detection routine voor een bsp tree)

[Sponge]

Ik zou het waarschijnlijk gewoon letterlijk porten naar VB en andere methodes verzinnen als het nodig is. Maar dat is het nou juis, C++ is niet letterlijk te vertalen naar Vb, dan is het traag. voorbeeldje:

http://www.2tothex.com/raytracing/index.html

Die C++ raytracer die je daar kunt downloaden (gebruik diffuse.exe) draait op 26fps hier... ik heb die geport (VB) en samen met iemand anders hebben we 66fps(!!) voor elkaar gekregen, realtime, geraytraced. Zonder dat je verschil ziet.

[.oisyn]

sorry, maar ik geloof je niet
heb je een executable?

[Sponge]

Op woensdag 12 juni 2002 14:24 schreef Gerco het volgende:
Wat zou VB eigenlijk van x = x + 1 maken?

code:

inc DWORD PTR[x]

of

code:

add DWORD PTR[x], 1

Laten we het daarmaar niet over hebben
Heb de compiler eventjes onderschept,

code:

Private Sub Form_Load()
    Dim lngX As Long
    
    lngX = lngX + 1
    
End Sub

-is-

code:

; 20   : Private Sub Form_Load()

    push    ebp
    mov ebp, esp
    sub esp, 12                 ; 0000000cH
    push    OFFSET FLAT:___vbaExceptHandler
    mov eax, DWORD PTR fs:__except_list
    push    eax
    mov DWORD PTR fs:__except_list, esp
    sub esp, 12                 ; 0000000cH
    push    ebx
    push    esi
    push    edi
    mov DWORD PTR __$SEHRec$[ebp+8], esp
    mov DWORD PTR __$SEHRec$[ebp+12], OFFSET FLAT:$S25
    mov eax, DWORD PTR _Me$[ebp]
    mov ecx, eax
    and ecx, 1
    mov DWORD PTR __$SEHRec$[ebp+16], ecx
    and al, -2                  ; fffffffeH
    push    eax
    mov DWORD PTR _Me$[ebp], eax
    mov edx, DWORD PTR [eax]
    call    DWORD PTR [edx+4]

; 21   :     Dim lngX As Long
; 22   :     
; 23   :     lngX = lngX + 1
; 24   :     
; 25   : End Sub

    mov eax, 1
    mov DWORD PTR __$SEHRec$[ebp+16], 0
$L24:
    mov eax, DWORD PTR _Me$[ebp]
    push    eax
    mov ecx, DWORD PTR [eax]
    call    DWORD PTR [ecx+8]
    mov eax, DWORD PTR __$SEHRec$[ebp+16]
    mov ecx, DWORD PTR __$SEHRec$[ebp]
    pop edi
    pop esi
    mov DWORD PTR fs:__except_list, ecx
    pop ebx
    mov esp, ebp
    pop ebp
    ret 4
$L20:
    call    DWORD PTR __imp____vbaErrorOverflow
?Form_Load@Form1@@AAGXXZ ENDP               ; Form1::Form_Load
text$1  ENDS
END

[Janoz]

Op woensdag 12 juni 2002 14:48 schreef 41.6C.6D.61.72 het volgende:
Die C++ raytracer die je daar kunt downloaden (gebruik diffuse.exe) draait op 26fps hier... ik heb die geport (VB) en samen met iemand anders hebben we 66fps(!!) voor elkaar gekregen, realtime, geraytraced. Zonder dat je verschil ziet.

Mischien zegt dat meer over de orginele C++ code dan over VB.

hmm .. al de tweede keer dat ik zo'n opmerking maak....

[.oisyn]

hahaha ja sorry hoor maar als je een schermpje gebruikt van 170x145 pixels waarin je 4 sphere's traced dan ben ik niet bepaald onder de indruk

En janoz heeft gelijk, dat zegt idd meer over de implementatie van de C++ versie dat het zo langzaam loopt dan jouw VB port

screenshot:

[Sponge]

De C++ code is niet eens zo beroerd hoor, maar wij hebben wat meer na gedacht over de limieten van windows zelf, bijv. de redraw tijd van een form/picturebox (want zoveel verschil zit er echt ni et in de code, niet meer dan 5 regels als je naar de raytracer code kijkt)

Okay dan gaan we verder..pure NASM Dll, vs. VB
Planeet gemaakt met 200x200, 1000 iteraties.

VB: 1492ms
ASM: 1002ms

Met 400x400, 1000 iteraties

VB: 5848ms
ASM: 3566ms

ASM geoptimaliseerd volgens de AMD-Athlon instructie set.

Vinden jullie dat nou grote verschillen?

[ddkiller0900]

Kent iemand een gratis 3D engine met goede kwaliteit. De Quake 2 of 3 zal je wel voor moeten betalen. Maar ik heb besloten om gewoon via een engine te beginnen aan een spel

[Sponge]

www.truevision3d.com
www.revolution3d.de
www.genesis3d.com (oid)

zoek op google naar "huge 3d engine list", is namelijk een grote lijst beschikbaar

[.oisyn]

ja maar wat probeer je nu te bewijzen
niemand heeft beweerd dat VB wat berekeningen betreft langzamer is, maar waar VB wel langzamer mee is is het verwerken van grote hoeveelheden aan data, zoals een scenegraph in een 3d fps en de collision detection daarbij

[ddkiller0900]

Als je programmeert zoals VB het eist, is VB bina gelijk met C++..zoals ik eerder zei het zit in de conversies tussen variabelen

x = x + 5
x =+ 5

is het niet x += 5

[.oisyn]

Op woensdag 12 juni 2002 15:19 schreef 41.6C.6D.61.72 het volgende:
zoek op google naar "huge 3d engine list", is namelijk een grote lijst beschikbaar

http://www.meshes.com/cssgame/engine1.htm
stond nog in mijn favorieten

[.oisyn]

Op woensdag 12 juni 2002 15:18 schreef ddkiller0900 het volgende:
Kent iemand een gratis 3D engine met goede kwaliteit. De Quake 2 of 3 zal je wel voor moeten betalen. Maar ik heb besloten om gewoon via een engine te beginnen aan een spel

van quake 1 en 2 kun je de source gratis downloaden (GNU lesser license als ik me niet vergis)

[Verwijderd]

Voor VB zijn een aantal directx wrappers te krijgen. De beste (IMHO) is de truevision 3d SDK

www.truevision3d.com

[.oisyn]

lees de draad voor je blaat

[Sponge]

Op woensdag 12 juni 2002 15:20 schreef .oisyn het volgende:
ja maar wat probeer je nu te bewijzen
niemand heeft beweerd dat VB wat berekeningen betreft langzamer is, maar waar VB wel langzamer mee is is het verwerken van grote hoeveelheden aan data, zoals een scenegraph in een 3d fps en de collision detection daarbij

Dat VB niet zo langzaam is als iedereen denkt, als je maar GOED programmeert in de taal zoals VB wil

bijv 80% xal niet het verschil tussen / en \ weten, de laatste is slechts 500 % sneller.. of 10 * 0.5 ipv. 10 / 0.2 (200% sneller), of x^2 en x*x (laatste 8000% sneller)

Veel C++'ers denken dat VB totaal niet geschikt is voor games, en daar ben ik het dus 99% mee eens. Microsoft geeft zelfs officeel support sinds Dx7..en nu komt alles pas op gang

[Verwijderd]

ik heb wel wat ervaring met blitzbasic(en ook met darkbasic) blitzbasic is wat krachtiger en net zo simpel. je moet het je niet voorstellen zoals visual-basic, het is geen sleur eh pleur werk, je moet gewoon stukken code typen, alleen is het net ff wat gemakkelijker, je kunt er toch wel aardige dingen mee maken hoor. kijk maar op www.blitzbasic.com daar staan een aantal demo's.

[Creepy]

Op woensdag 12 juni 2002 15:31 schreef 41.6C.6D.61.72 het volgende:

[..]

Dat VB niet zo langzaam is als iedereen denkt, als je maar GOED programmeert in de taal zoals VB wil

Dit is iets wat natuurlijk voor elke taal geldt

bijv 80% xal niet het verschil tussen / en \ weten, de laatste is slechts 500 % sneller.. of 10 * 0.5 ipv. 10 / 0.2 (200% sneller), of x^2 en x*x (laatste 8000% sneller)

10*0,5 = 5
10 / 0.2 = 50

Overigens is bitshiften sneller dan delen of vermenigvuldigen.

Veel C++'ers denken dat VB totaal niet geschikt is voor games, en daar ben ik het dus 99% mee eens. Microsoft geeft zelfs officeel support sinds Dx7..en nu komt alles pas op gang

Je bedoelt oneens?? VB is best geschikt voor games hoor. Maar een FPS op een redelijke framerate, met collision detection etc.. daar is VB zelf niet echt geschikt voor..tenzij je weer gebruik gaat maken van wrappers e.d. Maar waar zijn die wrappers dan in geschreven???

Ook altijd leuk als er met FPS, tijden e.d. gesmeten wordt.. ik wil dan altijd graag de source van de 2 verschillende versies zien + fatsoenlijke benchmarks (dus niet allebij 1 keer runnen, maar allebei 1000 keer runnen...)

[Sponge]

Op woensdag 12 juni 2002 17:00 schreef Creepy het volgende:

[..]

Dit is iets wat natuurlijk voor elke taal geldt
[..]

10*0,5 = 5
10 / 0.2 = 50

Overigens is bitshiften sneller dan delen of vermenigvuldigen.
[..]

Sorry, ik was nogal aan het klooien met knippen & plakken, aangezien ik hier een marketing boek voor m'n toetsenbord heb om te leren moet 10 / 2 zijn uiteraard. Bitshift is idd 1 cycle, of 2

Je bedoelt oneens?? VB is best geschikt voor games hoor. Maar een FPS op een redelijke framerate, met collision detection etc.. daar is VB zelf niet echt geschikt voor..tenzij je weer gebruik gaat maken van wrappers e.d. Maar waar zijn die wrappers dan in geschreven???

Ook altijd leuk als er met FPS, tijden e.d. gesmeten wordt.. ik wil dan altijd graag de source van de 2 verschillende versies zien + fatsoenlijke benchmarks (dus niet allebij 1 keer runnen, maar allebei 1000 keer runnen...)

Yep oneens, ik wou neer zetten "niet mee eens". [De benchmarks van Vb Fibre zijn overigens 5*50000 (iteraties) ]getest.

[.oisyn]

geinspireerd door deze topic besloot ik maar weer eens een raytacer te bakken

en nu ga ik fijn een screenshot pluggen zonder dat jullie daar verder wat aan hebben
* .oisyn opgepast: ongeveer 250 kb *
(klik voor een grotere versie (1280x1024))

[Creepy]

Zit ik dan met m'n in OpenGL ronddraaiende getexturede kubus

[.oisyn]

kan ook heel mooi zijn

[Sponge]

Mooi, zeer mooi.

Ooit hoop ik dat raytracer realtime zijn werk kan doen, helaas zal dit nog wel een aantal jaartjes op zich wachten, en zitten we met triangles opgeschept. Voxels kunnen ook zeer interessant zijn, maar hebben ook totaal geen hardware ondersteuning

Trouwens, ik had een tweede versie geport van m'n raytracer met andere primitieve vormen, en het lukte ook nog eem een .X file te laden . Helaas duurde het wel eventjes...

[.oisyn]

Op vrijdag 14 juni 2002 10:08 schreef 41.6C.6D.61.72 het volgende:
Mooi, zeer mooi.

Ooit hoop ik dat raytracer realtime zijn werk kan doen, helaas zal dit nog wel een aantal jaartjes op zich wachten, en zitten we met triangles opgeschept.

op zich kan het nu al; de huidige gpu's zijn zo complex en snel dat het ook wel mogelijk moet zijn om een scene te renderen in real time (theoretisch bedoel ik dan; uiteraard kunnen ze nu niet raytracen). Alleen moet er niet al teveel detail in de scene zitten, waardoor we dus in principe weer achteruit gaan.

Aan de andere kant, de traditionele poly renderers kunnen tegenwoordig ook al bloedmooie plaatjes genereren. Dingen als reflection en refraction gaan nog niet echt, maar zijn wel te simuleren mbv respectievelijk environment maps en environmental bumpmapping

Voxels kunnen ook zeer interessant zijn, maar hebben ook totaal geen hardware ondersteuning

de nieuwe parhelia van matrox heeft de feature genaamd 'displacement mapping'. Daarmee kun je een heightmap gebruiken op een polygoon, wat dus practisch neerkomt op voxels

[Janoz]

Op vrijdag 14 juni 2002 10:08 schreef 41.6C.6D.61.72 het volgende:

Ooit hoop ik dat raytracer realtime zijn werk kan doen, helaas zal dit nog wel een aantal jaartjes op zich wachten, en zitten we met triangles opgeschept. Voxels kunnen ook zeer interessant zijn, maar hebben ook totaal geen hardware ondersteuning

_{* Janoz is in z'n nopjes nu er over DVR wordt gebabbeld}

Dat de hardware niet op een GeForce zit betekend nog niet dat ie d'r niet is. Er is op dit moment al best hardware beschikbaar voor Direct volumne rendering (het rechtstreeks renderen van voxels zonder triangulatie tussenstap). Ik heb ietsje terug nog iets gelezen van een hardware oplossing die een 256³ volume mbv shearwarp realtime kon renderen met genoeg framerates per seconde. Daarnaast is er ook een lib voor DVR beschikbaar voor SGI bakken.

DVR is dan wel niet hetzelfde als raytracing, maar het zit er dichter bij dan triangle meshes.

Als ik maandag weer op de Uni zit zal ik wel ff een screenshot posten van het DVR project waar ik nu zelf mee bezig ben.

[Sponge]

Hmm, als ik me goed herinner toen ik ooit eens met een 3D Package heb kunnen klooien, dat displacement een soort heightmap is over een platte grond (plane), en ja, de meestal voxel engines werken met zo een heightmap systeem, maar toch verschil tussen poly's en voxels zal wel zichtbaar blijven, een voxel is een 3D pixel, terwijl een poly een plat stuk is die een bepaalde rotatie heeft (okee, als je bij polygonen quad-divide, of sub-divide vaak genoeg doet krijg je vanzelf een voxel zowat

Die nieuwe matrox kaart ziet er inderdaad cool uit voor gamedev, maar NVidia gaat ook niet stil zitten, timing zal cruciaal zijn voor Matrox.

Probleem met raytracer is dat elke object met elk ander object gechecked moet worden, of het ervoor zit of niet..en dat kost eeuwen.

Trouwens, de GPU zou inderdaad misschien wel redelijk kunnen raytracen, maar het probleem is dat je niet low level met de GPU kunt werken, ten minste, niet dat ik weet. (nog nooit instruction sets gezien) Best wel eens interessant om eens mee te klooien als het zou kunnen, die Voodoo3 kan toch zowat wel de prullenbak in

[.oisyn]

Op vrijdag 14 juni 2002 14:08 schreef 41.6C.6D.61.72 het volgende:
Probleem met raytracer is dat elke object met elk ander object gechecked moet worden, of het ervoor zit of niet..en dat kost eeuwen.

ben ik het zeker niet mee eens, er zijn talloze optimalizaties uit te voeren om te kijken of er uberhaupt een bepaald object of objecten gecontroleerd hoeven te worden

denk aan bounding sphere trees, bounding box trees, octrees (groot bos wordt dat )

dit alles zorgt natuurlijk wel voor minder dynamiek, maar het is zeker niet O (n²)