[3d] opengl, direct3d - hoe leer je dat?

[Verwijderd]

Deleted.

[SG]

Op zondag 06 januari 2002 15:59 schreef Sigurd het volgende:
Hello,
Iemand zij, dat je met Visual Basic, niet de game quality can berijken dan met Visual Cpp.

Dit is niet waar omdat, wanneer de 3D ENGINE in VCpp en in ASM geschreven is, dan kan je gerust Visual Basic gebruiken voor de code or instructions to the engine.

Ja maar dat is niet VB maar nog altijd CPP/ASM

het gaat erom 'n 3D engine in VB is trager dan.

Je hebt het over 'n VB 3Dengine(CPP/ASM) wrapper.

De glue code
Dat is geen 3D VB engine.

Quake via 'n VB shell starten maakt het nog geen VB app als dat kan.

[.oisyn]

dan gebruik je toch nog C++!

Ik kan ook wel een game in C(++) schrijven, dat compilen naar een dlletje en dat opstarten in VB, maar dat wil natuurlijk niet zeggen dat dat spel in VB is gemaakt

Het ging erom dat je met puur VB (anders dan de API natuurlijk) niet kunt halen wat je met C(++) wel kunt

^{oh fuck ik zou niet meer reageren... effe vergeten}

.edit: nou ik was eerder!

[SG]

en /me typed al zo traag.

[Verwijderd]

Potdomme, ben ik helemaal vergeten DemoGL te pluggen!

http://www.demogl.com

[Verwijderd]

Deleted.

[SG]

Op zondag 06 januari 2002 17:14 schreef Sigurd het volgende:
Hello,

I think that's not the point.

DX and OPENGL is ALWAYS made in Cpp, so you say EVERY game even VB games is actually Cpp.

These are low level API for a veri flexible use with high performance in mind.

The point is ALL THE CODE YOU! MAKE is vb or not.

Not exectly, A 3D game engine is a high level abstaction layer with publish only the functionality that matter in jour specific use en is highly optimized for performance.

That means routines that are called a 1000 times per frame
if you make a realtime 3D app with high FPS goal

Visual Basic, is written in C++, so you can say VB is cpp and C is written in ASm, so you can say C is in ASM, but the point is what YOU use, and how simple it's for YOU.

But is the VB code optimized for performance think of MFC it is developed with flexibility in mind thus slow (overhead) but still C/CPP
De generated code footprint in VB is lager then CPP generated ASM.

The point is, that you can use Visual Basic, if you use TrueVision3D, Morfit, Revolution3D, Fly3D, ...

As framework or front-end
Initalizasion speed does not matter and sporadic call function to.

VB is use to 3D engine in a easy way. like a front-end in the back gound its CPP/ASM modules.

So, YOU! can make games with VB with a 3D engine, so actually you make a game with vb.

If jou use a profile tool like Vtune en see witch code are most use in the critical execution loop that would be CPP & ASM
You use VB to set up a high performance 3D engine witch is not made with VB.

Everything is always ASM, and everything is always machine language, so that statement of VB is wrong.
The VB Dll, is also a compiled Cpp dll, and the cpp dll's are also ASM dll's.

The asm of a C/C++ compiler is clean and closer to the machine code then VB.

VB compiler/interpreter generates ASM with a lot of overhead so its very flexible and userfriendly and easy to use but not for critical code

Anyway, It seems that I came into a newbie club.

Regards,
Sigurd

"your just a prima donna" Semi-Quote: Game architecture & design
/me is a newbie

[marcusk]

Op zondag 06 januari 2002 17:14 schreef Sigurd het volgende:
Visual Basic, is written in C++, so you can say VB is cpp and C is written in ASm, so you can say C is in ASM, but the point is what YOU use, and how simple it's for YOU.

Actually, modern C(++) compilers are written in C(++).

maargoed, beetje offtopic.

[.oisyn]

waarom ineens engels

anyway, het gaat erom dat apottjewijd wil coden in VB, en hij heeft in principe alleen de API zelf tot z'n beschikking (waarin ie ook gecode is). Als hij een uitgebreid spel wil maken dat snel loopt, dan zal ie dus zijn engine in C(++) moeten coden OF gebruik moeten maken van een andere engine. Aangezien apottjewijd wil weten hoe directx en/of opengl werkt ga ik ervan uit dat ie zelf zijn engine wilt coden. Als ie dat in VB wil doen dan moet ie dat zelf weten, maar hij moet wel beseffen dat ie met alleen VB lang niet alles eruit kan halen

[SG]

/me reageerde totaal offtopic op sigurd.

Maar Direct3d komt in twee flavors IMMEDIATE en R....

'N lowlevel API en een high level API bijde in C/C++/COM
De high level API is traag en niet optimized maar wel makkelijk in gebruik voor 'n snelle app inmekaar te frutdselen.
VB 3D proggen en dan dus PUUR 3D proggen dus ook critical code die 1000 keer per 5 millie seconden wordt aangeroepen is VB niet zo geschikt voor.Dat geld ook voor langzame CPP code dus MFC / retainmode

VB is de doel groep van de retain mode high level snel 'n app kunnen maken dus een korte time to market en met onderhuids 'n 3Dengine ook met de performance maar die komt niet van VB maar van de 3D engine.

Die meneer ontoppic wilt dus een 3D engine puur in VB maken.
op de low level API IMMIDIATE mode dat houd in veel critical code in VB

API<->VB APP // mister ontopic
API<->3DE<->VB APP Sigurd
API<->CPP(ASM) app // normal
API<->CPP(ASM)<->VB APP Sigurd

die van mister ontoppic is niet ene met veel FPS als die af is.

Van Sigurd is wel lekker flexible naar z'n clienten toe.
Applicatie programmers. met reuseable componenten 3Dengine dus.

[SG]

Op zondag 06 januari 2002 17:58 schreef OiSyN het volgende:
waarom ineens engels

anyway, het gaat erom dat apottjewijd wil coden in VB, en hij heeft in principe alleen de API zelf tot z'n beschikking (waarin ie ook gecode is). Als hij een uitgebreid spel wil maken dat snel loopt, dan zal ie dus zijn engine in C(++) moeten coden OF gebruik moeten maken van een andere engine. Aangezien apottjewijd wil weten hoe directx en/of opengl werkt ga ik ervan uit dat ie zelf zijn engine wilt coden. Als ie dat in VB wil doen dan moet ie dat zelf weten, maar hij moet wel beseffen dat ie met alleen VB lang niet alles eruit kan halen

Of recommended P4 2,8 of Hammer 2ghz

Alleen is dat target platform er nog niet misschien wel over een jaar of 3 is dat mainstream.
Software houd de CPU wedloop momenteel niet bij.
CPU zíjn momenteel krachtig genoeg dat ASM optimalisatie ook steeds minder wordt en de performance hit afgewogen wordt.
Pure ASM applicaties zijn er niet meer zoveel als vroeger of helemaal niet meer.
Alleen wordt tegenwoordig ASM alleen nog voor specificke routines gebruikt in 3D game apps .

[Verwijderd]

Removed.

[marcusk]

Op zondag 06 januari 2002 18:33 schreef Sigurd het volgende:
All replies posts deleted.

lekker nuttig

@marcusk,
Keep your comments, when you have nothing good to say.
Compilers maakt niet uit, de Cpp dll's en VB dll's zijn op ...bla bla bla...

je zei zelf:

Visual Basic, is written in C++, so you can say VB is cpp and C is written in ASm

Maar de taal C is dus niet in ASM geschreven.

[Verwijderd]

Removed.

[marcusk]

(Nu weer in het engels?)

Op zondag 06 januari 2002 19:00 schreef Sigurd het volgende:
I guess, you just try to make fun of this, so bye

Je voelt je wel snel aangevallen zeg. Maargoed, ik had je blijkbaar verkeerd begrepen, dus laat maar zitten.

[SiNisTrAD]

hmmm even het ongezellige doorbreken ...
[beetje offtopic]
wat ik erg leuk vindt om mee te kloten is Darkbasic
http://www.darkbasic.com

Dit is leuk om een keer te doen als je met 3d wilt spelen
[/beetje offtopic]

[SG]

Op zondag 06 januari 2002 18:33 schreef Sigurd het volgende:
All replies posts deleted.

Dan zalk ik je effe quoten

@SuperG, your arguments, are SHIT!
Anway, I deleted my posts, and I'm gone of here

Als mijn argument zogenaamd shit zijn, dan moet dat makkelijk te weerleggen zijn met 'n goed tegen argument .
En aangezien je daaraan niet kan voldoen, niet tegen kritiek kan, wel meteen persoonlijk aangevallen voeld en meteen beledigd, wat wel vaker voorkomt op 'n forum wat ik dus wel hebben kan.

Dit is dus geen argument maar zeer persoonlijk.

Who's is full of shit

Iedere proffesionele developer weet dat hier iedereen en nogwat replyed dus waar heb je last van PMS

TrueVIsion3D was lang bekend, omdat het PUUR vb code was, en dat het ook open source was.
Later hebben we het closed source gemaakt, en nog lang vb code alleen gehouden.

Wat was dan de Doelgroep noem es retail apps die ervan gebruik hebben gemaakt van de oude en nieuwe situatie.

Pas +- 8 maand is er ASm code in de engine, en pas een paar maand Cpp code, en nu gaat vb code weg.

Dat zegt toch alles, waarom denk je.
ASM hand coded is het snelste maar ook het moeilijkst en tijdrovend. Blijkbaar zijn sommige collega's van jouw het niet eens met jouw.
En nu dan ook nog es CPP code.

Maar de screenshots op de site http://www.gabita.com of http://users.pandora.be/GabitaSoft/screenshots.html zijn 90% vb, de 3DS files loading en de blending filter is cpp.
En, ja dat heeft 51+ FPS (frames a second).
(een goed game, moet minstens 20 fps hebben, 30 fps is gewenst)

Dat zegt mij niks uit welke contexed komt dit een beta Game klaar voor release of 'n feature demo.
Feature demo's halen vaak 100+ frames als ze game optimized zijn.
'n released Game demo hoort 60+ fps afhankelijk van game genre te halen bij recommende targed systeem.

zal het 'n keer checken als ik tijd heb.

En uw RM, IM comments zijn OUT OF DATE, DX8 heeft geen RM meer, alleen IM, en Direct Draw is er ook niet meer, alles is 1 geheel.

DirectX is COM based Directdraw is er wel alles wat gecompileerd wordt met DX7 SDK pakt de DX7 interface die ook in DX8 zit. Pas als je app de DX8 interface gebruikt krijg je te maken met die grondige wijziging.

Ik gebruik de DX7 SDK met de DX8 runtime dus ook DirectDraw

@marcusk,
Keep your comments, when you have nothing good to say.
Compilers maakt niet uit, de Cpp dll's en VB dll's zijn op een andere taal gebaseerd en die vertragen het.

Dit is een open forum dus je hoeft niet perse in het vakgebied zitten waar deze topic overgaat d'r zijn hier ook hobbyisten of gewoon geintterseerden.

Met vb kan je een compiler interceptor maken, en de asm sneller maken, maar de vb main dll word NIET sneller, ook niet van cpp/windows.

De compiler heeft er NIETS met te maken, een compiler mag zelfs 1000000000000 keer te traag zijn, dan het zou moeten.

Ik heb het over de ASM code of oject code die 'n compiler genereerd en hoe efficient die code is. Waar slaat dit overdreven gedoe op of leg uit VB guru.

TrueVision3D is registrated bij NVidia, Microsoft, lid van Microsoft DX Dev Team Discussion, ... dus ik weet wat ik zeg, maar jullie dus duidelijk NIET.

Ja en hoef je niemand te beledigen wat zegt dat nou eigenlijk?

Deze post, word verwijderd, samen met al mijn andere posts, binnen de 3 uur.

Bye,
Sigurd De Keyser
TrueVision3D Developer

Behalve gequote reply's

[mbravenboer]

Dit is niet echt mijn topic, maar ik lees af en toe een beetje mee.

Misschien is het voor jullie zelf en zeker voor eventuele andere meelezers nuttig als jullie je talenten, capaciteiten en tijd gebruiken om een zinvolle, inhoudelijke en interessante discussie te voeren ipv elkaar af te zeiken? Voor dat laatste is /14 namelijk niet voor bedoeld .

[SG]

Op zondag 06 januari 2002 20:06 schreef mbravenboer het volgende:
Dit is niet echt mijn topic, maar ik lees af en toe een beetje mee.

Ik ook en toen zag ik de reply van sigurd en ik was er niet geheel mee ens dus een kritische noot met argument heel normaal toch. Maar dan zijn reactie daarop !!!!?

Misschien is het voor jullie zelf en zeker voor eventuele andere meelezers nuttig als jullie je talenten, capaciteiten en tijd gebruiken om een zinvolle, inhoudelijke en interessante discussie te voeren ipv elkaar af te zeiken? Voor dat laatste is /14 namelijk niet voor bedoeld .

Nou het laaste deel van deze one way discussie ging over of VB geshikt is voor 'n 3Dengine waar mister ontoppic mee bezig is. Dus erg ontoppic

Sigurd bijdrage is dat VB goed als APP framework kan dienen voor 'n 3Dgame engine voor snel en easy 'n 3D VB app in elkaar te zetten, dus er zaten goeie argementen bij alleen drong mijn punt er niet door en zat ie eromheen te draaien ipv gericht te argumenten op 'n relaxte manier.

Want VB compilers worden ook steeds verbeterd toch.

[mbravenboer]

SuperG: zijn reactie

Merk op dat ik niemand persoonlijk noem, zie het meer als een algemene oproep . Helaas kwam mijn post na die van jou, maar dat wil niet zeggen dat ik alleen op jou doel .

Want VB compilers worden ook steeds verbeterd toch.

Ach, compilers in het algemeen worden steeds beter. Zelfs VB compilers zullen dus beter worden .

[marcusk]

om nog meer offtopic te gaan :

mbravenboer, heb je mijn 2e mail (reply) wel gekregen?

[.oisyn]

waarom heeft die sigurd gast al z'n posts verwijderd?
Damn hij is wel heel erg triest...

[Verwijderd]

Op maandag 07 januari 2002 00:42 schreef OiSyN het volgende:
waarom heeft die sigurd gast al z'n posts verwijderd?
Damn hij is wel heel erg triest...

Jammer dat ie niet al de quote's kan wissen... dan had het ook nog nut gehad

[Verwijderd]

Op zondag 06 januari 2002 20:06 schreef mbravenboer het volgende:
Dit is niet echt mijn topic, maar ik lees af en toe een beetje mee.

Misschien is het voor jullie zelf en zeker voor eventuele andere meelezers nuttig als jullie je talenten, capaciteiten en tijd gebruiken om een zinvolle, inhoudelijke en interessante discussie te voeren ipv elkaar af te zeiken? Voor dat laatste is /14 namelijk niet voor bedoeld .

Een topictitel 'hoe leer je dat?' waarin veel info wordt gespuugd lijkt me niet gelijk staan aan 'afzeiken'. Dat de topicstarter niet snapt wat je moet doen met aangedragen info is niet het probleem van de mensen die hem die info aandragen. Als je een discussie wilt over 3D programming dan zou ik willen zeggen: start een nieuwe thread .

En denk je ook niet dat een moderator op de stoel zit anderen vermanend toe te spreken hoe ze zich moeten gedragen? Of voel je jezelf daartoe geroepen?

[mbravenboer]

Otis: Een topictitel 'hoe leer je dat?' waarin veel info wordt gespuugd lijkt me niet gelijk staan aan 'afzeiken'.

Ik doelde absoluut niet op pagina 1 t/m 11. De laatste 2 pagina's gaan echter nergens meer over dan Sigurd versus SuperG zonder dat er iets zinnigs wordt gezegd. Engels er tussendoor en een paar mensen die nog serieus proberen te reageren zorgen voor de rest van de chaos.

Maar goed, deze discussie draagt ook nergens toe bij. Kennelijk was ik niet duidelijk genoeg .

Of voel je jezelf daartoe geroepen?

Ja, als ik op straat iemand anders zich zie misdragen zeg ik daar ook wat van. Dat is niet alleen de taak van de politie. /14 is ook mijn speeltuin en ik heb er zelf belang bij dat het daar leuk is.

[wasigh]

Op maandag 07 januari 2002 10:39 schreef Otis het volgende:

En denk je ook niet dat een moderator op de stoel zit anderen vermanend toe te spreken hoe ze zich moeten gedragen? Of voel je jezelf daartoe geroepen?

Mods zijn niets meer als user met extra rechten.

P&W wordt gemaakt door de vaste bezoekers. En ik heb niets liever dan dat vaste bezoekers op een constructieve manier bijdragen proberen te leveren aan /14.

Dat je hier mbravenboer op zijn plek wil wijzen vindt ik dan ok niet terecht.

Ik hou deze thread in de gaten, als ie nog langer offtopic gaat moet ie helaas dicht.

[Verwijderd]

Op maandag 07 januari 2002 11:22 schreef wasigh het volgende:
[..]
Mods zijn niets meer als user met extra rechten.

P&W wordt gemaakt door de vaste bezoekers. En ik heb niets liever dan dat vaste bezoekers op een constructieve manier bijdragen proberen te leveren aan /14.

Dat je hier mbravenboer op zijn plek wil wijzen vindt ik dan ok niet terecht.

Dat zal best, maar hij sprak niet mensen in het bizonder aan, maar algemeen de mensen in de thread. Terwijl hij niet meedeed aan de thread. Bravenboer weet echt wel hoe fora werken en als je geinteresseerd bent in bepaalde info moet je een thread starten met een vraag en dan krijg je antwoord en met wat voedende vragen wellicht een leuke discussie. En ervaring leert dat Bravenboer dat echt wel kan.

Nu de mensen die in de thread rondhangen als user vermanend toespreken schiet mij in het verkeerde keelsgat. Tuurlijk, trollen, flamen etc. lijkt me niet gewenst maar de discussie was al veel eerder ontspoord en ZEKER NIET door de mensen die aan de thread deelnamen, maar die sprak hij wel aan middels zn posting. Ik vind het prima als een daarvoor aangewezen persoon dat doet, maar als iemand die niet meedoet aan de discussie ook mij even komt melden dat er van een interessante discussie geen sprake meer is en dat dat aan ook mij te wijten is, vind ik dat veel te ver gaan. Als Bravenboer dat werk interessant vindt moet hij solliciteren bij de GoT raad en wellicht is er een plek vrij als hulp-modje.

[mbravenboer]

Otis vond van niet

Ik was inderdaad niet helemaal duidelijk in mijn opmerking en ik had beter moeten aangeven wat ik bedoelde.

Wat vinden we elkaar toch lief he? .

[Verwijderd]

ik droom elke nacht van je

[wasigh]

Otis: ik zie het verschil niet tussen een user die terechtwijst en een modje. En vindt de opmerking van mbravenboer terecht.

maar laten we vooral niet van een mug een olifant maken.
Laatste poging om deze thread weer ontopic te krijgen: verder commentaar graag in LA, ICQ, MSN of m'n mailbox

[SG]

Sigurd was erg ontopic bezig helaas heeft ie z'n eerste ontopic reply gedelete waardoor de volg-op reply raar lijken vooral omdat ik maar 'n klein stukje gequote heb.

Om Sigurd standpunt te volgel moet je zijn links volgen in een van de opvolgende gequote repleys en daar kom je 'n 3D engine tegen voor VB users.

Tenzij Apottjewijd bedoeling is om echt zelf 'n 3Dengine te bouwen met VB dan is het offtopic of dat hij 'n VB 3D GAme wil ontwikkelen dan is dat best wel 'n interresante site voor hem dus dan wel erg ontoppic.

Het gaat om code reuse 3D engine ontwikken kost tijd en komt er eigenlijk op neer het wiel konstand op nieuw uit te vinden.

Kan je beter code rusen van mensen die er veel tijd in hebben gestoken dus ook van hoge qualiteit en functionaliteit en veel huidige supporte hardware features.

Heb zelf al op de site effe rond gekeken.
Erg interresant voor VB users dus ook de topic starter

Sigmund is 'n jochie van 15/16 jaar??? Zie site en de 3D Engine ontwikkelaar ook van die leeftijd.

http://www.gabita.com
http://users.pandora.be/GabitaSoft/screenshots.html

[Verwijderd]

Hello,

My Excuses, for my side.
(Sorry voor de mensen die engels haten of er niet al te best in zijn, maar engels is de beste taal waar ik mij kan uitdrukken met computer termen.)

Let's start from ZERO.

Ik had een vraag, ik ben al een paar jaar Delphi / VB / Web programmeur, en dat gaat me allemaal goed af. Maar nou wil ik voor mezelf thuis als hobbie eens een 3D game gaan bouwen ( beetje quake a la prutser ), gewoon voor de lol.
Dus ik ben me gaan verdiepen in VB, maar zie dan al snel dat ik ook mezelf in OpenGL en DirectX moet gaan verdiepen. Maar nou vroeg ik me af of dat ook mogelijk is zonder een mega- wiskunde expert te zijn. Gewoon met 3D studio of iets dergelijks een leuk 3D frame tekenen lukt me wel een beetje, maar om dat wiskundig met termen als matrixen enzo te gaan doen??? M'n hoofd begint al te tollen als ik dat doorlees, maar toch wil ik graag zoiets bouwen ( ook al ben ik een wiskunde 0 ). Is dit voor mij gewoon niet te doen, of is het ook zonder Einstein wiskunde nog te doen? Iemand enige ervaring hiermee? Tips waar ik het beste mee kan beginnen om te leren? Ik wil het het liefst toch in VB gaan maken, is dit zowieso mogelijk of moet ik dan echt C of C ++ gaan leren? Bedankt alvast, en sorry voor de lange topic.

First of all, I started with answering to the person, that you can't create (good quality)GAMES with vb (like in cpp)(no ones said, without using tools, or engine, because DirectX is ALSO an engine, written in Cpp, only it isn't using an other tool except main dll's (and yes some code of other companies and few dll's).).

You can create same quality games in vb, ok yes some code has to be done in cpp, but my argument was, that EVERYTHING comes to an end in ASM, EVERYTHING is linked, and ASM to the hardware.
The point is, that YOU can create a game(what the main person wants, who started the topic), and that you do as less as posible, and that you STILL have the freedom as using direcly DX, only less difficulties and more user friendly users interface.

In this case, is using VCPP only good, when you're trying to create your own engine or special software, that can't use an engine for some reasons.


The TrueVision3D engine, or other engines will handle Matrices, A lot of math and other stuff for you, including most dx work.
Ofcourse they still provide intern objects to create features on the engine, who're not supported by default.

So, this is what I wanted to say as main part.

ofcourse, when people slam compilers stuff into my face and starting about "that it isn't right what I said", then I think I may smash *with facts* back, and yes I includes words, that may hurt some other peoples feelings.

Maybe my answer wasn't pointed at the latest replies, but global to the whole topic including some replies, so when you didn't readed/understood everything then you couldn't understand it right, but I understand that it's sometimes confusing, sorry for that.

>>Sigmund is 'n jochie van 15/16 jaar??? Zie site en de 3D
>>Engine ontwikkelaar ook van die leeftijd.

In fact, yes I'm 16 and I hope you don't mind.
I work with people who're older and who're professionals.
Just wait till TrueVision3D 6 releases .
The engine will be a candy for the eye .

You can't judge people on their age, people with a normal IQ at my age, will have problems with this or can just folow a little, but other people, more weard (like me) who get at school 81% for math, they know what they talk about.

Anyway, with short words, is my suggestion to the topic writer: Use an engine, or a prebuild code, to use for building your game.
And to people with their comments like VB is too bad, or Cpp can do 10 times more, well I hate those people (sorry), but always look at the bright side, and take the GOOD posibilities and use them.

Cya,
Sigurd

[.oisyn]

Op dinsdag 08 januari 2002 00:24 schreef Sigurd het volgende:
You can create same quality games in vb, ok yes some code has to be done in cpp, but my argument was, that EVERYTHING comes to an end in ASM, EVERYTHING is linked, and ASM to the hardware.

weet je wat het is, de taal VB laat het gewoon niet toe om snel te coden, ook al maak je er asm van. Dat is omdat er op de achtergrond gewoon veel meer gebeurt dan je intiept, in tegenstelling tot bijvoorbeeld een taal als C(++), waarin je alles zelf moet doen (dus totale controle over wat er gebeurt)

dat is het essentiele verschil tussen VB en C(++)

Maar goed, als je dus een complete game engine gebruikt en de game logic en GUIs enzo maak je in VB, dan ben ik er niet mee eens dat je dan kunt zeggen dat het spel in VB geprogrammeerd is. Quake1 is tenslotte ook niet in QuakeC gemaakt, en zo zijn er nog talloze spellen die scripting gebruiken voor de gamelogic enzo. Ja, natuurlijk kun je daar ook VB voor gebruiken, maar daar gaat het hier helemaal niet om, we hadden het tenslotte over het enginewerk zelf, en daar is waar VB tekort schiet

[wasigh]

Op dinsdag 08 januari 2002 00:24 schreef Sigurd het volgende:

My Excuses, for my side.
(Sorry voor de mensen die engels haten of er niet al te best in zijn, maar engels is de beste taal waar ik mij kan uitdrukken met computer termen.)

Ik vraag je toch voor de laatste keer vriendelijk om het in het Nederlands te doen. GoT is een Nederlands forum en als je liever in een andere taal wilt discussieren dan zou ik een ander forum zoeken.

nb. groet onder je post hoeft niet, zie daarvoor ook de faq

[Verwijderd]

Op dinsdag 08 januari 2002 01:28 schreef OiSyN het volgende:
[..]
weet je wat het is, de taal VB laat het gewoon niet toe om snel te coden, ook al maak je er asm van. Dat is omdat er op de achtergrond gewoon veel meer gebeurt dan je intiept, in tegenstelling tot bijvoorbeeld een taal als C(++), waarin je alles zelf moet doen (dus totale controle over wat er gebeurt)

Dit is natuurlijk onzin. Als ik intik in VB:

code:

Dim oObject as MyPackage.clsMyClass

set oObject = CreateObject("MyPackage.clsMyClass")

dan is de C++ variant zo'n 3 regels langer geloof ik, en indien je smart pointers gebruikt zelfs even lang. De code die gegenereerd wordt met bv smart pointers, is zeker geen 1:1 afbeelding van je C++ code, integendeel.

Tuurlijk, als ik een rijtje int's heb in C/C++ en ik sjouw daar doorheen met een for() lusje waarin ik die ints bewerk met een berekening, dan is dat sneller dan in VB. Waarom? Omdat in VB de code wordt uitgebreid met runtime checks, wat je overigens kunt uitzetten. In C++ krijg je meer een 1:1 afbeelding naar machinecode maar ook daar moet je oppassen met deze bewering, want lang altijd is de gegenereerde code veel complexer dan de C++ code. Immers, dat is de reden waarom je uberhaupt een hogere orde taal gebruikt.

dat is het essentiele verschil tussen VB en C(++)

Nee. Het essentiele verschil met VB en C++ is dat in VB de compiler code genereert die een VM gebruikt en C++ native naar je doelhw platform compileert. De VB VM is wel erg plat, maar wel aanwezig. Vandaar dat sommige dingen niet kunnen in VB of trager verlopen dan wanneer je de C++ equivalent gebruikt. Heeft niets te maken met dat er wellicht meer gebeurt op de achtergrond dan je intypt, want dat is bij de gemiddelde C++ compiler ook echt het geval.

Maar goed, als je dus een complete game engine gebruikt en de game logic en GUIs enzo maak je in VB, dan ben ik er niet mee eens dat je dan kunt zeggen dat het spel in VB geprogrammeerd is. Quake1 is tenslotte ook niet in QuakeC gemaakt, en zo zijn er nog talloze spellen die scripting gebruiken voor de gamelogic enzo. Ja, natuurlijk kun je daar ook VB voor gebruiken, maar daar gaat het hier helemaal niet om, we hadden het tenslotte over het enginewerk zelf, en daar is waar VB tekort schiet

Wat is dat enginewerk dan? polygonen pushen door een DX interface? Waarom zou VB daar een bottleneck zijn? Het eigenlijke werk wordt immers gedaan door de DX driver/hardware. Hetzelfde verhaal hoor ik altijd van C++ programmeurs die database applicaties maken in C++ en niet in VB, omdat C++ vele malen sneller zou zijn. Als je dan profiled, zie je dat in beide gevallen de meeste tijd in de database wordt doorgebracht en niet in de eigen code.

Praat je over scenegraphs (dus de database zelf) in VB maken, dan geef ik je groot gelijk als je zegt dat VB daar tekort schiet. Puur omdat de compiler naar een VM compileert die altijd in de weg zit en performance vreet die je wellicht nodig hebt. Echter... voor quake2 achtige scenegraphs (dus paar duizend poly bsp's) betwijfel ik of je het merkt.

[.oisyn]

Op dinsdag 08 januari 2002 10:50 schreef Otis het volgende:

[..]

Dit is natuurlijk onzin. Als ik intik in VB:

code:

Dim oObject as MyPackage.clsMyClass

set oObject = CreateObject("MyPackage.clsMyClass")

dan is de C++ variant zo'n 3 regels langer geloof ik, en indien je smart pointers gebruikt zelfs even lang. De code die gegenereerd wordt met bv smart pointers, is zeker geen 1:1 afbeelding van je C++ code, integendeel.

Het verschil is dat je in C++ een pure pointer hebt naar je object zonder enige typechecking, en dat heb je in VB wel. Bovendien zijn alle members van die vieze properties met get en let functies, zodat het lijkt alsof je een variabele assigned, maar ondertussen wordt er gewoon een functie aangeroepen

Tuurlijk, als ik een rijtje int's heb in C/C++ en ik sjouw daar doorheen met een for() lusje waarin ik die ints bewerk met een berekening, dan is dat sneller dan in VB. Waarom? Omdat in VB de code wordt uitgebreid met runtime checks, wat je overigens kunt uitzetten.

en dat is ook precies waar ik op doel

Nee. Het essentiele verschil met VB en C++ is dat in VB de compiler code genereert die een VM gebruikt en C++ native naar je doelhw platform compileert. de VB VM is wel erg plat, maar wel aanwezig. Vandaar dat sommige dingen niet kunnen in VB of trager verlopen dan wanneer je de C++ equivalent gebruikt.

Je kan al sinds VB 4 (geloof ik, anders 5) compilen naar native code (dus niet naar P-code), en dus hoeft het ook niet meer geinterpreteerd te worden

Heeft niets te maken met dat er wellicht meer gebeurt op de achtergrond dan je intypt, want dat is bij de gemiddelde C++ compiler ook echt het geval.

zeker wel, juist door al die checks die VB uitvoert (je kunt ze niet allemaal uitzetten)

Wat is dat enginewerk dan? polygonen pushen door een DX interface? Waarom zou VB daar een bottleneck zijn? Het eigenlijke werk wordt immers gedaan door de DX driver/hardware. Hetzelfde verhaal hoor ik altijd van C++ programmeurs die database applicaties maken in C++ en niet in VB, omdat C++ vele malen sneller zou zijn.

nee niet het pushen zelf, maar visible surface determination en zware berekeningen als physics en collision detection. In VB kun je gewoon niet snel genoeg door je data heen vliegen en berekeningen erop uitvoeren

Praat je over scenegraphs (dus de database zelf) in VB maken, dan geef ik je groot gelijk als je zegt dat VB daar tekort schiet. Puur omdat de compiler naar een VM compileert die altijd in de weg zit en performance vreet die je wellicht nodig hebt. Echter... voor quake2 achtige scenegraphs (dus paar duizend poly bsp's) betwijfel ik of je het merkt.

oh damn, ik had niet genoeg vooruit gelezen. Ja ik bedoelde dus onder andere scenegraphs
Idd, een graph van het formaat van quake2 is nu wel goed te doen in VB, maar quake2 is erg lang geleden (3dfx tijdperk). Toen waren de computers gewoon veel trager dan nu (pentium 166 was toen geloof ik mainstream), en toen was het dan ook niet te doen in VB (maar ja, toen was sowieso al niet echt veel te doen in VB ).

Misschien is datgene waar ik op doel niet helemaal duidelijk, namelijk niet dat spellen niet te maken zijn in VB (zijn ze tenslotte wel), maar dat je in VB nooit eruit kunt halen wat je er in een taal als C(++) eruit kunt halen

[Verwijderd]

De VB Compiler compileert wel naar native x86 maar gebruikt veel calls in de MSVBVM60.dll, de runtime, iets wat je in C++ niet hebt. Een variable optellen gaat wel in native code, maar veel statements zijn functies, calls in de VM dus. Vandaar de tragere executie.

Ik vind get en let propertie gevallen erg handig, want je genereert ze zo makkelijk . Ik zou overigens ook geen VB kiezen voor rekentechnisch zware applicaties hoor. Iedere taal/omgeving heeft zn pluspunten, en juist de wat zwakkere punten gaan uitbuiten lijkt me niet zo slim

[Verwijderd]

Hello,

Voor de persoon, die het in het nederlands wou horen:
"Sorry voor mijn posts ervoor"

En dan even antwoorden op de paar posts erboven.

Wel, Inderdaad is Visual Basic trager, en yep vb compiled ook naar ASM, maar is zo generic(algemeen) dat het meer code moet toevoegen, en dat het daarom vertraagt.

VB gebruiken voor een eigen engine te maken die unreal 2 moet verslagen is inderdaad niet mogelijk, dus zoals iemand erboven heeft gezecht dat je het daar ook niet voor moet uitbuiten is 100% juist.

VB is een Interface friendly en Fast Time coding programma.

Wanneer je de moeilijke code in Cpp maakt en de interface of andere gedeelte, die niet uitmaken hoe snel te zijn, kan je dagen uitsparen, zoals de makers van de Unreal editor, veel mensen gebruiken Visual Basic, omdat ze niet dagen willen verliezen om het in Cpp te maken, warop je het in VB gewoon in een kwartier kan doen. (niet beginnen zagen dat je het even snel kan in Cpp, maar ik denk dat je wel weet wat ik bedoel)

Ook voor games is VB heel handig, daar gebruiken sommige engines, zoals diegene waar ik met mee werk, handig gebruik van.
VB legt dan gewoon de links dussen de functies en stuurt de juiste commandos op het juiste moment naar de engine.

Op deze manier, kunnen mensen op zeer korte tijd, zeer goede 3d programma's en ook games maken, en nog steeds naar hun eigen goesting en keuze.

Elke taal heeft voordelen, en een taal afkraken heeft geen nut, ik ben ook een C++ programmeuer, en ik wil het voor geen geld stoppen met gebruiken; maar als iemand mij vraagt een stoem rekenmachine te maken, of gewoon een programma voor de kas&stock van een kapper bij te houden, dan gebruik ik gewoon VB.

Dus, Ik denk dat het de meeste hier nu wel eens zijn, en sommige veel uit deze topic kan leren.

Eigenlijk is gewoon VB het overgestelde van ASM.

ASM << Kost veel tijd om iets te maken, maar je kan ZEER goede resultaten berijken
Cpp << Gemiddelde tijd voor iets te maken, en je kan ook goede resultaten berijken maar iets minder dan ASM
VB << Kost weinig tijd om iets te maken, en je kan goede resultaten halen zoals in Cpp, maar je word meer beperkt en de berekeningen zijn trager.
(Om een discutie niet te laten gebeuren, zal ik ook zeggen waarom ik vind dat VB beperkt is, omdat je niet direct toegang tot alles hebt, je kan met WinApi stuff gaan veranderen, maar met Cpp is alles meer gewoon normaal, in vb is Winapi meer iets apart.)

Vriendelijke Groeten,
Sigurd

[Verwijderd]

3D Programmeren in .NET is echt fantastisch, ze hebben zelfs een hele mooie demo erbij gegeven, helemaal gemaakt in .NET. Link:

http://msdn.microsoft.com/vbasic/donkey.asp

Is echt snel en leuk! Veel plezier.

[Scorpion]

aaaaaaargh! toch niet weer he!

[Verwijderd]

Is het nog steeds zo in VB dat als je het volgende intypt:

code:

Dim I As Integer

En het compileert dat stiekum intern wordt gelezen:

code:

Dim I As Variant

Zou namelijk heel veel verklaren (traagheid van VB6)!

[Verwijderd]

Op dinsdag 26 februari 2002 11:51 schreef hvdberg het volgende:
Is het nog steeds zo in VB dat als je het volgende intypt:

code:

Dim I As Integer

En het compileert dat stiekum intern wordt gelezen:

code:

Dim I As Variant

Zou namelijk heel veel verklaren (traagheid van VB6)!

Nee, in .net helemaal niet meer, het was in VB6 wel zo dat als je zei:

Dim A,B,C as Integer

Dat A en B als varianten werden gedeclareerd, en alleen C als een integer. In .NET is in dit voorbeeld dan ook echt alles als integer gedeclareerd, alleen de integer is in .net een short geworden, de integer staat gelijk aan de VB6 long. 3D applicaties in .NET draaien echt fantastisch.

[Verwijderd]

Op dinsdag 26 februari 2002 12:11 schreef Mammaplank het volgende:
Nee, in .net helemaal niet meer, het was in VB6 wel zo dat als je zei:

Dim A,B,C as Integer

Dat A en B als varianten werden gedeclareerd, en alleen C als een integer. In .NET is in dit voorbeeld dan ook echt alles als integer gedeclareerd, alleen de integer is in .net een short geworden, de integer staat gelijk aan de VB6 long. 3D applicaties in .NET draaien echt fantastisch.

Zo bedoelde ik het dus precies (Dim A,B,C As Integer). Dat ze van de integer een 32-bit integer hebben gemaakt lijkt me niet meer dan logisch (geheel andere discussie).

VB.Net lijkt me idd een heel stuk beter maar C# lijkt me wat betreft 3D helemaal toppie.

[.oisyn]

en ik zou geen van beiden gebruiken voor 3d

[wasigh]

He wat is dat?
een 3d slot??


sorry, maar dit topic brengt teveel nare gevoelens boven