Quite new to C++

I picture Harry shaking his head wondering *** happened to his thread.
As far as the rest goes.....I have to give the edge to Egawtry.

Quote:

---

Originally Posted by GCDEF

And while you're out there optimizing your assembly code and tweaking using the native APIs, your competitor will bet using .net or MFC and get to market way before you do. It's nice to know that stuff but for most work, it's just not essential or even practical.

---

Depends on what you are doing. If you are writing a office app to transfer specific data using SOAP or something like that, C# or unoptimized MFC is great. If you are writing a game like Harry (the orginal poster) then you need to do low level tweaking. Last RPG I worked on, I had to really tweak code to get the laser gun sound to match the screen graphic, there was too much latency in the standard code.

-Erik

Quote:

---

Originally Posted by egawtry

Depends on what you are doing. If you are writing a office app to transfer specific data using SOAP or something like that, C# or unoptimized MFC is great. If you are writing a game like Harry (the orginal poster) then you need to do low level tweaking. Last RPG I worked on, I had to really tweak code to get the laser gun sound to match the screen graphic, there was too much latency in the standard code.

-Erik

---

in this, I agree

one should always specify the programming area he's speaking of, because we're not ultimately interested on the absolute performance ( = the time needed to complete an operation ), we're interested in the "value" of performance, and in turn the latter can be a non linear function of the former.

an example is the latency Egawtry alluded to: double/half the sound latency doesn't mean half/double the gamer satisfaction, because there's a sharp cutoff separating a synchronized from an unsynchronized sound; so, near the cutoff a small absolute performance increase translates into a big performance value increase, away from the cutoff the opposite occurs ...