• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

102 Neutral

About JoshuaHoffmann

  • Rank

Personal Information

  1. Merry Christmas! Don't eat too much sugar like I just did, or else you'll feel it!
  2. [quote name='hick18' timestamp='1322223704' post='4887597'] The newest being WinRT which from what I understand is a new version of the win32 API, which unlike the .net version is not built on top of the current win32 api but is instead a rewrite (something which wikipedia seems to disagree on)..... but only seems to work with metro apps? why is this? [/quote] My understanding is that WinRT implements only a subset of Win32 API functions, plus functions which are exclusive to WinRT. A Metro app is only allowed to call WinRT functions. Metro apps can't call Win32 API functions that are not in WinRT. This sort of acts like a security sandbox which prevents Metro apps from doing "insecure" things. Additionally, Metro apps have some sort of manifest where they declare which features they're going to use. If a Metro app tries to use a feature (such as connecting to an Internet server), but said feature is not in the manifest, then that function will fail. When a user installs a Metro app from Microsoft's store (and Metro apps must come from there), Windows 8 will examine that manifest and put up a prompt that tells the user what permissions the app needs. At least that's how I understand it. EDIT: Also, since Metro apps will also run on ARM processors, maybe Microsoft found it better to make an ARM version of WinRT, rather than the whole entire Win32 API.
  3. STL, yay or nay?

    EDIT: Just noticed Ravyne's post... he said what I was trying to say better than I did. About seven years ago (2004), I used STL in one of my projects. Back then, I was still using Visual C++ 6.0. Then I decided to look into porting that project to Linux. I figured a good "stepping stone" would be to compile it using a Windows version of GCC. I can't remember if it was MingW or Cygwin. GCC gave all sorts of compiler errors, and they were caused by differences between how STL is implemented in different compilers. So I decided to replace all usage of STL classes with my own custom-made classes, where I could guarantee that if it compiles in one compiler, then it'll compile in others. I figured I wouldn't have to worry about STL having "breaking changes" in "future" compilers such as Visual C++ 2005 and updates to GCC. I found other problems with STL too. So I've been using my own custom classes since then. Because of that, I don't really know if all these problems with STL have been solved in the newest compilers like Visual C++ 2010 and the newest versions of GCC. Now I regret not using STL recently as I've been applying for jobs and I wind up taking tests which ask STL questions. And that particular job description didn't even mention STL. I guess some people feel that if C++ is mentioned in the job description, then knowledge of STL is implied. So if I were in your shoes, I would use STL. However, be prepared for the possibility that you may run into weird problems with STL later on. I would make your code flexible enough that you could substitute custom classes in place of STL classes later on if the need arises.
  4. Organising engine

    I don't know if this answers your specific questions, but I have some background that might help. My game, Land of Smiley Cubes, separates modules into DLLs as well. Since I may want to port my game to Mac or Linux someday, only a few modules are allowed to call Windows API functions. Most modules must call methods in another module in order to do certain things. For example, I have my low level graphics code in a module called: JTH3D_Direct3D9.dll Any code which calls Direct3D 9 methods is in there. None of my other modules call Direct3D methods. They must go through JTH3D_Direct3D9 to render graphics. The advantage of this is that in the future, I could write new "JTH3D Drivers" with names like: JTH3D_OpenGL.dll JTH3D_Direct3D11.dll JTH3D_Direct3D10.dll JTH3D_Direct3D9Ex.dll So if I wanted my game to support OpenGL, then I would just write JTH3D_OpenGL.dll. I wouldn't have to modify or even recompile my other modules/DLLs. I could just "swap in" JTH3D_OpenGL for JTH3D_Direct3D9, and it would just work. Here's my list of DLLs: JTHAccountServer.dll - Server Only - Implements account server for logging in, authentication JTHAudio_XAudio2.dll - Client Only - Implements all sound code. If I decided XAudio2 had problems, I could write a different "JTHAudio driver" (example: JTHAudio_DirectSound9.dll) and swap it in. JTHBase_Win32.dll - Server/Client - Implements certain functions that need calls to Windows API such as high resolution timers, critical sections, mutexes, etc. JTHBitmap.dll - Client Only - Implements code that has to do with bitmap manipulations. JTHControlHost_Bitmap.dll - Client Only - Implements UI (hence, a "host for controls".) This name is for historical reasons; these days, I ought to name it JTHControlHost_JTH3D.dll since it makes calls to the JTH3D module. JTHControls.dll - Client Only - Implements UI controls such as buttons, text boxes, labels, checkboxes, frame windows, etc. JTHEntities.dll - Server/Client - Stores game world entities and their attributes in tables. The server version also contains code for storing/retrieving entity data in a MySQL database. JTHPhysics.dll - Server/Client - Physics routines JTHRealmServer.dll - Server Only - The main realm server code. JTHSock_Win32.dll - Server/Client - Low level code for client and server to talk to each other over the Internet using Winsock functions. NPCClient.dll - Server Only - All code for AI (NPCs). This runs in a separate thread. In theory, NPCClient could run in a separate process, or even a remote computer. It actually connects to JTHRealmServer the same way human players do with their clients. NTNManager.dll, RemoteNode.dll, GameNetworkCmdProcessor.dll - Some high level client/server communication code that's hard to explain. GameEngine.dll, GameEntities.dll, GameLookupTables.dll - Misc. high level code. SmileyCubes.exe - The game client executeable that ties everything together. SmileyCubeServer.exe - Game server executeable that's run as a service. It just simply runs JTHRealmServer.dll and JTHAccountServer.dll. Another advantage of this is in my debug build only, I have the game client load and run JTHRealmServer.dll so that there's a "loopback server" running. I have a single Visual C++ 2010 solution for the whole game (both client and server in one solution), although each DLL and EXE has its own project in this solution. I hope this information helps somehow. It works great for my game.
  5. Threading in Games

    Just as an example: My game, Land of Smiley Cubes, runs the computer controlled players (AI) on a separate thread. The key is that this separate thread has its own copy of the game world in memory. So it does not need to enter a critical section or mutex to do things like physics, checking for nearby "enemy" (human) players, etc. When this second thread moves the computer controlled player, it sends a message through a pipe to the main thread. That way, the main thread can update its copy of the game world with the computer player's new location. Likewise, if the world "changes" in some way, the main thread also sends messages to the AI thread through a pipe, so the AI thread can update its copy of the world. The downside of this approach is that it uses more memory. For my game, that's a tradeoff I'm willing to make. Another good candidate for multi-threading is a separate thread devoted to music and sound. Again, your main thread would send messages through some sort of pipe to tell the sound thread to play sounds.
  6. Land of Smiley Cubes is a free 3D MMORPG and MMORTS for Windows available for download at [url="http://landofsmileycubes.com"]landofsmileycubes.com[/url]. - Players build blocks to earn points. - All players are ranked on a real-time leaderboard. - Destroy other players' blocks so they lose points and go down in rank! - Build defenses around your blocks. - Build your own house! And defend it! - Destroy other players' houses! - Persistent world. Your blocks keep working while you're logged off. - Fight monsters to gather resources needed for block building. In-game footage: [media]http://www.youtube.com/watch?v=3033Y0Ejyug[/media] Requires Windows XP, Vista, or 7. Windows XP users need Service Pack 2. Land of Smiley Cubes is free to download and play from [url="http://landofsmileycubes.com"]landofsmileycubes.com[/url]. If anyone has any suggestions, including on how to improve the Land of Smiley Cubes, please feel free to reply to this thread. Constructive criticism, whether positive or negative, is welcome! Thank you!
  7. I'm wondering if sprintf_s might be useful here (if you're targeting Windows) for guarding against buffer overruns. If your program is targeting non-Windows platforms (like Mac or Linux), I wonder if there's equivalents to sprintf_s out there.
  8. Math and game development

    [quote name='Habbala' timestamp='1322070860' post='4886950'] [i]If object A is at (x,y) and I need to move it to (x,y) in 1200 milliseconds, where should it be in 36 milliseconds?[/i] [/quote] Did you mean that to be a trick question? If it was meant to be phrased this way: If object A is at (x[b]1[/b],y[b]1[/b]) and [b]it needs to be at[/b] (x[b]2[/b],y[b]2[/b]) in 1200 milliseconds, where should it be in 36 milliseconds? [b](Assuming the object's velocity stays the same the whole time.) (Assuming object travels in straight line.)[/b] Then I would answer: 1. Vector vDiff = v2 - v1; 2. vDiff = vDiff * (36.0 / 1200.0); 3. Vector vAnswer = v1 + vDiff; 4. I would single-step through this code with the debugger; using watches to make sure everything is correct. Now, if the object's velocity was changing due to acceleration, friction, etc., then the answer is quite different. And the answer would be different if the object couldn't travel in a straight line.
  9. Land of Smiley Cubes

  10. Im new to this programming world, help please.

    To know if programming is fun, you have to do it. If I were in your shoes, I'd head to Barnes & Noble (or somewhere like that) and get a good book on C++ programming. Read it and do the exercises. In addition to that, it might be fun to set little goals. When I started, one of my first goals was: "Make a simple program where the window is solid black, and there's a yellow box in it. When I press an arrow key, that yellow box moves in that direction." After I made that simple program, I tried making enhancements to that program, one by one. They would be things like: "Make it so the yellow box can't go outside the window." "Make it so the yellow box moves 10 pixels per second no matter how fast the PC is. Use a high resolution timer to do this." "Instead of using GDI for this program, try using Direct3D or OpenGL to clear the screen black and draw the yellow box instead." "Make it possible to move the yellow box by using the mouse." And every time I did one of those things, I learned a little bit more. And the little things I learned allowed me to try bigger things like: "Change the yellow box into a picture of something." "Have more than one yellow box and make it so you can use the TAB key or mouse to select which one you want to move." "When you press a key, your yellow box shoots a big dot. If that big dot hits another box, that box disappears." "Each box has hit points. If a box gets hit by a big dot, it loses a hit point. If it runs out of hit points, then it disappears." I just kept trying things like that one at a time, and I learned a lot in the process. And it doesn't take 20 years. You can learn a lot in one year.
  • Advertisement