Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

Language choosing help needed.

jeripedojeripedo Posts: 68Member
OK So far Ive sampled the following la nguages and been able to understand all of them.... C++, vb, adn playstation linux...... So ive been thinking and researching to no avail for the last two days on which of nthe three are better to make a game with.... I wanted to know if i can get some opions about these and maybe even what I should be researching on them... Like I know directx is a good one.... Thanks before hand..
[Size=5][blue]J[/blue][/size][size=3][red]eripedo[/red][/size]

Comments

  • GideonOmegaGideonOmega Posts: 617Member
    : OK So far Ive sampled the following la nguages and been able to understand all of them.... C++, vb, adn playstation linux...... So ive been thinking and researching to no avail for the last two days on which of nthe three are better to make a game with.... I wanted to know if i can get some opions about these and maybe even what I should be researching on them... Like I know directx is a good one.... Thanks before hand..
    : [Size=5][blue]J[/blue][/size][size=3][red]eripedo[/red][/size]
    :

    I don't know very much about making games myself, however I've always been interested in learning, as far as I know, most games are made with C++ - Probably due to it being a low level language, and a mixture of assembly I belive for making graphics engines - or at least that is what I've heard.
    [blue]
    C:Dos
    C:Dos Run
    Run Dos Run
    [/blue]

  • JonathanJonathan Posts: 2,914Member
    : : OK So far Ive sampled the following la nguages and been able to understand all of them.... C++, vb, adn playstation linux...... So ive been thinking and researching to no avail for the last two days on which of nthe three are better to make a game with.... I wanted to know if i can get some opions about these and maybe even what I should be researching on them... Like I know directx is a good one.... Thanks before hand..
    : : [Size=5][blue]J[/blue][/size][size=3][red]eripedo[/red][/size]
    : :
    :
    : I don't know very much about making games myself, however I've always been interested in learning, as far as I know, most games are made with C++ - Probably due to it being a low level language, and a mixture of assembly I belive for making graphics engines - or at least that is what I've heard.
    :
    DirectX can be used from both VB and C++. VB has the advantage of watching your back on various things and doing things for you (e.g. you can in many cases produce code faster in VB than in C++). However, performance is the price. Now, if your VB app is mostly passing stuff off to DirectX and you're not doing much of your own stuff VB may cut it. But if you want to do anything more fancy, you probably want to be looking at C++.

    Like was said above, you can also embed assembly in C/C++ code if you really need to. But cleanly written C (and to a slightly lesser degree, C++) will probably be good enought that you don't really have to do that. The stuff that needs to be really cutting fast (the graphics rendering) is probably in the main part going to be done for you by DirectX if you use that platform anyway.

    Just my 2 cents. IANAGH. (I am not a games hacker)

    Jonathan

    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

  • KDivad LeahcimKDivad Leahcim Posts: 3,948Member
    : DirectX can be used from both VB and C++. VB has the advantage of watching your back on various things and doing things for you (e.g. you can in many cases produce code faster in VB than in C++). However, performance is the price. Now, if your VB app is mostly passing stuff off to DirectX and you're not doing much of your own stuff VB may cut it. But if you want to do anything more fancy, you probably want to be looking at C++.
    :

    Genjuro and I have often argued about that. He seems convinced that VB's back-watching won't hurt the game unless you write very bad code (such as using strings to hold numbers). I'm not as convinced though I believe VB can get close when using DirectX.

    Anyway, with the right code, I bet you can get [italic]very[/italic] close to C performance (such as our switch to "char" arrays?).

    : Like was said above, you can also embed assembly in C/C++ code if you really need to.
    :

    You can in VB as well though it's trickier (wish I still had that ^%*$^ project...).
  • JonathanJonathan Posts: 2,914Member
    : : DirectX can be used from both VB and C++. VB has the advantage of watching your back on various things and doing things for you (e.g. you can in many cases produce code faster in VB than in C++). However, performance is the price. Now, if your VB app is mostly passing stuff off to DirectX and you're not doing much of your own stuff VB may cut it. But if you want to do anything more fancy, you probably want to be looking at C++.
    : :
    :
    : Genjuro and I have often argued about that. He seems convinced that
    : VB's back-watching won't hurt the game unless you write very bad
    : code (such as using strings to hold numbers). I'm not as convinced
    : though I believe VB can get close when using DirectX.
    :
    : Anyway, with the right code, I bet you can get [italic]very[/italic]
    : close to C performance (such as our switch to "char" arrays?).
    The way in which you write VB does have a big effect on performance, yes. That's something I've become more aware of. The problem I have is that the natural way to do something in VB generally won't be the one that performs well. The thing about "char" arrays is that we're just doing pretty much what C does, and abandoning VB's own string handling. So we're doing pretty much the same amount of grotty handling work we'd do if we were writing in C, and paying a performance penalty for using VB too.

    As for how close it gets - I'm not sure. But I do know the AMaMP mixdown engine runs one heck of a lot faster now it's written in C. The algorithm (on the surface at least) is pretty similar - in fact, the C one has more to handle. Maybe there will be optimisations we could have done in the VB one, but I'll bet we'd have had to jump through all kinds of hoops to do them.

    : : Like was said above, you can also embed assembly in C/C++ code if
    : : you really need to.
    : You can in VB as well though it's trickier (wish I still had that
    : ^%*$^ project...).
    Wish you'd shown it to me too... That way I'd be able to pass it back to you since you've lost your copy.

    Jonathan

    ###
    for(74,117,115,116){$::a.=chr};(($_.='qwertyui')&&
    (tr/yuiqwert/her anot/))for($::b);for($::c){$_.=$^X;
    /(p.{2}l)/;$_=$1}$::b=~/(..)$/;print("$::a$::b $::c hack$1.");

  • KDivad LeahcimKDivad Leahcim Posts: 3,948Member
    : The way in which you write VB does have a big effect on performance, yes. That's something I've become more aware of. The problem I have is that the natural way to do something in VB generally won't be the one that performs well. The thing about "char" arrays is that we're just doing pretty much what C does, and abandoning VB's own string handling. So we're doing pretty much the same amount of grotty handling work we'd do if we were writing in C, and paying a performance penalty for using VB too.
    :
    : As for how close it gets - I'm not sure. But I do know the AMaMP mixdown engine runs one heck of a lot faster now it's written in C. The algorithm (on the surface at least) is pretty similar - in fact, the C one has more to handle. Maybe there will be optimisations we could have done in the VB one, but I'll bet we'd have had to jump through all kinds of hoops to do them.
    :

    If I ever learn C, I'm going to have to write a comprehensive comparison test to find out. Much of C's ability is available in VB if one knows where/how to look so I could write relatively similar code for many things such as strings and chars. I'm pretty certain that with the right code, the mixer in VB would have been no more than 5% or 10% slower if that much. Not that the "If" at the beginning of this paragraph had extreme emphasis on it.

    : Wish you'd shown it to me too... That way I'd be able to pass it back to you since you've lost your copy.
    :

    Wonder how many other things I can pass to you for safekeeping? I only have about 820MB of "important" stuff... The important question: Would you still have it if I had sent it?

    Now, for those who want to know how to embed assembly in VB: You need to first get the compiled version of the code you want (not a whole exe, just the appropriate code). Next, you put it into a byte array (I swear the example I saw used a string, but VB's strings are supposed to be in unicode) somewhere in your code where it will be in-scope at the time you want it. Next, while it's in-scope, it needs to be vtable swapped. This means that a pre-existing function's pointer in the vtable has been overwritten with the new pointer (using CopyMemory and ObjPtr() to find the location to write to); in this case, the new pointer can be gotten by using [b]VarPtr(YourByteArray)[/b]. Finally, call the function as you normally would. VB will happily follow the pointer in the vtable apparently no matter what you put there (0& anybody?) so the new code will get executed. Assuming you do VB-friendly cleanup behind yourself, all should go beautifully.
  • dededede Posts: 145Member
    I believe C and C++ are powerful enough to code a game. Some programmer invloves Lisp if any artificial Intelligence is needed.
    dede:-)

Sign In or Register to comment.