Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

128 Neutral

About Eps

  • Rank
  1. I can't say I've ever gotten heavily involved in a message system so keep that in mind for the rest of this post. You may want to try something like the following. enum MESSAGE_TYPES_E {BASE, SPECIAL}; class Message { int nFrom; int nTo; virtual int GetType() { return BASE; } }; class Special : public Message { int nExtraInfo; int GetType() { return SPECIAL; } }; Then you can just pass it around as usual thanks to our friend polymorphism and query its type with ease to cast it appropriately.
  2. That doesn't sound right to me. Whether the file is read from a DLL or as a stand alone file, the speed at which it gets decoded is gonna be the same. If anything it'll be slower due to having the DLL overhead to parse. The only advantage to do so which I can think of is for reducing file clutter while simultaniously speeding up file copy speeds (its faster to read a huge block off the hdd than to seek around for several small files). I would not recommend that, instead use a pack file method as you can get greater flexibility for storing hundreds of files.
  3. Eps

    ODE and terrain

    Here is their description of the Quad Tree in the ODE doc. Quadtree space. This uses a pre-allocated hierarchical grid-based AABB tree to quickly cull collision checks. It’s exceptionally quick for large amounts of objects in landscape-shaped worlds. The amount of memory used is 4ˆ.depth * 32 bytes. Currently dSpaceGetGeom() is not implemented for the quadtree space. It sounds very similar to what I already have setup. The landscape is setup into clumps (for example, 16 by 16, each clump is 32 by 32 quads) which have AABB setup already. I could create a space for the entire terrain, have box colliders for each clump, and then have inside those a tri-mesh? If i create a tri-mesh for each clump it autogenerates an AABB, so I'd have duplicate information. Ill have to find a way to eliminate that on one of the ends.
  4. For any of you here that have used ODE (or perhaps any other physics engine), what are your thoughts on terrain collision? As of right now, my terrain is setup in a quad-tree and each "clump" has a listing of verts/indices/normals. ODE has a collision type tri-mesh. I was considering using a tri-mesh for each clump. I've heard that the tri-mesh type isn't fully developed within ODE yet and can be slow. Any one ever tried this or have a suggestion on how to do it differently?
  5. What you are curious about is called string delimination. It is really a rather simple algorithm. Start at the beginning, and go through the array of characters until the character you wish to deliminate by is found. Allocate the memory for 0 to N and then strncpy into the new array for length N. Now record where N was and start the search again. Allocated and strncpy for the new position - N. Of course, you are going to want to trim the left and right sides of the string of any deliminating characters before you start. Edit: And in Java it is called tokenizing.
  6. You can also use int mkdir(const char*) found in direct.h
  7. Eps

    Memory Manager

    Depending on how big of a system you are writing, you may want to make free lists. Its like a memory manager, but you have a pool for each data type. That way you don't have to do any shifting of memory to keep things from getting too fragmented, there is only one size you can allocate in that pool. This is probably the fastest implementation of a memory manager.
  8. Eps

    Is this a good way to learn?

    It depends on the example. Up until about a month ago all the examples on gametutorials used to be for free so I used them every once in a while. It really depends on the example as some of them were alright and others you could definitely find what you needed and more for free out there.
  9. I thought I'd bring this thread back from the dead just to make one point. We were debating the usefulness of creating a table of headers and then all the buffers at the end of the file versus having a file header then its buffer immediately following. Everyone agreed that having a table of the contents at the start of the file was faster for finding things within the file. Well, it turns out they may be identical in speed. I was benchmarking how long it would take to generate a directory listing using my method of file storage. It seems that when seeking through a file, it is essentially an instantaneous process. I could open any file, seek 500mb and profile this. Everytime it would return that 0 milliseconds had passed. I thought I was doing something wrong at first until I realized that Windows can do a very fast addition and jump right to that spot on the harddrive. So the result is that a TOC and my method are the same in speed. In both you must read several headers to get to the one you are searching for. This will be the same number of read operations if the tree is built the same way. The difference comes in when in the TOC method you read-read-read-seek. Mine you read-seek-read-seek.
  10. How can I test if a path leads to a directory or a file without an extension?
  11. A function pointer is really only useful for 2 things. Call back functions and arrays of functions. You havn't really what the purpose of this is and in what fashion you want to be able to use it, but it seems that what Stormrunner said is what you want.
  12. Quote:Original post by flukus Would yours be as efficient for navigating throu multiple directories? (not that mine can anyhow)? It seems like you would have to parse through a large amount of data to get to a file thats a few folders down the tree. I'm actually getting very interested in this project now, I never thought I'd find myself doing filesystem design, no matter how elementary! True, laying it out in "header-header-buffer-buffer" results in finding files faster. However, I'm doing a few things to speed mine up. For instance keeping the pack file open at all times, with the file pointer at the start of the current directory. Subsequent calls to my change directory, list directory, and extract file are then initiated at the appropriate file position. My goal is to save myself the headaches that come with maintainance of the "header-header-buffer-buffer" format (which I've dealt with on a few projects) sacrificing the speed. In reality though I cannot fathom it would have that large of an impact for anyone to complain. Quote:Original post by flukus I didn't even think of that so it's purely coincidental. Is there a precompiler directive that turns this off? I'm pretty sure there is. Just about all my work has been done with VS however, where the option is turned off in a menu, so I couldn't tell you what it is. As for my problem of the icons moving around, I finally got my system up and running a few minutes ago and it turns out it isn't a problem at all. I created a new file, copied all the contents of the pack file over as well as a newly compressed file, then deleted the original and renamed the new file. The icon for the pack file never moved. Windows is doing something that fixes it apparantly. I did notice that when I was in debug mode and stepped through the function a line at a time it _did_ move, and thought maybe the time elapse would cause that and would experience the problem when compressing large files, but I've tested that and restested when compressing 500mb files and the icon doesn't move.
  13. Eps

    Copy Protection

    Star-Force ( seems to be one of the better copy protection schemes around, though it is rather controversial. It is a software solution rather than a hardware one that installs a driver onto the user's computer which has some way of preventing a copy.
  14. Quote:Wouldn't that require an insert operation for whatever filesystem the OS uses? I vaguely remember hearing about something like that being available in reiser4! Couldn't find this feature for reiser in just a couple min of searching, but I'm on a windows box anyhow. Any idea if there is a similar feature available (whatever it does?)
  15. Well, it should certainly work, but you may have over complicated things a bit. I'd have to mull over the details of you design to discover any pros/cons, so instead I'll show you what I came up with and you can compare it for yourself. // Pack Entry struct PackEntry_T { PackEntry_T() { memset(this, 0, sizeof(PackEntry_T)); } short type; // Type of entry: Folder(0) or File(1). unsigned char string[54]; // Name of the entry, 52 chars, padded with '\0'. long size; // Uncompressed size of the entry in PACK file if a file, or number of entries if a folder. long csize; // Compressed size of the file. }; Thats it. Using this structure I can have any number of levels of directories and any number of files. If I set an entry to type folder and write it out, it will tell me that the next 'x' number of entries read belong to that folder. That could include another folder inside of which could be more folders. If I want to insert a file into a folder, I read through the file until the correct folder is found, increment its file count, then immediately write in the new file. The first thing in my file is always a root folder, under which i can keep track of everything that is going on. This is a permenant folder that cannot be removed. You may notice I'm not keeping track of file offsets within the pack. This is because I'm writing things out in the "header-buffer-header-buffer" fashion instead of "header-header-buffer-buffer". This lowers the maintanence I need to do when writing/removing. Your structs are 4 byte aligned which is good, if they weren't they would get padded by the default compiler options (in VS anyhow) and when trying to parse the file by the size of structs you'd run into problems. If anyone read all that, let me know if you see any issues with my design, as I think I have thought it out fairly well too :)
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!