Sorry your browser is not supported!

The idear is to use a local network. I have not tryed useing a local network before. The main program with a sub / slave program that does something ( collision checks ) and send the resuls back to the main program. collision checks may not be a good example but it can take a while with many ( 1000 + ) object moveing.

There are problems with useing the local network that are the ping time ( should be very small ) , errors and the amount of data that coule be send at anyone time. Someone who has used it more could help with these problems.

Quick example

game: think bullet hell with 1000 + bullets moveing and could collide with the player.

Start of the game
Main prgram connect to the sub
the main program gen / sends the bullets positions to the sub program.

main program
PLayer control ( No collision checks )
Sent to the sub is the player position X / Y
Move the bullets
Draw the bullets
Draw the player
recives from sub if there is a collision do something

Sub program:
Moves the bullets
recives the player position x / Y
Check for collision for player / bullets
send to the main IF there was a collision.

moves the bullets are in both program because You don't want to send all of that data. There could be something that i'm missing.

The dule screen could be used to make a tool for tracking some veribles , map for testing , command console for changing veribles in game. There are many other thing that this could be used for. The Best part of it does not need to many sync per sec. i think 1 to 10 times a sec should be fine. So it can spend most of it's time waiting for the main program to send something.

If it's all done on the one computer the same results could be achieved by generating an XML feed from one program and reading it in another.

So you'd transfer the data via the hard drive? That's a very bad idea, as you're reading/writing 60 times a second. If you ran that program for 8 days, cells in that region on the hard drive would break.

TheComet

No, he'd transfer the data using a network connection on localhost.


Use a custom data transfer format rather than XML, if only to avoid the wasted cycles used for encoding/decoding the XML stream.

@Alien002,
The only problem that I see with your idea is that you'd need media to be loaded in both programs - one copy for the collision checks, and one copy for displaying, putting double the load on your system.

You could mitigate that by using very simplified and untextured media for collision checks, so maybe it wouldn't be too bad.

DBPro itself can't handle double-displays, but with a recent addition to my plug-ins, it's now possible to get offsets and sizes of secondary displays so that each program can position itself to cover them.

I have tried this before.

I also used File Mapping between two programs.

Edit: It was a bit irritating having to query entities and UDTs through the network.

I didn't use the technique for multi-core though; I have one.

I used this technique because I wanted to split my program in two.

Interesting...