Loof

I have two main languages of choice C++ and Python. When efficiency is a must, or for larger projects I like C++ and Visual Studio 2005. (haven't run into a scenario where C++ is to slow yet). For prototyping and playing around with algorithms or if speed is not a problem, I usually use Python, mainly because i love pythons syntax and the freedom to combine functional and imperative programing styles. In this scenario I simply use the text editor of the moment to code in (haven't found one I'm perfectly happy with yet, the favorites so far are the above mentioned Notepad++ and ConText or CrimsonEdit). As for versioning tool I have only tried CVS and SVN, but greatly prefer SVN since binary files aren't such a hassle when using it. Question to all of you that have used some of the commercial alternatives: How does using them differ from using SVN, and what features do those packages have that SVN lacks?

I'm pretty sure the game is not CPU bound. I tried running around a while with a CPU meter on my secondary screen and as long as I wasn't in combat the CPU was pretty close to 25% usage. And I only have a P4 2.8 GHZ. also noted that Windows + NWN2 seem to use around 800mb of ram. That being said memory speed could still be a factor, or cache utilization or disk access or about a million other things ...

Yes I know what context switching is. Taks was talking about a scenario where you had dual cores without shared caches I think. So a switch from one core to another would either result in alot of cache misses or having to copy the cache from one to the other. At least thats what I think he was talking about. What I asked you if you had a guess as to what could cause a single threaded process to perform noticeably slower on a dual-core then a single-core CPU. Note: with single threaded I'm refering to a process that has only one thread where any heavy computations take place... Just so you don't missunderstand me again

Ok then context switching jumping from one core to the next shouldn't be whats causing dual-cores to run slower then single-cores (as all games would then behave that way). You seem to be in the know of how lowlevel stuff works under windows. You don't happen to have educated guess as to what could cause such behavior? (that is if the lower performance even is because of single/dual core thingy...)

You mean there is no windows api that grants you any control of how your threads are managed? (Don't have much experience coding windows specific programs)

this really is not possible. code that is explicitly written for threads will, or should, take advantage of multi-core. otherwise, it will not, and will simply run on a single core. in other words, the instructions issued by the CPU do not know, nor care, that there is another CPU available. the issue, however, may be context switching. i do not know if winders will switch your process from one core to another, but that is a killer sometimes (linux will do that). tas <{POST_SNAPBACK}> Well there should be a way for the programmer to tell the OS how to handle context switching, otherwise we have a scenario that can give bad performance on multi-cores with nothing we can do about it. Assuming the option exists and it wasn't used (or was used badly) what we end up with is basically what I said. So I would call my statement a gross simplification and not incorrect =P

No there shouldn't be a downside to having two cores, only a potential upside. But computers as you probably knew are very complex machines, so it could be that they actualy run slower because the programmers wrote some code that is suboptimal on dual-cores but not on single-cores. Also about the patching to utilize both cores, dream on... Splitting a piece of code into several calculation heavy parts is a non trivial problem (hard as hell according to some programmers). So since Bioware didn't code for multi-cores, obsidian probably didn't have time to do it during development, and I have never heard of such a large change being done in a patch. @Kraftan: Yeah almost all modern games are GPU limited and not CPU limited, but there really isn't any law that says it has to be that way. If someone made a game tomorrow with very advanced AI, physics and lots of procedural content it's possible/probable that such a game would be CPU bound. In other words its a design choice...

Ok so you and mkreku disagree about the power of the charge kick,kick,..., sounds like I will have to try the game myself to find out =)

""" I think most reviewers just don't see the entire strength of the game. If you just keep running and screaming frontal at your enemie like this is Quake or Doom, you certainly don't see the whole aspects that the game offers you. """ I agree that this is probably not how the combat was suposed to be used. But a good combat system should make that tactic a sure death for the player. Having many options in your gameplay looses its point if there is a simple tactic that always results in victory, wouldn't you agree? PS: hypothetical argument as I haven't played DM yet...

huh me or mkreku??

Doesn't sound that fun... But most of your complaints seem to be rooted in level design or enemy design. If someone was mainly interested in the game so they could look at the new ideas for the combat system. Would you say that its a complete failure? Or are the basics of the system sound and just badly implemented?

hihihihi sounds like your problem is with ****y GM's and not with forced or self created characters. But it was a funny story =)

My recomendation would be to ignore C++ for now. Even if most games are written in it, it's not the best language to start learning in if you have never coded anything before (to many ways to do the same thing). I would instead recomend that picking an easy to work with higher level language (my personal favorite at the moment is python). It will be much easier to pick upp the basic princaples and concepts in such a language then it would in C/C++, and once one has programmed a while picking up a new language becomes a trivial problem that can be overcome in a week or two. C++ may be an exception to that timelimit since it so damn huge, but even if it takes longer then a few weeks to learn once you get down to learning C++ it will still go an order of magnitude faster or so then if you started with it.

I have a Audigy 2 ZS running on a WinXP sp2 installation. Haven't toutched the sound drivers since I installed the system, but I think I used the driver on the disc that came with the sound card. But I didn't install anything except the actual driver, so maybe the problems come from some of the bloated extra programs creative thinks you should have. Anyway, the bottom line being I'm pretty sure it's quite possible to have sp2 and an audigy card playing nicely together.

Actualy the 360 graphics card has features that wont be implemented on desktop cards untill next generation. So at release time consoles can definetly have nicer bells and whistles then a PC. But yeah in a year or so the PC will probably have passed the 360 on all points again (with the possible exeption of only having 2 cpu cores, but then those 2 are more advanced...).