just a curiosity question about programming with dbp on a dual core machine.

the word on the street is, todays software (that has been designed for single core) dosen't take advantage of dual core because win xp can't work with 2 cores because it was designed to use only one core.

I also heard somewhere (don't know if its true) that you need to split your programs into some kind of things so they will work on a dual core or use 2 cores or something.

I am planning to build a dual core machine in a few months. I have decided on an AMD 6000 x2 3.0 Ghz.

If my fears are correct my dark basic game (i am experimenting with different settings I have made at the moment) will run no different on "uber high settings" on a 3 ghz dual core than on my current 3 ghz p4.

any dual core owners out there have any thoughts on this?

I don't have a dual-core system, but back before it was released, I remember reading something that said that it is program specific weather it will take advantage of the second core. but if you compare the cache(L2?) of your current and future cpus you should be able to for see the difference in performance.

Having recently been developing on a Dual-Core machine, let me assure you that unless you're using Linux (or some other OS that actually takes advantage of the Dual-Core architecture), you're just going to get single-core response from your App. All XP will do with your Dual-Core machine is run twice the number of processes at a time.

But it is useful: you can do two processor-intensive tasks at once, and only worry about your disk utilization suffering. Other than that, it's like having a 3.0GHz machine on my desktop. Of course, having a lot of RAM doesn't hurt...

Unless you have the OS for it, and unless you write your app to take advantage of it (mutexes, multi-threading, that sort of thing) you're just going to enjoy mono-processor speeds. But past the 2.5GHz point, I keep asking myself does it really matter?

Although your app is running on one core, other XP stuff can use the other, so your program will be better by the fact there is not as many other processes competing with it. XP can handle two cores, and you can even set the affinity of your app if you know what you're doing.

Is it hard to do multi threading for dbp?

@BatVink -- Do you know how to set an app's affinity or can you supply a link with some info on it. I'd love to figure out how to do this.

Also, I seem to remember reading something in the forums a while back about DBP apps sharing memory or something like that? Am I mistaken or is that possible? If it is, would it be possible to write an application that loads resources on demand for use in another DBP application. That way you never saw a loading screen as the other process was continuously loading/unloading resources as needed.

I got inspired by the topic, to set the affinity:
http://forum.thegamecreators.com/?m=forum_view&t=111731&b=6

I think 3Ghz P-CD will be faster than 3Ghz P4

P4 is a bad chip design, I think the P-CD is based on pentium M so for the same clock it's faster. I find a 1.5Ghz P-M runs stuff about the same speed as a 2.0Ghz P4, so 3Ghz should equate to about 4Ghz?

Well, running a dual-core (2,67 GHz) I can say that it doesn't (untweaked anyways) alter the performance of DBPro apps; however, windows and most (commersial ) programs run far better than on an equivalent (2,67 GHz) single-core processor.
(So yeah, I guess XP can make quite good use of it after all )

An idea I've had but haven't gotten around to playing with yet is to have 2 processes involved in the game. Finding a way to split the responsibility evenly and cleanly between the processes would be tricky. Once a good split was found though, then you would just need to find an efficient and trustworthy method for communicating between the processes.

The thing to do then is determine if all of that extra work actually nets you an increase in performance or just a few more headaches. It wouldn't be easy though. You'd probably need to study operating system development and read up on the use of semaphores to prevent deadlock between multiple processes and things like that. I haven't messed with that type of programming in about 8 years, so I don't think I'm ready for it myself.

I did some programming on trans-puters back in college (systems that combined 2 or more computers together so they'd work as one) and some of the techniques we used might (MIGHT) apply to dual core processors to an extent.

Or I could just be blowing in the wind. In which case, someone please correct me so that I'm not leading anyone in the wrong direction.

I would think one half would be to load all the images, sounds, and maps that make up a section of the world, then be aware of the location of the player loading new sections as needed. Maybe it could also be concerned with the creation of the automated charactors that roam around that section.

The other half would be concerned with the screen refresh, soundeffects playback, the actual game play and the artificial inteligence of the animated charactors.

If that was built as two seperate apps and simply used shared memory to pass information back and forth, it would be interesting to see how it would perform on a dual processor system.