Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 31

Thread: C++ Help

  1. #21
    AO Antique pwaring's Avatar
    Join Date
    Aug 2001
    Posts
    1,409
    Originally posted here by progme


    No not all but if you go and work at any software house that produces software of any reasonable size it will. I can't think of one project that I've worked on in the last four years that wasn't compiled overnight. This is just my experience though working on industry strength software.
    Define "reasonable size". A program doesn't have to require overnight compilation to be considered industrial strength software.

    Sure I remember quake, I also remember the days when there wasn't parallel processing and all graphics rendering was done in software on the CPU.
    Most PCs today only have one CPU, so parallel processing still isn't an option for the fast majority of people.

    And I wasn't saying that speed is the most important factor in programming any more, but it is certainly not a petty one as you stated it to be.
    Paul Waring - Web site design and development.

  2. #22
    Junior Member
    Join Date
    Oct 2003
    Posts
    14
    Originally posted here by pwaring

    Define "reasonable size". A program doesn't have to require overnight compilation to be considered industrial strength software.
    I suppose not and this is also my personal experience working at software houses. I certainly don't constitute for all software development houses but I can speak for the ones I have worked at. If you would like to offer counter-evidance to support your argument rather then no it doesn't please post them now.

    Most PCs today only have one CPU, so parallel processing still isn't an option for the fast majority of people.
    PC's definatly have more then one CPU, the sound card will have a CPU your graphics card will have a CPU and if it's a modern graphics card it will have a programmable CPU. When I was refering to paralllel processing I meant that as the game was handling it's logic/physics the graphics card was rendering to the screen. The way games today work is this:

    1) Handle input
    2) Handle Logic
    3) Handle Physics
    4) Batch all responce sounds and send the to the sound card to be processed( 3d sounds, dongle effects..)
    5) Batch all 3d data together and send to the graphic card to be rendered
    6) LOOP

    Step 4/5 use to be a much longer process because games didn't have any CPU's that could handle 3d Sounds and graphics. Thankfully all of the rendering is done on the GPU(graphics card processor unit) and this leaves the programmer to only worry about step 2 and 3.

  3. #23
    AO Antique pwaring's Avatar
    Join Date
    Aug 2001
    Posts
    1,409
    Originally posted here by progme


    I suppose not and this is also my personal experience working at software houses. I certainly don't constitute for all software development houses but I can speak for the ones I have worked at. If you would like to offer counter-evidance to support your argument rather then no it doesn't please post them now.
    I've worked on projects where the software has compiled in a matter of minutes (sometimes even less) - and sometimes that code was written in Visual Basic. Now, you might not consider it "industrial strength" software, but the fact that it was an important part of a £250 million project and was taken to various countries (including the Middle East and the USA) to be demonstrated shows that to someone it was "industrial strength" software.


    PC's definatly have more then one CPU
    I was referring to the actual CPU that most people would be thinking off - i.e. the Intel/AMD processor that sits on your motherboard with a fan on and works at anything from 66MHz to upwards of 4Ghz (based on the manufacturer's specs of course).


    the sound card will have a CPU your graphics card will have a CPU and if it's a modern graphics card it will have a programmable CPU.

    When I was refering to paralllel processing I meant that as the game was handling it's logic/physics the graphics card was rendering to the screen. The way games today work is this:

    1) Handle input
    2) Handle Logic
    3) Handle Physics
    4) Batch all responce sounds and send the to the sound card to be processed( 3d sounds, dongle effects..)
    5) Batch all 3d data together and send to the graphic card to be rendered
    6) LOOP

    Step 4/5 use to be a much longer process because games didn't have any CPU's that could handle 3d Sounds and graphics. Thankfully all of the rendering is done on the GPU(graphics card processor unit) and this leaves the programmer to only worry about step 2 and 3.
    What, so the programmer doesn't have to worry about handling input now either? Programmers have to be aware (although not necessarily involved in, if using an external graphics library) of ALL the steps you mention, even if they don't have to write the code for it. Furthermore, programmers definitely have to worry about input - even in the most simplest of programs user input is one of the things that can cause major problems if not handled correctly. Again, you could use a library to validate the input, but still the programmer will have to worry about it.
    Paul Waring - Web site design and development.

  4. #24
    Junior Member
    Join Date
    Jul 2001
    Posts
    8
    Thanks everyone for the responses. They helped a lot and i will try not to post them in two different forums. Thanks again HICKMAN

  5. #25
    Junior Member
    Join Date
    Oct 2003
    Posts
    14
    Originally posted here by pwaring

    What, so the programmer doesn't have to worry about handling input now either?
    It's not that they don't have to worry about input but it is generally as hard as writing the initializing code for starting up a window, it is trivial. Also handling input takes no real time considerations because you are just polling the hardware every iteration.

    Programmers have to be aware (although not necessarily involved in, if using an external graphics library) of ALL the steps you mention, even if they don't have to write the code for it. Furthermore, programmers definitely have to worry about input - even in the most simplest of programs user input is one of the things that can cause major problems if not handled correctly. Again, you could use a library to validate the input, but still the programmer will have to worry about it.
    Let's not vear off the topic we were originally discussing. We were talking about speed considerations and how you even believed you had to choose a low language project for real-time applications. I never would disagree with you on how programmers need to have a sense for how all their external dependencies should work. Knowing basic theory on graphics rendering is essential even if you're making use of a third party library but worrying about optimizations, custimizations and inlining assembly is nothing programmers should be worrying about. A game company can make a game now a days in a high level language like ruby, python, or LISP by using 3rd party libraries. Speed isn't as important as it use to be.

  6. #26
    AO Antique pwaring's Avatar
    Join Date
    Aug 2001
    Posts
    1,409
    Originally posted here by progme


    It's not that they don't have to worry about input but it is generally as hard as writing the initializing code for starting up a window, it is trivial. Also handling input takes no real time considerations because you are just polling the hardware every iteration.
    I wouldn't say that handling and validating user input was "trivial" - think of the number of problems that have been caused over the years by users either accidentally or purposely entering invalid data. Sure, the basic functions of handling input may be trivial, but to make sure that you cover all (or at least the majority of) the possible inputs that might cause unwanted effects requires a lot of thought. In fact, last time I worked on a project, about 20% of the code was used purely to collect and validate user input.

    Let's not vear off the topic we were originally discussing. We were talking about speed considerations and how you even believed you had to choose a low language project for real-time applications.
    I never said that you had to choose a low level language for real-time applications - what I mentioned was that speed is essential in real-time applications (although the program doesn't have to be fast, it does have to respond in a certain time) and sometimes that used to mean using assembly. Nowadays you can probably get by using a slightly higher level language such as C - perhaps even write everything in an interpreted language if it doesn't require extremely fast response times (based in milliseconds rather than seconds say). Speed (or perhaps more correctly response time - although that is obviously linked to speed) has always been an important factor for programmers, and will continue to be so. Perhaps if you're writing a simple education program it might not be top of the priority list, but it's still a consideration.

    I never would disagree with you on how programmers need to have a sense for how all their external dependencies should work. Knowing basic theory on graphics rendering is essential even if you're making use of a third party library but worrying about optimizations, custimizations and inlining assembly is nothing programmers should be worrying about. A game company can make a game now a days in a high level language like ruby, python, or LISP by using 3rd party libraries. Speed isn't as important as it use to be.
    I agree, speed isn't as important as it used to be - but only to a point. It's still an important consideration for tasks which need to be performed faster and faster (e.g. any task involving large amounts of statistical analysis/number crunching). Sure, you might not have to worry about inlining assembly anymore (unless you are interacting with hardware on a low-level, or require the fastest response times possible - e.g. in a program dealing with hospitals, emergency services etc.).

    In theory you could use ruby or python to write a game, but I doubt that the major software houses will step to that level yet because the games probably wouldn't run fast enough. Sure, python (and other interpreted languages) are great for scripting, but I expect the core code (some of which the programmers will still have to write, even if they are using external libraries) will be written in C/C++ or a similar middle-level language for some time yet.
    Paul Waring - Web site design and development.

  7. #27
    Junior Member
    Join Date
    Oct 2003
    Posts
    14
    Originally posted here by pwaring

    I wouldn't say that handling and validating user input was "trivial" - think of the number of problems that have been caused over the years by users either accidentally or purposely entering invalid data. Sure, the basic functions of handling input may be trivial, but to make sure that you cover all (or at least the majority of) the possible inputs that might cause unwanted effects requires a lot of thought. In fact, last time I worked on a project, about 20% of the code was used purely to collect and validate user input.
    If you would stay in context to my post then you would know that I'm refering to Input in the game cycle. I only brought up inputing to show that it was a detail in the game cycle but not an important detail. Writing how input is handled in a game is trivial, it requires polling every iteration of the game sequence of the hardware and updates the states of every key position. Based on the key positions events happen.

    In theory you could use ruby or python to write a game, but I doubt that the major software houses will step to that level yet because the games probably wouldn't run fast enough. Sure, python (and other interpreted languages) are great for scripting, but I expect the core code (some of which the programmers will still have to write, even if they are using external libraries) will be written in C/C++ or a similar middle-level language for some time yet. [/B]
    www.gamasutra.com

    That is the definitive source for game development. Particulary if you check out he articles on the Crash Bandicoot series you will notice that the 'core' of the game was written in LISP. Those games were fully 3d and I didn't notice anything slow about them. While C++ is still a major development language in the game industry, due to managers making development decisions, many game companies are shifting away from developing the game from ground up. Many games are written in a scripting language and use Unreal's or Quake's engine.

    You can argue with me all day that there will be always a need for assembly and low level C optimizations. I've worked on plenty of projects which made strict requirements on the space and time. Though White_Eskimo made it clear that he was more worried about speed on such a trivial issue. I see it happen all the time even at work when iterns are optimizing they are looking at little tricks such as ++i instead of i++ when they should be looking at the tripple nested for loop they had implemented. Another observation I've made is that on most programming forums, when people ask advice on what language they should learn they usually base there decision on speed. Most of these programmers arn't writing time critical applications they are writing programs that help them out or maybe they are writing games. So they choose to learn C/C++ and it takes them months to get beyond the basics of C++ where if they choose a language like Python they could of have multiple fully developed programs out in weeks.

  8. #28
    Senior Member
    Join Date
    May 2003
    Posts
    226
    btw, can someone explain the usage of "using namespace std;" and #pragma once. i'm new to c++

  9. #29
    Senior Member
    Join Date
    May 2002
    Posts
    344
    oh no not again....i am going to write a tutorial about it damn it the question has been asked at least 100 times...sorry to be a little rude, but it gets annoying when you re type the same stuff over and over again. plus if you actually read all the posts in this thread i think you should get a general idea maybe i havent read them all so i dont quite know but thats what progme and pwarning were originally argueing about...or at least i think it was
    Support your right to arm bears.


    ^^This was the first video game which i played on an old win3.1 box

  10. #30
    AO Antique pwaring's Avatar
    Join Date
    Aug 2001
    Posts
    1,409
    You can argue with me all day that there will be always a need for assembly and low level C optimizations.
    You are not listening to what I have said - I never stated that there will *always* be a need for assembly or low level C optimisations (in fact I've managed to avoid assembly and "low level" C in all the commercial programs I have written), I merely used them as an example to support the point that speed still is an important issue when considering the design of any program, not just games.

    I've worked on plenty of projects which made strict requirements on the space and time.
    So have I, but that doesn't necessarily mean I had to use interpreted languages such as Ruby, Python or LISP.

    Though White_Eskimo made it clear that he was more worried about speed on such a trivial issue. I see it happen all the time even at work when iterns are optimizing they are looking at little tricks such as ++i instead of i++ when they should be looking at the tripple nested for loop they had implemented.
    i++ is just a throwback to when it did actually make a difference to write i++ instead of i = i + 1, because it told the compiler to use the increment instruction rather than the add instruction, which if I recall correctly did make a speed difference. Nowadays the compiler will probably interpret both statements as the same thing and optimise it for you.


    Another observation I've made is that on most programming forums, when people ask advice on what language they should learn they usually base there decision on speed. Most of these programmers arn't writing time critical applications they are writing programs that help them out or maybe they are writing games. So they choose to learn C/C++ and it takes them months to get beyond the basics of C++ where if they choose a language like Python they could of have multiple fully developed programs out in weeks.
    Obviously speed is not going to be a critical issue when you start programming, especially since a lot of newbies will spend so much time thinking about what they are doing that they won't notice if their program runs 10% slower in Python than its equivalent in C++. It's probably better to learn an interpreted language first, although some people (including myself) do find it more useful to be thrown in "at the deep end" so to speak.
    Paul Waring - Web site design and development.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •