After a long period of time, I found another book by Osho on zen "walking in zen, sitting in zen". It is another collection of his discourses and needless to say, it is very enjoyable. The language used is funny and serious and a far cry from the very plain english that i had found in the immortals of meluha. And on top of that osho's book is about meditation, my favourite subject, about which i love to read but fail to practice :-)
on the work front, i was loaded with work, games had to be modified, some modifications had to be reverted back, it was kind of nonsensical yet very draining and stressful. But I did find a very interesting thing about screen resolution. You see, the older laptops have a screen resolution of 1024 by 768 and the newer ones have a resolution of 1400 by 900. So, if one game's images work well on newer laptops, it may not work on older ones due to this resolution issue. If the cards are well spaced out on our monitors, they may be crowded together on the older laptops. Initially, it was mind boggling. How can something which work well on our pcs won't work on other laptops? Our woes boiled over this friday when we rejected 7 issues from clients on the ground that we can't simulate them :-)
But then we did find the root cause behind such issues and so by setting screen resolution to different values, we were able to see many display issues and were able to fix them on time. had to work on saturday also, which was very painful yet very rewarding too.
Sunday, January 16, 2011
Sunday, January 9, 2011
challenges of making game run on differently powered pcs
If you are working on a game which you want to run on differently configured PCs, there are a bunch of things you need to take care of, especially when it is driven by a timer :-)
So, if you have a game which is timer driven, the result to be shared with all the clients and the result to be displayed on the client which takes time (9 seconds on windows 7 with 2 GB ram, 7 seconds on windows 7 with 4 GB ram, 13 seconds on windows 7 with 1 GB ram, 11 seconds on windows vista with 2 GB ram, 15 seconds on windows 7 with 1 GB ram, 15 seconds on windows xp with 1 GB ram), the problems compound. The decision basically boiled down to whether we would put different conditions for display depending upon the pc configuration so that we can control the result display on the client and so that timer can remain synchronized on all the clients or we would want to do something to the architecture itself to somehow synchronize the timer on the server with all the clients. After 1 week of trying out different things, my mind was full of thoughts and of pending doom. And at that instant, I suddenly realized that if I continue in this fashion, the problem won't be solved. I tried calming my mind and gradually started ticking off things that had not worked. After some time, my list was empty but my mind kept on churning ideas. And one of them just simply clicked. Depending upon the time spent in displaying the result, I just had to start the timer at the right value so that it remains synchronized with the server. Very simple solution which did not add any complexity to the code. And it worked too. So far, no one has complained of timer synchronization issue.
There was another such issue yesterday. 2 threads were using the same static flag in their run conditions, but one of them was working and the other was not. And this would happen only in 1 particular scenario when the clock would wait for a condition to fulfill before starting. After some time, I realized that it was a race condition. The one thread which was not working was being created before the 2nd thread was created. And the variable was being initialized in between these 2 calls. So, I set the variable before these 2 and it all started working properly. So how did it work for other scenarios? If the thread displaying result was being run, the 1st thread would have to wait. By this time, the other thread would have created the 2nd thread and set the flag to true. And so it was working properly. But if for some reason, the result displaying thread would go to sleep, the 1st thread would be invoked and would exit quickly but the 2nd thread would work properly :-)
So, if you have a game which is timer driven, the result to be shared with all the clients and the result to be displayed on the client which takes time (9 seconds on windows 7 with 2 GB ram, 7 seconds on windows 7 with 4 GB ram, 13 seconds on windows 7 with 1 GB ram, 11 seconds on windows vista with 2 GB ram, 15 seconds on windows 7 with 1 GB ram, 15 seconds on windows xp with 1 GB ram), the problems compound. The decision basically boiled down to whether we would put different conditions for display depending upon the pc configuration so that we can control the result display on the client and so that timer can remain synchronized on all the clients or we would want to do something to the architecture itself to somehow synchronize the timer on the server with all the clients. After 1 week of trying out different things, my mind was full of thoughts and of pending doom. And at that instant, I suddenly realized that if I continue in this fashion, the problem won't be solved. I tried calming my mind and gradually started ticking off things that had not worked. After some time, my list was empty but my mind kept on churning ideas. And one of them just simply clicked. Depending upon the time spent in displaying the result, I just had to start the timer at the right value so that it remains synchronized with the server. Very simple solution which did not add any complexity to the code. And it worked too. So far, no one has complained of timer synchronization issue.
There was another such issue yesterday. 2 threads were using the same static flag in their run conditions, but one of them was working and the other was not. And this would happen only in 1 particular scenario when the clock would wait for a condition to fulfill before starting. After some time, I realized that it was a race condition. The one thread which was not working was being created before the 2nd thread was created. And the variable was being initialized in between these 2 calls. So, I set the variable before these 2 and it all started working properly. So how did it work for other scenarios? If the thread displaying result was being run, the 1st thread would have to wait. By this time, the other thread would have created the 2nd thread and set the flag to true. And so it was working properly. But if for some reason, the result displaying thread would go to sleep, the 1st thread would be invoked and would exit quickly but the 2nd thread would work properly :-)
Subscribe to:
Posts (Atom)
