Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

176 Neutral

About HAM

  • Rank

Personal Information

  • Interests
  1. HAM

    Game programming - books?

    For 3D math related to games I would recommend:   3D Math Primer for Graphics and Game Development, Second Edition. http://gamemath.com/about-the-book/   The book is not dumbed down but presents the math as it relates to graphics and games.
  2. For games, especially if you are designing, you are much less an engineer and much more a sculptor, constantly pushing and pulling things around, removing unneeded bits and adding extra bits.  Plan for things to change,    Get a playable version as fast as possible. Even if it all gets thrown away. Prototyping is a design step, a pre-production step. Its going to help in planning and identifying what really needs to be implemented. Design up front just enough to get a good idea of what you really need. Implement the minimal amount. Schedule the minimal amount. Art and sound and nice assets can wait.  Make things work first.   And the last thing is my personal law for programming.  It might sound stupid but it helps in about a million ways. Never write a function longer than 50 lines (including white space and comments).  Decompose. make it fit on a single page.  
  3. HAM

    I think my school missed some steps...

    I would echo peoples comments about 'this is how you learn.'   It's not uncommon in an academic setting to stay within the bounds of console apps, DOS prompts, and web scripting.  Academia typically focuses on theory and not application.  And command line apps are sufficient to teach theory.  Its only when you get into specialty courses, like game programming, that you would need to start dealing with application.   So yeah you are probably in a 'trial by fire' situation.  There are actually a few studies, about computer science courses and students, that show that you really can't teach programming.  You can teach analysis, data structures, algorithms, but not programming. The mind set and the skills to solve problems analytically, you will have developed before you ever stepped into a programming class, or you'll never have them.   Your number one skill as a programmer is problem solving.  Honestly the title 'programmer' should just be replaced with 'Problem Solver.'  It has nothing to do with computers. It just so happens computers are great tools for solving problems and more importantly create tons of problems.  The key problem you will have to solve over and over for yourself is how to get up and running when you don't have the knowledge or skills.   The trial by fire is constant and continuous.  As a programmer you will more than likely always be working in an area that you have no experience in, until you do, then you move on to another area you have no experience in.   You are right to be worried about getting something finished. Making games is hard.  But not too worried.  This will be your normal operating mode.  There is always too much to do and you always know too little.  If that isn't the case then you probably aren't pushing yourself.   Have fun.
  4. You could do this plenty of ways but your idea about using an integer instead of a pointer is sensible.  I'd suggest looking into that more. Using an integer or a handle or really any mechanism for keeping a 'name' to your referenced object would be better than keeping a pointer directly all the time.  And as you've already guessed you can start limiting how much of your code needs to know specifics like what a Sprite is.
  5. HAM

    games for phones

    I would echo any suggestions for starting with existing packages rather than trying to choose a language.   Unity, UDK, cocos, etc...   These are cross platform and fully featured.  They will take care of alot of details and you can probably get up and running pretty quick.
  6. HAM

    Texture mapping question

    I'm not sure how far along you are on this but I would suggest tackling this step by step. Forget about obj files and cylinders. Draw an untextured quad on the screen. (Two triangles forming a square) Do this manually creating the vertex and index buffers and filling in the vertex data yourself. Load a texture.  In this case your jpeg. Now draw the quad with the texture mapped At this point you will know what you need to deal with your problem. You'll know: How to deal with vertex and index buffers How to load an image and create a texture How to construct the vertex data and set UVs How to bind the texture and draw textured geometry. Once you know all that, then all you have to do is find where the obj file is loaded and when it creates the vertex data from it.  Once you know that you can write your UVs into that data.  You may have to change the vertex type and declaration.  Then your last challenge would be to figure out the math to get your UVs correct.   However, even though I think you would learn alot from doing this I wouldn't suggest changing or adding UVs in this way.  I'm sure the obj file format can store your UVs and you should probably be setting up the UVs in the modeling package that exported the obj file.     For simple shapes like boxes, quads, cylinders, spheres, I would suggest not using an obj file at all.  Create them yourself in code, if for no other reason other than to familiarize yourself with how to construct them and manipulate them.     You would need this knowledge if you then wanted to go back and start manipulating the data from the obj file.
  7. You might not have provided enough information for someone to help.  But I'll take a stab.  Also I think you have a typo and missed a comma in the code you did post.   I am assuming 'score' is an int and the function, TTF_RenderText_Solid is expecting a char* for the second arguement.   A simple way to do this would be:       char textBuffer[64]; sprintf(textBuffer, "%d", score); // Write the int 'score' into a char buffer TTF_RenderText_Solid(font, textBuffer, textColor);   sprintf works just like printf but writes into a char buffer instead of standard out.   The error you received was pretty straight forward.  You were trying to use a variable of type 'int' when a variable of type 'char*' was expected.
  8. HAM

    Basic movement (with shapes)

    If what I said didn't make sense, let me know and I'll try to be more clear.   Otherwise, good luck.  I bet you've got it by now.
  9. HAM

    Help, I've optimized too much!

      Well since you can run at 200 FPS that means you are not CPU bound.  And for simplicity sake why not just keep it like you have it.     Lock to vsync.   This will lock you state updates, input, and rendering.  If you start wanting to run at lower than 60 that is when it might become a concern for your input timings.    But you'll create more input woes if you want to start threading anyway, so why not keep it as simple as possible until you need something more.
  10. HAM

    Help, I've optimized too much!

    Really? they didn't buzz before. I mean before rework... The CPU usage would be the same with or without optimization with your description so strange... I'm not sure why you would assume his CPU load would be the same when he runs at 50 FPS vs 170 FPS, but it is not relevant.  He asked how to limit his FPS.  
  11. HAM

    Help, I've optimized too much!

    Well the concept is the same.  Just wait on vsync.  I'm sure there is a way to do it in openGL.   A quick google search shows wglSwapIntervalEXT as an extension.  Unsure if that is what you should use.  But I'm sure you can figure it out.
  12. HAM

    Help, I've optimized too much!

    Probably just waiting on VSync would do it.   If you are using DirectX lookup the present parameters and something like D3DPRESENT_INTERVAL_ONE.   So if your monitors refresh rate is 60hz.  Then your FPS will be 60 at most.   That would be a pretty straight forward way to limit your FPS.   For lower values there is D3DPRESENT_INTERVAL_TWO and THREE i think.   For sleep times you could just track your frame and sleep until 1/60th of second as passed; That sounds kinda weird to me though.          
  13. HAM

    Basic movement (with shapes)

    In the UpdateScene the Translation matrix is going to change your objects posiiton.   In this case your three verts: (0.0f, 0.5f, 0.5f) (0.5f, -0.5f, 0.5f) (-1.0f, -0.5f, 0.5f)   get translated by (0, 10, 0) and become (0.0f, 10.5, 0.5) (0.5f, 9.5f, 0.5f) (-1.0f, 9.5f, 0.5f)   So if you want to move your object around just store a Vertex for its position:   Vertex currentPosition;   Then in UpdateScene use your variable:   Translation = XMMatrixTranslation(currentPosition.x, currentPosition.y, currentPosition.z);   And now you control where those verts get drawn by changing the variable 'currentPosition'.
  14. The warnings don't really matter. The errors are link errors. If you look at the documents page for DirectDrawCreatEx you'll find what lib you need: http://msdn.microsoft.com/en-us/library/windows/desktop/gg426116(v=vs.85).aspx Then in the project settings, linker section, make sure you are linking to that lib. However, I honestly don't even know if DirectDraw functions are still part of directX sdk. That is pretty old stuff. But I suppose it would still be in the libs for directX 9.c
  15. HAM

    Basic movement (with shapes)

    You can do either one. But what you are probably failing to understand is that all the drawing occurs with a single matrix. In your code you'll probably find somewhere that multiplies three matrices together: World * view * projection All three get multiplied together producing a single matrix that every vert is multiplied by. Typically you will use this terminology, and three separate matrices, because its pretty standard and helps you mentally keep separate the object position, camera position, and projection. But it doesn't really matter if you change the world or view matrix to draw an object in a different place on the screen. Because what matters is the final matrix the vert gets multiplied with. There is always a way to modify either the world or view matrix to produce the same result. But usually if you are wanting to move an object, then you store a position ( a single 3d vector) for it, and move that position around. When it comes to drawing the object you then setup the world matrix to translate the objects position. If you are wanting to move a camera around, then you normally store a camera position and move it around. When it comes time to drawing you setup the view matrix to translate the camera position. That is the basic idea. There is a ton of little details and honestly you can do it any way you want, as long as that final matrix you multiply every vert by gets those verts into the position you want. I would recommend Fletcher Dunn's 3D game math book if you are confused about the matrices and verts and how those end up deciding what gets on the screen.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!