• Advertisement

Gav

Member
  • Content count

    73
  • Joined

  • Last visited

Community Reputation

124 Neutral

About Gav

  • Rank
    Member
  1. using 'new' and 'memmove' properly

    One thing i noticed is that the call to new in the else block isn't creating an array but you try to delete it as if it is. ie it should probably read m_Accounts = new SBWPDataEntry[1]; otherwise delete [] temp will probably go wrong. After the second allocation of new does m_Accounts actually equal null? If new returns null it is out of memory... also, as m_Accounts and temp are pointers should the memmove call actually be: memmove(m_Accounts, temp, sizeof(SBWPDataEntry)*m_intNumRecords); ie without the ampersands? otherwise you're trying to copy from address of temp which is on the stack rather than what it is pointing to. Likewise you are copying to the location of m_Accounts, not to where m_Accounts is pointing?
  2. My almost good idea (SDL)

    I did a similar thing on a DirectX game I was working on. My process was (i think, it was a while): Have a surface containg your uncoloured main sprite image Create another surface that is just the new colour you want to colour your original with Set the colour key of the first image to be that of the area you want to change (in my program different areas of the image had different colours so I could colour them differently) Blt the main image onto your new surface. The new surface should now contain the original image except for the area that is the same as the colour key which should now have the new colour. You can repeat this for each different area of your image you want to colour. I think this process is slightly different to yours in that in mine you blt the main onto the new, where as yours seems to be the other way round. I believe this method is quicker than manually changing the pixels. Plus it avoids all the issues with different colour formats and varying pitches of the surface, amongst other things.
  3. I'd say the 2nd option is better as it's more readable - you're explicitly stating which foot to use rather than relying on the ! operator to alternate between 0 and 1. Having said that i'd be tempted to replace 0 and 1 by an enum to make it even more readable eg enum EFoot { eLeftFoot = 0, eRightFoot = 1, eMaxFeet }; // Start on certain foot when turning mostly around, depending on which direction planning to turn if( MoveDirection.AngleLength( Forward ) > PI / 2 ) { // Start on foot opposite to our new direction (eLeftFoot or eRightFoot) NextStartIndex = ( Forward.CrossY( MoveDirection ) < 0.0f ) ? eRightFoot : eLeftFoot; // Reverse if the movement anim plays with right foot stepping first if( Animation->CheckFlag( ANIM_BACKWARDS ) ) NextStartIndex = ( NextStartIndex ) ? eLeftFoot : eRightFoot; // Also reverse (again) if stance is mirrored if( State.Anim.CheckFlag( STATE_ANIM_MIRROR ) ) NextStartIndex = ( NextStartIndex ) ? eLeftFoot : eRightFoot; }
  4. Collision Problem

    I believe your method of calculating the centre point is wrong and should be like this: // Calculate the vector between player i and player j int diffx = players[i].getX() - players[j].getX(); int diffy = players[i].getY() - players[j].getY(); // Find the midpoint along the vector from player j to player i // I.e. move half the distance from player j to player i // Note if you didn't have the divide by 2 you'd end of with the position of // player i boomx = players[j].getX() + (diffx /2); boomy = players[j].getY() + (diffy /2); It may help to sketch out what this code is doing. Try having player j at (0,0) and player i at (10,10)
  5. Alternatives to STL?

    it makes sense because std::pair can be more than just a value in a std::map so naming the values key and value would make it too specific. There could've been std::mappair but that would go against object re-use. (change my wording slightly) [Edited by - Gav on March 2, 2005 1:46:04 PM]
  6. memory management problem

    Memory allocation isn't cheap so doing lots of news and deletes each frame may harm your frame rate. Also, with all your news and deletes you may be fragmenting memory again harming your frame rate. Lastly, are you sure it's a memory leak problem? If you have task manager open whilst running your program does your program's memory usage keep going up?
  7. Blanking out character arrays

    you can do memset( littleForm1.field, ' ', sizeof( littleForm1.field ) ); memset( littleForm2.anotherField, ' ', sizeof( littleForm2.anotherField ) ); or even _strnset( littleForm1.field, ' ', 500 ); _strnset( littleForm2.anotherField, ' ', 500 );
  8. Tic-Tac-Toe Problem

    I'm assuming the ouput is 49? The reason for this is you are putting the character code for the number 1 into your array, not the actual number 1. Your code should read board[0][second] = 1;
  9. Problems with a really small program.

    the reason the else if isn't being executed is because you're missing an equals sign. In C equality is tested using == whereas assignment uses = Therefore your else if should read: else if (state == OUT){
  10. what's the value of intHook? if it's bigger than the size of the arrHooks array you could run into problems. Also, what's the value of arrObjects[l].intX after each line of code? does it change when you step onto the current line shown? seeing the structures/classes would be helpful as well. As would the code that creates the arrays.
  11. I'm running version 8.0.40607.16 (beta1.040607-1600) and that code compiles fine. Not that that's much help to you, sorry.
  12. And OutputDebugString will output debug info to the output window of the Visual Studio IDE
  13. Are you sure you're passing the files in in the right order? I ran the code and the reading in of the data was fine.
  14. simple file input question

    if you're using C/C++ you could always use the strtok function. First read in the entire line and then pass it to the function. I think java has a similar string tokeniser function.
  15. I think there are two main reasons for this 1) You can change the DLL without having to rebuild the EXE. Useful if different people are working on different areas of your game. 2) Multiple programs can use the same DLL. This means the EXE can be smaller both on disk and in memory. For example the windows user32.dll DLL (which contains icons and user mode functions) could be statically linked into every windows program available but is rather memory inefficient. Applying this to a game scenario, you could have a 3d engine in a DLL which your users download once. Then they could download different games which use this engine rather than having to keep downloading the engine for each game leading to smaller downloads for them.
  • Advertisement