Active TopicsActive Topics  Display List of Forum MembersMemberlist  Search The ForumSearch  HelpHelp
  RegisterRegister  LoginLogin
Developers
 Brain Games Forums : Developers
Subject Topic: network Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 13 September 2003 at 13:43 | IP Logged Quote Popolon

And of course, I've to start writing code to ensure that all the computers are running the same game, etc. (this will be a boring part).
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 13 September 2003 at 18:49 | IP Logged Quote JEames

Well... I think I can't wait to see all this in action.

What will you implement frist? -Networked Road Fighter or Net MOG2 engine?



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 14 September 2003 at 12:03 | IP Logged Quote Popolon

MoG2.

I have this roadmap for MoG2 engine:

v0.7: network
v0.8: sound
v0.9: room/map/game scripts
v1.0: generate standalone games

And I want to complete version 0.7 before going again for RF

Edited by Popolon on 14 September 2003 at 12:03
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 22 September 2003 at 14:55 | IP Logged Quote Popolon

A preliminar version of the networked gameplay for the MoG2engine is already finished!!!
To test that it works perfectly, I've connected my laptop running MoG2 over Windows with my Mac running MoG2 over Mac OSX. Here you can see a small photo that proofs that it works!!!!!!!!



However, it still needs refinement before the network code is considered definitive and I can put it into RoadFighter or anyother game. For instance, a CLIENT computer freezes if I turn of the server first, etc. All this small problems have to be fixed before...

But well, now I see that coding a network game is not so easy! But it's possible!

Edited by Popolon on 22 September 2003 at 14:55
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 22 September 2003 at 15:19 | IP Logged Quote JEames

hey hey hey...

When are we going to get downloading? I think we are all anxious to start testing.



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
MP83
Senior Member
Senior Member
Avatar

Joined: 05 December 2002
Location: Finland
Posts: 901
Posted: 23 September 2003 at 11:07 | IP Logged Quote MP83

Hmmm...Apple monitor.

That's some good news!  I believe everything is possible...when it's about your programming things.

Well, nothing more to comment. Keep up the good work, as always.

 

Back to Top View MP83's Profile Search for other posts by MP83 Visit MP83's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 23 September 2003 at 11:11 | IP Logged Quote Popolon

I love that Apple motior I'd buy one for home if it wasn't 900€...

Hope to have a version "ready to be released" by the weekend
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
jpkokkon
Newbie
Newbie


Joined: 09 October 2003
Location: Finland
Posts: 23
Posted: 09 October 2003 at 21:55 | IP Logged Quote jpkokkon

Well, almost didn't realize that MoG2 was already in "production". Had I realized that sooner, I would have not bothered Santi with the e-mail I just sent him. :)

Anyway, to the actual point..

You said that the game was really slow because of the network sending.. Well that sounds like you are using syncronous networking calls (blocking calls). Otherwise that kind of slowdown should not be possible because of network. The only thing that the network can cause is lag - in other words, some clients lag behind others, but it certainly should not affect the framerate of the clients.

If you are using blocking network calls, I would most certainly recommend changing to non-blocking (asyncronous) calls. Otherwise you will most probably end up having a very laggy game which may pause for even several seconds just because some client is having network connection problems.

The movement prediction is an important part of the game, if you want to minimize the effect of network lag. However, it is not that important in some cases when some lag is tolarable - and if you really want to get rid of the lag, the only way would be to use UDP instead of TCP, because no matter how you code your game, TCP is always laggier than UDP because of bigger packets and especially the needed ACK. On the other hand, UDP is unreliable protocol, whereas TCP is a reliable protocol - in other words, TCP ensures that all the packets get to the other client and in correct order, UDP may lose packets and neither the server or client will know this, unless you implement a TCP-like system on top of the UDP.

Well, regardless of the protocol used UDP or TCP, the one thing that is important, is the difference between syncronous and asyncronous networking calls. Asyncronous networking will make the code much more complex (because you need to implement buffers and stuff) but you can't make any proper networking without it (well actually you could, if you were to use multithreading, but that's probably a bad idea).

I haven't looked into SDL_net, so I can't say if it uses async somehow for the TCP.. I would guess that it works in sync not async manner.

Oh and btw. I have heard at least in a few occasions that port numbers above 32767 are not recommended because some bad hardware/software may not work properly with those, because the ports numbers are 16 bit integers and some may use signed 16 bit ints, so that the last bit may cause problems. So port numbers between 1024-32767 are a safe bet.
Back to Top View jpkokkon's Profile Search for other posts by jpkokkon Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 09 October 2003 at 22:20 | IP Logged Quote JEames

Well... I must agree in about 95%.

Just one thing: I believe multithreading could be a good bet. I've been involved closely in a multi-threading project and I now that the programing gets really tricky, but believe me, Santi has really smart programing with hardlly any bugs. That's a big advantage because what really make's multithreading complex is the fact that debugging come's really hard.

I think that keeping in mind the amount of data that has to be sent is minimum, a multithread server and a client with several open sessions over TCP (priorizing time sync, positions, and extra data) the game should work fine.

The ideal combination would be using all possibilities: the multithread server, tcp connections for time sync and positioning checksum and udp for the rest. In fact the positioning could be sent by tcp if you keep the amount of data low (this is not a 3D shoot game... so there's no so much to send arround).



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 10 October 2003 at 11:25 | IP Logged Quote Popolon

JEames wrote:

Well... I must agree in about 95%.


Just one thing: I believe multithreading could be a good bet. I've been involved closely in a multi-threading project and I now that the programing gets really tricky, but believe me, Santi has really smart programing with hardlly any bugs. That's a big advantage because what really make's multithreading complex is the fact that debugging come's really hard.




Well, you embarras me...

Actually, threads are a good option. Fortunately for the kind of application that MoG2 is, they are not needed (I can explain you why if you want to know).

About the network algorithm. Al you say, my initial problems were because I used blocking calls. Now I've changed to another version of the protocol with non-blocking calls, and using a buffer. Therefore, the network speed only produces a lag (bigger or smaller).

I still haven't implemented prediction of the movements of the characters, since all the tests that I've done are in a LAN. And in a LAN, the lag is so small, that there is no need for predicting moves.

About the amount of data to send. I've taked advantadge of the way the MoG2 engine is build. In fact, what the computers share by TCP is the state of the keyboards of each machine (the keypresses that the user makes). The MoG2 engine is build to be deterministic (i.e. with the same input from the user, the game will be always exactly the same). This is done in this way to allow "replays", etc. (exactly as in Transball). The only problem were the random numbers, but I've solved the issue by sinchronizing the random number generators of all the computers at the beginning of the game (since all the computers use the same random number generator). Therefore, even the game was a 3D shooter, the amount of data to send will be the same. Just the keyboard presses.

However, my method is not perfect and it has a weak point: a player cannot enter a game that has started some time before. But I'll change it in the future. I already have some idea on how to do that... It's not that hard...
However, it's my first attempt to add networked gameplay in a game, so be patient with me!

I've also though on using UDP, but I think that the speed gain is not worth the complexity of the code. I think that TCP is much easier to use (since you can be sure that your packets will arrive to their destination).
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
jpkokkon
Newbie
Newbie


Joined: 09 October 2003
Location: Finland
Posts: 23
Posted: 10 October 2003 at 14:49 | IP Logged Quote jpkokkon

Making the game deterministic and just syncronizing the keypresses (or any other user inputs) sounds like a good idea for this kind of game. Done one game like that before myself.

There are of course some weak points in every solution..
Some points that cross my mind based on what I learned when making my game..

This is going to be a long post, so just skip it if you are not very very very interested in networking coding. Also, these are actually pretty trivial things, so I guess you may have already though of these.

Random numbers:

I would not recommend using the standard rand() function, because there are no guarantees that every operating system does it exactly the same way (well, actually ANSI C may define it pretty strictly, but I still remember the rather bad implementation of borland's turbo C++ 3.0). Also, you cannot get the seed for standard rand(), therefore people joining in the middle of the game require a new srand() to be called to get the same seed for everyone. I would go for some own simple and deterministic random implementation. (easiest way is to use precalced random data file which is then looped and seed is the location in the file - i can send you the little piece of code to for that.) You can still use the standard rand() for such cases that do not effect the game state (for graphical effects maybe) if you want.

Syncronization checking:

You probably want to send the current random number in "queue" to each client from time to time. This way the clients can compare their own random number to the number received from the server - thus making sure that the game has kept in sync, also you may send some other data to determine wheather the games are in sync or not. You will want to have this kind of check - see below for the reason.

Bug freeness:

With deterministic syncronized game you must be absolutely sure that there are no bugs - no buffer overflows or uninitialized data. Because just one little bug like that, and probably the error will cascade and very soon the random number generators are out of sync and so is everything else. And then you'll be going out of your mind, debugging the game for hours and hours. (I know, I've been there ;) On the other hand, thanks to the game going out of sync on bugs, I found a huge amount of bugs that I would have never found without it.

Joining in the middle of the game:

You will eventually need the possibility of players joining in the middle of the game - if not for any other reason, for the reason that internet network connections tend to break every once a while, just for a few seconds, but that may be enough do drop one player off. If that player cannot join back into the game, he sure will be pissed off. One problem with joining in the middle of the game is the fact that you need to send basically _all_ game data (game state snapshot) to each of the joining clients to make sure they are in sync. Now, this may take a few seconds at least (or even minutes!), so you may need to pause the whole game while waiting for that one client get it's data. You could just go on without pausing and trust that the client will catch up with the rest, but then you will need bigger receive/send buffers and the game logic must be so lightweight that the client actually can do the catching up in time. An easy way to implement the game data sending, is to make good save and load functionality to the game - you can use the same data to save and load the current local game and to send the game to other clients. Using some compression algorithm for the saves (data snapshots) may be a good idea to speed things up. A simple RLE packing or Zlib being the usual solution I think.

Gameplay logic lightweight:

As I just stated above, the gameplay logic needs to be quite lightweight. This is because if a person happens to have a bit oldish computer with not too much processing power - he won't be able to play the game unless his computer can do all the logic in whatever time is reserved for one game loop "tick". If the game runs at 25Hz (40ms per tick), everyone must be able to do that in that time. If one computer cannot do it, it keeps on lagging more and more until finally the lag is several seconds and the network buffers are probably full - so the client drops off. (Of course the client could reconnect and request a new snapshot of the game state, but that would not help, he would still drop again and just annoy other players when causing the server pause/lag.) A good example of this kind of problematic game was the Stronghold strategy game (at least the first versions) - when players had built too much houses and units, the game could not cope with that and started to send game state snapshots every few seconds - making the game simply unplayable. One way to ensure that clients have enough CPU to use for the gameplay logic is of course to drop screen framerate if necessary to save some CPU time.

One could also make the server run at most at the speed that the slowest client can run, but then again the other players would be annoyed because some player would ruin their game with his too slow computer.

Version:

Probably a good idea to send the game version info when a client tries to connect to a server - just to make sure the versions are the same (once again, because if the versions are not the same, the clients won't keep in sync).

TCP or UDP:

Definately TCP if you are making this kind of synchronized architecture - nothing would be gained for using UDP (because you would have to implement a TCP-like functionality yourself anyway or otherwise the clients would immediately go out of sync).

Computer players (bots?) - and maybe even other computer controlled enemies?:

Well, either they are run on every client just as the gameplay. Or maybe you could just implement them so, that they are run on the server only, and the server will then send the computer "keypresses" just like it would do for the players. This of course depends on the amount of the computer players/enemies and if one wants to remove unnecessary processing load from clients.

Timing info:

The game probably need to send some timing information with the packets. If there is no movement prediction, you will probably want to create a little bit of artificial lag between the server and clients. The client should not attempt to run all packets received from the server immediately, because this might result some "jerkiness" at the clients - since not all network packets take exactly the same time from server to client. If there is no artificial lag added according to received timing info, the client would just execute every packet as soon as it arrives, resulting into small jerks at game execution when a network packet for some reason would take more time to arrive than the previous packet. With an artificial lag (preferably adapting one) adds enough lag (more than the usual network lag) to each packets execution, it does not matter if some packets arrive a bit faster and some a bit slower - client will still run smoothly.

Well, that's about everything that comes to my mind right now. Hopefully at least some of these points raised some new thoughts. Of course it would be even better if you have already thought of each one of them - but I know I did not when I first tried to make networked games. :D
Back to Top View jpkokkon's Profile Search for other posts by jpkokkon Send Private Message Add to Buddy List
 
JEames
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Catalonia
Posts: 498
Posted: 10 October 2003 at 15:47 | IP Logged Quote JEames

And what about a "server based" game where the server recive's all keystrokes and sends "rooms" (width all the status of that active room with it's active objects) to dumb clients that just blindly obey to what the server sends? -How many things can change every 1/25 seconds in the current active room? -Can all these things be sent in time? -Well, it's just a possibility, it's obiouse that you have had much more experience in networking programing than my self; but this aproach could make things really simple. What do you think?



__________________
Jason Eames Lamarca
+34 639517737
Back to Top View JEames's Profile Search for other posts by JEames Visit JEames's Homepage Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 11 October 2003 at 12:21 | IP Logged Quote Popolon

About the "server based" game:
That was my initial idea, but that means to send A LOT of data every frame (you will get surprised to see the amount of variables that each object has). And in each room there can be about 50-100 active objects (only the STONE explosion is composed of 64 small objects). Moreover, a client can be displaying more than one room at a time (the engine allows that), therefore multiplying the amount of data to send. I think that that "server based" game is perfect for more simple games (i.e. road fighter) where there are very few active objects in the game, and they are very simple (in road fighter, each object has just 5 local variables). Maybe I implement RF network code in that way. But for MoG2, I prefer to keep the current way of doing it.

About the Random numbers and synchronization checking:

I think that you can read my mind. What you describe is EXACTLY what the engine does: I've not used the "rand()" function, but downloaded a random numbers generator library, to ensure that the numbers are generated exactly equally in Windows, Linux, Mac, BeOS, etc. And in every frame, each client sends a random number to the server. If the random numbers differ with a random number generated by the server, we have a synchronization error. Fortunately I still have never experienced that situation. However, if that happens, each computer will save the last "secure" game state to disk and then quit the game. The users can then reload the saved game, and restart the game from there.
Of course, it's very important that the engine is bug free... However, I think that at this moment it is quite very bug free (I haven't found anyone by now).

About joining at the middle:

Again, you read my mind. My idea was to pause the game while the server sends the game state to the new client. And as you have said. The game relies on a very STRONG load/save functions, that can completely save the state of a game to disk, and then reload it. However, what I don't like is that my current functions SAVE/LOAD to disk in an ASCII readable format, not very efficient in size. I'll have to compress it as you say. I don't know Zlib, but I guess it is some compressing/decompressing library. Am I right? That can be a good solution.

Gameplay logic lightweight:

Good point. That's right. Fortunately, the game logic is quite fast to compute. The slow thing is redrawing the screen. But I'll take care of that point... But now a question rises on my mind: When a client drops off, the characters that that client were comtrolling are discarded? or they remain in the game without moving? When a client reconnects, how can the server know which was the character that that client was using and reasign that character instead of creating a new one? I'll have to think about how to solve that questions!

Version:

another mind reading. MoG2 already does that. In fact it also sends the version of the map that each clienc is running to ensure that every computer has exactly the same game info.

Artificial lags:

I've noticed that effect! When I play a networked game, even the game runs also at 25fps, it's not as smooth as it should be. The reason you explain can be the cause... I'll look on how can I add artificial lags to add smoothness to the game.

Nice post jpkokkon! You've touched a lot of interesting points!!!
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
jpkokkon
Newbie
Newbie


Joined: 09 October 2003
Location: Finland
Posts: 23
Posted: 11 October 2003 at 21:09 | IP Logged Quote jpkokkon

Now that I'm on the roll, I'm just gotta post one more of these excessively long posts..
Sorry about that. I'm just bad when it comes to text compression.

Zlib is indeed a compression/decompression library (www.zlib.org if I guess right) - it uses basically the same algorithm used in zip files. Plus side of zlib is of course the compression ratio of the algorithm. Minus side may be the performance needs of such algorithm. Although, probably still faster to compress files and then send them over the network compressed than just sending big text files uncompressed.

If the data sent would be just the right kind of data in just the right kind of format, doing a simple RLE compression might be a good idea, because it basically takes no extra performance compared to just using plain uncompressed data. Bad thing with RLE is that it usually gives you a very bad compression ratio (i guess it's usually good only for compressing simple cartoon like graphics, any other data will compress very badly with RLE).

About that artificial lag / the game not running smoothly.. If you have been using LAN (of just 2 computers, not doing anything else network intensive?), it seems a bit odd that the game would not run smoothly, unless there is some other problem too. Because at least in my tests, my games have run pretty smoothly over LAN, even before any kind of extra artificial lag or anything else was implemented (over the Internet the game was jerky as hell though. ;)

The "artificial lag" may seem like the stupidest idea ever - willingly adding lag to the game - but at least the way I see it, it is the only way one can remove the un-smoothness of network connections - if there is no movement prediction. If there is some proper movement prediction, adding lag is probably quite useless (or even stupid). However, of these 2 choices, the lag adding is much easier to implement than proper movement prediction. The result is of course not quite as good.

Oh, and one thing... The network sending should probably flush every time you send something - you don't want the OS to buffer anything. That might cause some un-smoothness.

I can't say much about how the flushing should be handled when using SDL_net for example - or wheather the SDL already automatically does that.

When using asyncronous calls, the flushing isn't quite as simple as it would be for blocking calls (where you would just call flush(), but the call would block). If my memory serves me right, I think that at least on Windows, you can force the flushing on with some winsock ioctrl calls.. just don't quite remember the right call and I don't have my sources on this machine. I'll throw the piece of code here later.

btw. The "game server - UI client" architecture would probably work just as well for this game as the "synced game clients" architecture. Usually you can't do a full dumb UI client implementation (like VNC or X-windowing system basically are), the client would have to have some game elements coded to it, like breaking the rock - the server should not send every little piece of the breaking rock individually for every frame, it should just send some kind of code for executing the breaking rock effect, the effect and individual pieces would then be handled by the client itself. I think that this is the way things are usually done nowadays (at least for shooters). I think the synced clients architecture has not been used much except for strategy games (with lots of moving units moving on the screen simultaneously). As far as I know, the original "Doom" used synced clients architecture, but don't know any much of other shooters that would have used it since (well, Unreal may have used it).

But, if the game is already working with whatever the architecture is, there is no point in changing that.
Back to Top View jpkokkon's Profile Search for other posts by jpkokkon Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 12 October 2003 at 12:11 | IP Logged Quote Popolon

I think Zlib will do the job for me. I guess it uses the LZW compression algorithm, I implemented it some years ago for a course in the university. However, I've lost the source code ...

About the game not running smoothly in a LAN. In fact, it is not VERY "unsmooth", but you can notice somehow that the game doesn't run exactly as smooth as in a single player mode. I'd like to test it over the internet. Some day I'll try to find time and call Jason to make a test.

And for the "game server - UI client" archtecture. I see that for what you explain, it's not very easy to implement. It will mean make A LOT of changes in my code. Therefore, as making the synched clients architecture has meant only to make slightly changes to the main engine, I think that I'll stuck to this architecture. However, I'm quite interested on where have you got the information about what architectures are used in some games (Doom, etc.) I was looking through the internet to find some info, and I found nothing. Only some infor that I could get asking a question in the SDL forum.
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 
jpkokkon
Newbie
Newbie


Joined: 09 October 2003
Location: Finland
Posts: 23
Posted: 12 October 2003 at 16:00 | IP Logged Quote jpkokkon

The information about which architectures are used in different games I've pretty much picked up here and there.

A lot of the information about the way different games work I've actually picked up by just simply playing the game and paying attention to all the little details of the game - error situations being the most informative..

When a game like Doom suddenly tells you that "the game has gone out of sync" with some kind of error message, you can quite easily figure out that the game actually tries to run deterministically on every client and the clients somehow then keep the games syncronized. :)
In a way, that was just a kind of an educated guess (later confirmed by reading some documents).

The same kind of guesses can be made with other games too, usually the structures are easiest to see, when something goes wrong - in other words, when the network connection starts to break up. At the moment the connection breaks up, different architectures start behaving differently.

Well, enough of the "guess the architecture logic". :)

Usually to get solid information about some architecture, I just make a google search with proper keywords. (Google is basically the best source of information if you ask me.)

Usually google can even find you documents made by the programmers of these architectures themselves. For example if you are intrested in Unreal engine, check this out: http://unreal.epicgames.com/Network.htm

If you are interested in Id-software's stuff, well, Carmack is also known for telling all sorts of things about their engine "innovations". As you most likely know, quake1/2 sources are freely downloadable under GPL (I would not recommend the original sources though - there are already improved versions available, like "beefquake" built on top of quake2.) If you are interested enough to wade through the q2 networking source, you will probably know the basics of half-life and even quake3 networking.. and since a whole lot of games use either q3 engine or epic's unreal engines, you know how the networking in all those games work. :)

Of course one channel, thru which I get my information are my collagues at work. I haven't really done much 3D programming myself, but after discussing about those things with the guys who have done it, I've learned quite a bit about how to make efficient 3D or how one can use shaders, etc.

And where do the others get the information?
Well, I'm kinda lazy surfer myself, but others seem to like to surf at the flipcode and gamasutra sites. Also, gdalgo posting list seems to have a lot of discussion.. (I personally don't like subscribing to it, because it will spam your mailbox full in no time.

And of course.. the best way to figure out how things work, is to try it out yourself. Having made all sorts of little network apps, some using threading, some using shared files, some using asynchronous networking, I'm finally starting to get the hang of these things.

I still remember my first networking app attempts.. They very rather ridiculous. They used blocking network calls, and in order to be able to handle multiple simultaneous clients, the server was multithreading (multiprocessing actually, cos linux does not have native multithreading, but multiprocessing) and then the "threads" (= processes) communicated with each other using shared files or unix pipes... Which seemed like the only way to do it, since I had no idea how shared memory could be used. The result was of course extremely clumsy and unnecessarily complex. Now, that I've learned the joy of asynchronous calls, I always try to keep my application single threaded unless there is a really good reason for doing it multithreading. I could tell more about my views of threading, but maybe I'll just leave that to another time, since I've already gone way off the original topic.

So, once again, I seem to have managed to write way too much text when a simple few line answer would have done the trick just as well. Just try to extract the actual information underneath all this crap.
Back to Top View jpkokkon's Profile Search for other posts by jpkokkon Send Private Message Add to Buddy List
 
Popolon
Admin Group
Admin Group
Avatar

Joined: 05 November 2002
Location: Spain
Posts: 3135
Posted: 13 October 2003 at 11:47 | IP Logged Quote Popolon

Thanks for that info. I'll take a closer look the next time I play "Enemy Territory"!!
Back to Top View Popolon's Profile Search for other posts by Popolon Visit Popolon's Homepage Send Private Message Add to Buddy List
 

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

Page of 2
  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum

Powered by Web Wiz Forums version 7.01
Copyright ©2001-2003 Web Wiz Guide

This page was generated in 0,7354 seconds.