gamedesignteam

Anyone here think about getting xbox live but not have enough money to pay for the starter kit...

WELL GUESS WHAT!!!!!!!!

You can now get it without paying a cent (that is if you have a free 2 month trial)

First go to http://www.xbconnect.com/downloads.php and download the current version of XBConnect...

Secondly you must get a Ethernet cable and connect your X-BOX to your router (if you have, you MUST have one BTW)

Thirdly install and open xbconnect. Create a new account .......

Fourthly go on www.xbox.com/live and sign in your .NET passport and create a profile for xbox live

Fifthly open your xbox with a xbox live supported game and follow the setup for xbox live ....

And YOUR DONE!!!!!

Backtracking EMAIL Messages

Tracking email back to its source: Twisted Evil
cause i hate spammers... Evil or Very Mad

Ask most people how they determine who sent them an email message and the response is almost universally, "By the From line." Unfortunately this symptomatic of the current confusion among internet users as to where particular messages come from and who is spreading spam and viruses. The "From" header is little more than a courtesy to the person receiving the message. People spreading spam and viruses are rarely courteous. In short, if there is any question about where a particular email message came from the safe bet is to assume the "From" header is forged.

So how do you determine where a message actually came from? You have to understand how email messages are put together in order to backtrack an email message. SMTP is a text based protocol for transferring messages across the internet. A series of headers are placed in front of the data portion of the message. By examining the headers you can usually backtrack a message to the source network, sometimes the source host. A more detailed essay on reading email headers can be found .

If you are using Outlook or Outlook Express you can view the headers by right clicking on the message and selecting properties or options.

Below are listed the headers of an actual spam message I received. I've changed my email address and the name of my server for obvious reasons. I've also double spaced the headers to make them more readable.


Return-Path:

X-Original-To: davar@example.com

Delivered-To: davar@example.com

Received: from 12-218-172-108.client.mchsi.com (12-218-172-108.client.mchsi.com [12.218.172.108])
by mailhost.example.com (Postfix) with SMTP id 1F9B8511C7
for ; Sun, 16 Nov 2003 09:50:37 -0800 (PST)

Received: from (HELO 0udjou) [193.12.169.0] by 12-218-172-108.client.mchsi.com with ESMTP id <536806-74276>; Sun, 16 Nov 2003 19:42:31 +0200

Message-ID:

From: "Maricela Paulson"

Reply-To: "Maricela Paulson"

To: davar@example.com

Subject: STOP-PAYING For Your PAY-PER-VIEW, Movie Channels, Mature Channels...isha

Date: Sun, 16 Nov 2003 19:42:31 +0200

X-Mailer: Internet Mail Service (5.5.2650.21)

X-Priority: 3

MIME-Version: 1.0

Content-Type: multipart/alternative; boundary="MIMEStream=_0+211404_90873633350646_4032088448"


According to the From header this message is from Maricela Paulson at s359dyxxt@yahoo.com. I could just fire off a message to abuse@yahoo.com, but that would be waste of time. This message didn't come from yahoo's email service.

The header most likely to be useful in determining the actual source of an email message is the Received header. According to the top-most Received header this message was received from the host 12-218-172-108.client.mchsi.com with the ip address of 21.218.172.108 by my server mailhost.example.com. An important item to consider is at what point in the chain does the email system become untrusted? I consider anything beyond my own email server to be an unreliable source of information. Because this header was generated by my email server it is reasonable for me to accept it at face value.

The next Received header (which is chronologically the first) shows the remote email server accepting the message from the host 0udjou with the ip 193.12.169.0. Those of you who know anything about IP will realize that that is not a valid host IP address. In addition, any hostname that ends in client.mchsi.com is unlikely to be an authorized email server. This has every sign of being a cracked client system.


Here's is where we start digging. By default Windows is somewhat lacking in network diagnostic tools; however, you can use the tools at to do your own checking.

davar@nqh9k:[/home/davar] $whois 12.218.172.108

AT&T WorldNet Services ATT (NET-12-0-0-0-1)
12.0.0.0 - 12.255.255.255
Mediacom Communications Corp MEDIACOMCC-12-218-168-0-FLANDREAU-MN (NET-12-218-168-0-1)
12.218.168.0 - 12.218.175.255

# ARIN WHOIS database, last updated 2003-12-31 19:15
# Enter ? for additional hints on searching ARIN's WHOIS database.

I can also verify the hostname of the remote server by using nslookup, although in this particular instance, my email server has already provided both the IP address and the hostname.

davar@nqh9k:[/home/davar] $nslookup 12.218.172.108

Server: localhost
Address: 127.0.0.1

Name: 12-218-172-108.client.mchsi.com
Address: 12.218.172.108

Ok, whois shows that Mediacom Communications owns that netblock and nslookup confirms the address to hostname mapping of the remote server,12-218-172-108.client.mchsi.com. If I preface a www in front of the domain name portion and plug that into my web browser, http://www.mchsi.com, I get Mediacom's web site.

There are few things more embarrassing to me than firing off an angry message to someone who is supposedly responsible for a problem, and being wrong. By double checking who owns the remote host's IP address using two different tools (whois and nslookup) I minimize the chance of making myself look like an idiot.

A quick glance at the web site and it appears they are an ISP. Now if I copy the entire message including the headers into a new email message and send it to abuse@mchsi.com with a short message explaining the situation, they may do something about it.

But what about Maricela Paulson? There really is no way to determine who sent a message, the best you can hope for is to find out what host sent it. Even in the case of a PGP signed messages there is no guarantee that one particular person actually pressed the send button. Obviously determining who the actual sender of an email message is much more involved than reading the From header. Hopefully this example may be of some use to other forum regulars.

Listing 2.2 contains the source code for the game engine's WinMain() function.
Listing 2.2 The WinMain() Function in the Game Engine Makes Calls to Game Engine Functions and Methods and Provides a Neat Way of Separating Standard Windows Program Code from Game Code
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR szCmdLine, int iCmdShow)
{
MSG msg;
static int iTickTrigger = 0;
int iTickCount;
if (GameInitialize(hInstance))
{
// Initialize the game engine
if (!GameEngine::GetEngine()->Initialize(iCmdShow))
return FALSE;
// Enter the main message loop
while (TRUE)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
// Process the message
if (msg.message == WM_QUIT)
break;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
// Make sure the game engine isn't sleeping
if (!GameEngine::GetEngine()->GetSleep())
{
// Check the tick count to see if a game cycle has elapsed
iTickCount = GetTickCount();
if (iTickCount > iTickTrigger)
{
iTickTrigger = iTickCount +
GameEngine::GetEngine()->GetFrameDelay();
GameCycle();
}
}
}
}
return (int)msg.wParam;
}
// End the game
GameEnd();
return TRUE;
}
Although this WinMain() function is similar to those found in every Windows application, there is an important difference. The difference has to do with the fact that this WinMain() function establishes a game loop that takes care of generating game cycle events at a specified interval. The smallest unit of time measurement in a Windows program is called a tick, which is equivalent to one millisecond and is useful in performing accurate timing tasks. In this case, WinMain() counts ticks in order to determine when it should notify the game that a new cycle is in order. The iTickTrigger and iTickCount variables are used to establish the game cycle timing in WinMain().
The first function called in WinMain() is GameInitialize(), which gives the game a chance to be initialized. Remember that GameInitialize() is a game event function provided as part of the game-specific code for the game; therefore, it isn't a direct part of the game engine. A method that is part of the game engine is Initialize(), which is called to get the game engine itself initialized. From there, WinMain() enters the main message loop for the game program. The else part of the main message loop is where things get interesting. This part of the loop first checks to make sure that the game isn't sleeping and then uses the frame delay for the game engine to count ticks and determine when to call the GameCycle() function to trigger a game cycle event. WinMain() finishes up by calling GameEnd() to give the game program a chance to wrap up the game and clean up after itself.
The other standard Windows function included in the game engine is WndProc(), which is very simple because the HandleEvent() method of the GameEngine class is responsible for processing Windows messages:
LRESULT CALLBACK WndProc(HWND hWindow, UINT msg, WPARAM wParam, LPARAM lParam)
{
// Route all Windows messages to the game engine
return GameEngine::GetEngine()->HandleEvent(hWindow, msg, wParam, lParam);
}
All WndProc() really does is pass along all messages to HandleEvent(), which might at first seem like a waste of time. However, the idea is to allow a method of the GameEngine class to handle the messages so that they can be processed in a manner that is consistent with the game engine.
Speaking of the GameEngine class, now that you have a feel for the support functions in the game engine, we can move right along and examine specific code in the GameEngine class. Listing 2.3 contains the source code for the GameEngine() constructor and destructor.
Initializing Variables

Listing 2.3 The GameEngine::GameEngine() Constructor Takes Care of Initializing Game Engine Member Variables, Whereas the Destructor is Left Empty for Possible Future Use
GameEngine::GameEngine(HINSTANCE hInstance, LPTSTR szWindowClass,
LPTSTR szTitle, WORD wIcon, WORD wSmallIcon, int iWidth, int iHeight)
{
// Set the member variables for the game engine
m_pGameEngine = this;
m_hInstance = hInstance;
m_hWindow = NULL;
if (lstrlen(szWindowClass) > 0)
lstrcpy(m_szWindowClass, szWindowClass);
if (lstrlen(szTitle) > 0)
lstrcpy(m_szTitle, szTitle);
m_wIcon = wIcon;
m_wSmallIcon = wSmallIcon;
m_iWidth = iWidth;
m_iHeight = iHeight;
m_iFrameDelay = 50; // 20 FPS default
m_bSleep = TRUE;
}
GameEngine::~GameEngine()
{
}
The GameEngine() constructor is relatively straightforward in that it sets all the member variables for the game engine. The only member variable whose setting might seem a little strange at first is m_iFrameDelay, which is set to a default frame delay of 50 milliseconds. You can determine the number of frames (cycles) per second for the game by dividing 1,000 by the frame delay, which in this case results in 20 frames per second. This is a reasonable default for most games, although specific testing might reveal that it needs to be tweaked up or down. Keep in mind that you should always shoot for the highest frame rate (lowest frame delay) possible that allows your game to run smoothly; you don't want to see a game slowing down because it can't keep up with a high frame rate.
The Initialize() method in the GameEngine class is used to initialize the game engine. More specifically, the Initialize() method now performs a great deal of the messy Windows setup tasks, such as creating a window class for the main game window and then creating a window from the class. Listing 2.4 shows the code for the Initialize() method.
Listing 2.4 The GameEngine::Initialize() Method Handles Some of the Dirty Work that Usually Takes Place in WinMain()
BOOL GameEngine::Initialize(int iCmdShow)
{
WNDCLASSEX wndclass;
// Create the window class for the main window
wndclass.cbSize = sizeof(wndclass);
wndclass.style = CS_HREDRAW | CS_VREDRAW;
wndclass.lpfnWndProc = WndProc;
wndclass.cbClsExtra = 0;
wndclass.cbWndExtra = 0;
wndclass.hInstance = m_hInstance;
wndclass.hIcon = LoadIcon(m_hInstance,
MAKEINTRESOURCE(GetIcon()));
wndclass.hIconSm = LoadIcon(m_hInstance,
MAKEINTRESOURCE(GetSmallIcon()));
wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
wndclass.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
wndclass.lpszMenuName = NULL;
wndclass.lpszClassName = m_szWindowClass;
// Register the window class
if (!RegisterClassEx(&wndclass))
return FALSE;
// Calculate the window size and position based upon the game size
int iWindowWidth = m_iWidth + GetSystemMetrics(SM_CXFIXEDFRAME) * 2,
iWindowHeight = m_iHeight + GetSystemMetrics(SM_CYFIXEDFRAME) * 2 +
GetSystemMetrics(SM_CYCAPTION);
if (wndclass.lpszMenuName != NULL)
iWindowHeight += GetSystemMetrics(SM_CYMENU);
int iXWindowPos = (GetSystemMetrics(SM_CXSCREEN) - iWindowWidth) / 2,
iYWindowPos = (GetSystemMetrics(SM_CYSCREEN) - iWindowHeight) / 2;
// Create the window
m_hWindow = CreateWindow(m_szWindowClass, m_szTitle, WS_POPUPWINDOW |
WS_CAPTION | WS_MINIMIZEBOX, iXWindowPos, iYWindowPos, iWindowWidth,
iWindowHeight, NULL, NULL, m_hInstance, NULL);
if (!m_hWindow)
return FALSE;
// Show and update the window
ShowWindow(m_hWindow, iCmdShow);
UpdateWindow(m_hWindow);
return TRUE;
}
This code is similar to the Skeleton program example found in Appendix C, and it should be familiar to you if you've done any Windows programming using the Win32 API. An important thing to note in this code is how it determines the game application window size, which is calculated based on the size of the game client area. The GetSystemMetrics() Win32 function is called to get various standard window sizes, such as the width and height of the window frame, as well as the menu height. The position of the game application window is then calculated so that the game is centered on the screen.
The window styles used to describe the main game window are WS_POPUPWINDOW, WS_CAPTION, and WS_MINIMIZEBOX, which result in a window that is not resizable and can't be maximized; however, it does have a menu and can be minimized.
The Initialize() method is a perfect example of isolating generic Windows program code and moving it into the game engine. Another example of this approach is the HandleEvent() method, which is shown in Listing 2.5.

The Game Event Functions
The first place to start in creating a game engine is to create handler functions that correspond to the game events mentioned earlier in the chapter. When an event occurs in a game, the corresponding event handler function will be called, which gives your game a chance to respond accordingly. The following are these functions, which should make some sense to you because they correspond directly to the game events:
BOOL GameInitialize(HINSTANCE hInstance);
void GameStart(HWND hWindow);
void GameEnd();
void GameActivate(HWND hWindow);
void GameDeactivate(HWND hWindow);
void GamePaint(HDC hDC);
void GameCycle();
The first function, GameInitialize(), is probably the only one that needs special explanation simply because of the argument that gets sent into it. I'm referring to the hInstance argument, which is of type HINSTANCE. This is a Win32 data type that refers to an application instance. An application instance is basically a program that has been loaded into memory and is running in Windows. If you've ever used Alt+Tab to switch between running applications in Windows, you're familiar with different application instances. The HINSTANCE data type is a handle to an application instance, and it is very important because it enables a program to access its resources since they are stored with the application in memory.
The GameEngine Class

The GameEngine Class
The game event handler functions are actually separated from the game engine itself, even though there is a close tie between them. This is necessary because it is organizationally better to place the game engine in its own C++ class. This class is called GameEngine and is shown in Listing 2.1.

Note - If you were trying to adhere strictly to object-oriented design principles, you would place the game event handler functions in the GameEngine class as virtual methods to be overridden. However, although that would represent good OOP design, it would also make it a little messier to assemble a game because you would have to derive your own custom game engine class from GameEngine in every game. By using functions for the event handlers, you simplify the coding of games at the expense of breaking an OOP design rule. Such are the trade-offs of game programming.

Listing 2.1 The GameEngine Class Definition Reveals How the Game Engine Is Designed
class GameEngine
{
protected:
// Member Variables
static GameEngine* m_pGameEngine;
HINSTANCE m_hInstance;
HWND m_hWindow;
TCHAR m_szWindowClass[32];
TCHAR m_szTitle[32];
WORD m_wIcon, m_wSmallIcon;
int m_iWidth, m_iHeight;
int m_iFrameDelay;
BOOL m_bSleep;
public:
// Constructor(s)/Destructor
GameEngine(HINSTANCE hInstance, LPTSTR szWindowClass, LPTSTR szTitle,
WORD wIcon, WORD wSmallIcon, int iWidth = 640, int iHeight = 480);
virtual ~GameEngine();
// General Methods
static GameEngine* GetEngine() { return m_pGameEngine; };
BOOL Initialize(int iCmdShow);
LRESULT HandleEvent(HWND hWindow, UINT msg, WPARAM wParam,
LPARAM lParam);
// Accessor Methods
HINSTANCE GetInstance() { return m_hInstance; };
HWND GetWindow() { return m_hWindow; };
void SetWindow(HWND hWindow) { m_hWindow = hWindow; };
LPTSTR GetTitle() { return m_szTitle; };
WORD GetIcon() { return m_wIcon; };
WORD GetSmallIcon() { return m_wSmallIcon; };
int GetWidth() { return m_iWidth; };
int GetHeight() { return m_iHeight; };
int GetFrameDelay() { return m_iFrameDelay; };
void SetFrameRate(int iFrameRate) { m_iFrameDelay = 1000 /
iFrameRate; };
BOOL GetSleep() { return m_bSleep; };
void SetSleep(BOOL bSleep) { m_bSleep = bSleep; };
};
The GameEngine class definition reveals a subtle variable naming convention that you might or might not be familiar with. This naming convention involves naming member variables of a class with an initial m_ to indicate that they are class members. Additionally, global variables are named with a leading g_ to indicate that they are globals. This convention is useful because it helps you to immediately distinguish between local variables, member variables, and global variables in a program. The member variables for the GameEngine class all take advantage of this naming convention.
The GameEngine class defines a static pointer to itself, m_pGameEngine, which is used for outside access by a game program. The application instance and main window handles of the game program are stored away in the game engine using the m_hInstance and m_hWindow member variables. The name of the window class and the title of the main game window are stored in the m_szWindowClass and m_szTitle member variables. The numeric IDs of the two program icons for the game are stored in the m_wIcon and m_wSmallIcon members. The width and height of the game screen are stored in the m_iWidth and m_iHeight members. It's important to note that this width and height correspond to the size of the game screen, or play area, not the size of the overall program window, which is larger to accommodate borders, a title bar, menus, and so on. The m_iFrameDelay member variable indicates the amount of time between game cycles in milliseconds. Finally, m_bSleep is a Boolean member variable that indicates whether the game is sleeping (paused).

The GameEngine constructor and destructor are defined after the member variables, as you might expect. The constructor is very important because it accepts arguments that dramatically impact the game being created. More specifically, the GameEngine() constructor accepts an instance handle, window classname, title, icon ID, small icon ID, width, and height. Notice that the iWidth and iHeight arguments default to values of 640 and 480, respectively, which is a reasonable minimum size for game screens. The ~GameEngine() destructor doesn't do anything, but it's worth defining in case you need to add some cleanup code to it later.
I mentioned that the GameEngine class maintains a static pointer to itself. This pointer is accessed from outside the engine using the static GetEngine() method. The Initialize() method is another important general method in the GameEngine class, and its job is to initialize the game program once the engine is created. The HandleEvent() method is responsible for handling standard Windows events within the game engine and is a good example of how the game engine hides the details of generic Windows code from game code.
The remaining methods in the GameEngine class are accessor methods used to access member variables; these methods are all used to get and set member variables. The one accessor method to pay special attention to is SetFrameRate(), which sets the frame rate or number of cycles per second of the game engine. Because the actual member variable that controls the number of game cycles per second is m_iFrameDelay, which is measured in milliseconds, it's necessary to perform a quick calculation to convert the frame rate in SetFrameRate() to milliseconds.
The source code for the GameEngine class provides implementations for the methods described in the header that you just saw, as well as the standard WinMain() and WndProc() functions that tie into the game engine. The GameEngine source code also initializes the static game engine pointer, like this:
GameEngine *GameEngine::m_pGameEngine = NULL;

The Robotics community provides free resources pertinent to anyone in any industry interested in how technology can enhance quality of life. Here you’ll find Robotics technology industry news, blogs, feature articles, videos and more. Use these tools to educate yourself and stay current with what’s happening in Robotics .

Robotics technology is developing at a rapid pace, opening up new possibilities for automating tasks and enriching the lives of humans. From the automobile assembly line to automatic home vacuum cleaners, Robotics are a part of our world.
Talking about Simulations and robotics , we always can put both robotics and simulations put together , regarding bio-tech and simulations I guess virtualinfocom can provide bio-simulations .
Molecular dynamics--the science of simulating the motions of a system of particles--applied to biological macromolecules gives the fluctuations in the relative positions of the atoms in a protein or in DNA as a function of time. Knowledge of these motions provides insights into biological phenomena such as the role of flexibility in ligand binding and the rapid salvation of the electron transfer state in photosynthesis. Molecular dynamics is also being used to determine protein structures from NMR, to refine protein X-ray crystal structures faster from poorer starting models, and to calculate the free energy changes resulting from mutations in proteins.

Entrepreneurs yet to tap social networking fully’
Sukanto Mukherjee

 ‘TREAT your start-up as your own baby and nurture it’ – these were some of the insights shared by city-based entrepreneurs at a panel discussion on ‘Start Ups In Today’s Economy – Employment & Growth Factor’ at the Icfai Business School (IBS). The talk was part of Voyage 2010 — organised by IBS under the aegis of Entrepreneurship Week, India (February 6-13) initiative of National Entrepreneurship Network (NEN). Addressing an eager batch of B-school students and aspiring entrepreneurs were Arijit Bhattacharyya, CEO & founder of Virtual Infocom, and Prabuddha Sankar Raychaudhuri, CEO of SEOguru — both city-based it start-ups.
    Besides having a viable business plan and customised marketing strategies, both Mr Bhattacharyya and Mr Raychaudhuri stressed on the power of social networking as a business tool.
    “In an era when communication happens with a single mouse click, social networking sites like Twitter and Facebook are of immense help to start-up entrepreneurs, especially if they want to reach out to the global markets,” said Mr Bhattacharyya.
    On the other hand, ‘the potential of social networking is yet to be tapped fully by entrepreneurs in India’, felt Mr Raychaudhuri. But, as clichéd as it may sound, passion is of utmost importance when starting a business, felt both the entrepreneurs.
    “One should be prepared to make long-term sacrifices if he or she wants the business to take off, which is possible only if one has loads of passion and does not run after the money from day one,” Mr Raychaudhuri said.
    Adding an anecdote from his personal life, Mr Bhattacharyya said: “I dreamt of being a game developer when I was in school.” Considering that Infosys was started by NR Narayana Murthy and his friends with small capital but big dreams and that it took 13 years to reach where it is today, the role of passion for an entrepreneur has been underscored time and again.
    Both the speakers also highlighted the fact that recession is actually a good time to start a business. The downturn can be used to scale up, they remarked. “There is access to capital like skilled manpower at 50-60% lesser cost than in normal situations,” said Mr Raychaudhuri.
    At the same time, during the initial stages of a business, the entrepreneur must market the product himself, as he or she cannot afford to hire top-notch managers. Also, there should be sufficient bank balance for at least three-six months to take care of family needs, considering the risks involved, felt both the speakers.
    At the same time, ‘money is not the main constraint in an IT business’, said Mr Bhattacharyya. On the trend of Indian IT companies selling more services rather than their own products, Mr Raychaudhuri said: “Whereas a product takes at least $50,000 and 18-24 months to develop, a service can be enabled much faster and at cheaper rates. But, selling a service is much tougher, especially when one has to compete with global giants.”  Hence, an IT entrepreneur must keep all marketing options open, he concluded.