• Advertisement

pragma Fury

  • Content count

  • Joined

  • Last visited

Community Reputation

343 Neutral

About pragma Fury

  • Rank
  1. convert bstr to byte array

    A BSTR is basically a pointer to a byte array, so all you really need to do is this: BSTR b = SysAllocString(L"Hello World!"); BYTE *pBytes = (BYTE*)b; As a BSTR essentially points to the middle of a struct, the 4 bytes prior to the address pointed to the BSTR contains the length of the data should you desire to get it. int nNumBytesInBSTR = INT(*(pBytes-4)); But if you want to convert the BSTR to a char*, then you could use WideCharToMultiByte, just so long as you do not confuse BSTRs with WCHAR* in areas of memory management. char* sz(NULL); // determine the number of bytes required int nNumChars = WideCharToMultiByte(CP_UTF8, 0, b, -1, NULL, 0, NULL, NULL); if(nNumChars > 0) { // nNumChars includes the NULL terminator sz = new char[nNumChars]; memset(sz,0,nNumChars); // do the actual conversion WideCharToMultiByte(CP_UTF8,0,b,-1,sz,nNumChars,NULL,NULL); } Don't forget to release memory! delete [] sz; SysFreeString(b); You might also want to look into _bstr_t
  2. writing octal data to file in C++

    What is "info", what does it contain, and what exactly do you wish to view in the output? ie: if "info" is an integer containing 123456, do you want to see 361100?
  3. learn to program!

    Absolutely not. You must learn to walk before you can run. Unless you know how to program, getting experience with game development is darn near impossible. So learn all you can, never stop. Start by making some small games like tic-tac-toe, and work on your skillset. Once you feel you are up to speed, get involved with game mods or other groups like Starsiege 2845 All this counts towards your qualification. It is possible to get into the industry without any prior game development experience, but it's much harder.
  4. I think your grid idea is probably your simplest solution at this point, though there's no reason to hash it. If your grid is uniform, you just need to check all grid squares within units/square_width distance.. pseudo-code: // scanning left -> right, top -> bottom. int nGridSquares = message_radius / gridwidth; int nStartX,nStartY,nEndX,nEndY; nStartX = message_source.x; nStartY = message_source.y; nEndX = nGridSquares*2 + nStartX; nEndY = nGridSquares*2 + nEndY; for(int nY=nStartY; nY < nEndY; ++nY) { for(int nX=nStartX; nX < nEndX; ++nX) { // send the message to each creature for(int nCreature=0; nCreature < grid[nX][nY].creatures.count; ++nCreature) { // message stuff. } } } Of course, this won't give you a circle of influence, but a quick tweak would fix that. Another option is to do your messaging in a queued manner. When your creature performs a messagable action, the message and radius is pushed onto a queue. The next frame when you update your creature positions, have each check it's distance from the message source and react accordingly (for each message in the queue) You're still checking every object, but in a slightly smart way. :P
  5. Anyone knows the contour tracing algorithm?

    Quote:Original post by timaer Thanks pragma, but I'm afraid I can't read that tutorial,the link seems unavailing :( That's very unusual. It seems to be working for me right now.
  6. Anyone knows the contour tracing algorithm?

    Quote:Original post by timaer And hi, pragma Fury, could you tell me more how the contour tracing algorithm detect the line between the P and G, does that need collision test? thanks Yes, if you want to test for line of sight between P and G, you would need to do a collision test. If you're unfamiliar with the various forms of collision detection for objects in motion, here's a pretty decent page of tutorials. Check out Tutorial A for sure.
  7. Anyone knows the contour tracing algorithm?

    And contour tracing has it's issues. For example, assume you had this room, where "G" is the goal, and "P" is the player. +-----------------------+ | | | G | | | | | | | | |P | | | | | | | +----+ | | | | | | | +-----------------------+ If your contour tracing decides to make left hand corners, your player may get to here (periods show its path) +-----------------------+ | | | G | P| | | | ^| | | |. .| | | |....| | | +----+ | | | | | | | +-----------------------+ and realize nothing is stopping it from moving towards the goal... so it goes to the left and ends up against a wall.. starts making left hand turns, and gets stuck running in circles. And obviously it can't make the decision as to whether it can walk towards the goal based on direct line of sight, since in this scenerio, it will never have line of sight. +-----------------------+ | | | | | | | | | | | | | G | |P | | | | | | | | | | | | | +-----------------------+ I think A* is pretty straightforward and computationally more efficient than this. Edit: I forgot to mention that contour tracing will not help you at all with 3D terrain. It might be a good backup to use if the object encounters something in its path that wasn't handled by a more robust pathfinding algorithm though. [Edited by - pragma Fury on March 31, 2006 7:44:11 AM]
  8. Making an RPG game

    I'm with rpg_code_master on this one. Modding an engine that "does it all" will be a royal pain in the posterior. Even worse is trying to mould a FPS engine into a NWN-style RPG engine.. it's ... unpleasant. I have some experience in this. I would recommend looking into RPG Makers. Wikipedia has an entry on this, along with several external links RPGSource also has a listing
  9. re-sorting whenever new particles are inserted is trivial to implement, just have a dirty flag on your array. And really, sorting an array of 250 objects using qsort is blindingly fast. Another option would be to use a STL Set container (std::set<particle>) and implement whatever comparison operators it needs in your particle struct, it will auto-sort when inserted.. Edit: Did a quick test, sorting an array of 250 particle objects with random depths produced an average sort time (over 10,000 tests) of 0.22487ms with qsort, so it is pretty quick. Re-sorting an already sorted array took on average 0.073968ms.. practically nothing. And that's a debug build. Release build reduces those times to 0.063453ms and 0.013465ms respectively. Tests were done on a 2.2GHz AMD, times aquired using rdtsc. [Edited by - pragma Fury on March 28, 2006 2:30:37 PM]
  10. My thoughts: 1) Create the objects in the order of furthest to nearest in the first place, then there's no need for sorting at all. or 2) Since you're working on a 2D app, there's no need to constantly re-sort the particles once they're already sorted. Just when new ones are spawned. Look into quicksort (qsort) for a fast sorting algorithm. or 3) Game Programming Jems 5 has an article suggesting doing an incremental bubble-sort on the particles. Bubble sort is slow, but it can be stopped and resumed at a later date. The article suggests sorting as much of the array as you can within a given time-slice every frame, and then continue again on the next frame. So frame 1 you sort maybe 50 elements, frame 2 the next 50, and so on. There will be some artifacts, but they won't last long, especially with an array of only 250 elements.
  11. Spy! - [SOLVED]

    Quote:Original post by bakery2k1 Assuming Windows, I don't think there's any need for kernel-mode drivers etc. Ah, I was thinking he also wanted to look at the process's executable in memory as well.
  12. Spy! - [SOLVED]

    Well, having never tried it, I'm not sure, but I believe it would involve writing a kernel-level app, as user-level apps won't have access to another process's memory space. And then it's just a matter of figuring out where in that process's memory space the application code begins and go from there.
  13. C# strings.

    Regular expressions (once you understand them) are your friend. using System.Text.RegularExpressions; Regex rx = new Regex(@"\((\(.*?\))\)"); String sTest = "((#,R,2))((#,R,3)(#,R,4))((#,R,5))"; MatchCollection mc = rx.Matches(sTest); String[] aMatches = new string[mc.Count]; // populate the array for(int nMatch=0; nMatch < mc.Count; nMatch++) { aMatches[nMatch] = mc[nMatch].Groups[1].Value; } // aMatches[0] = (#,R,2) // aMatches[1] = (#,R,3)(#,R,4) // aMatches[2] = (#,R,5)
  14. Movement speed

    Yes, you're using a milliseconds/pixel scheme, instead of pixels/millisecond. So by increasing your Speed variable, you're basically increasing the number of milliseconds between pixels, thereby slowing your sprite/whatever down. What you want to do is determine that number (milliseconds) based on how fast you want it to move.. So say, you want Speed to be in pixels per second: void Critter::Move() { float fPixelsPerMillisecond = float(Attributes.Speed) * 0.001f; // same as dividing by 1000, but faster DWORD dwRequiredMillisecondsPerPixel = DWORD(1/fPixelsPerMillisecond); if(!moving || dwRequiredMillisecondsPerPixel < SDL_GetTicks()-lastMoveTime) return; // do move stuff lastMoveTime = SDL_GetTicks(); } So, if you wanted to move 60 pixels per second, the logic works out like this fPixelsPerMillisecond = 60*.001f = 0.06 dwRequiredMillisecondsPerPixel = 1/0.06 = 16 So 16 milliseconds must pass before you move 1 pixel, resulting in a speed of 60 pixels per second. If you wanted to move 100 pixels/second, the math works out to give you a time of 10 milliseconds/pixel. There are of course optimizations that can be done, like pre-computing dwRequiredMillisecondsPerPixel instead of doing it every time Move() is invoked, but I leave that to you. Also, since you're using SDL_GetTicks() and unsigned ints (DWORDS) for your timing, there'll be rounding issues.. the actual number of milliseconds you would want to wait for a perfect 60px/sec speed is 16.66666... You may want to consider using a high-performance timing system to get finer resolution, if speed values are that important. Look around the forums, at least one person asks how to do that every day. SDL_GetTicks() will also limit you to a maximum of 1000px/second .. which might be an issue, depending on your application. [Edited by - pragma Fury on March 25, 2006 9:22:18 AM]
  15. Movement speed

    Ok, so in your statement if(!moving || lastMoveTime < Attributes.Speed) return; Your critter will only move if more than "speed" milliseconds has elapsed since the last Move() call. However, you're resetting lastMoveTime every call, so basically, if you call move() 50 times and less than 1ms has elapsed between calls, nothing's gonna happen. I would change it to this: void Critter::Move() { // if we are not moving, dont bother calulating, also, enough ticks since last step must have passed DWORD dwDeltaTimeMs = SDL_GetTicks()-lastMoveTime; if(!moving || dwDeltaTimeMs < Attributes.Speed) return; // else, move doMoveStuff(); // reset the time lastMoveTime = SDL_GetTicks(); 1 px per millisecond might be a bit fast. You might want to consider using pixels/second instead of milliseconds/pixel.
  • Advertisement