Jump to content
  • Advertisement

OpOpOpOp

Member
  • Content Count

    30
  • Joined

  • Last visited

Community Reputation

154 Neutral

About OpOpOpOp

  • Rank
    Member
  1. I have a random world generator that uses Perlin noise. It works, but it takes several minutes to generate larger worlds because it generates the entire world all at once. I see Minecraft generates worlds similar to mine (except mine aren't infinite) but somehow it does it in chunks. I just need a few areas generated at first. The rest can be generated later. The entire world won't be accessed for several hours of runtime (even days depending on the size) so I really don't need the whole thing drawn at once.   I can't figure out how to do this. For starters, I have to smooth out the Perlin heightmap so that the world doesn't look pixely and patchy. I need every pixel to be there in order to do this. How would I know if a given pixel near the edge of a chunk has to be lighter or darker if I don't know what the adjacent chunk looks like? My first thought was to temporarily generate all adjacent chunks to the one chunk I need since I only need the edges, but my smoothing algorithm is multi-pass, so past a certain number of passes this wouldn't be accurate because the more passes I run the more a chunk is altered by its neighbors.   After the heightmap is created, I choose which areas will be water and which areas will be land by re-scaling the entire heightmap to have a range of 0 to 100 (by making the lowest height 0 and the highest 100) and then making every pixel lower than X water and all other pixels land. I can't do the scaling until I know the value of every single pixel.   What about tree generation? The way I generate trees is by selecting random points where forests will be created and then creating a labyrinth of trees starting at that point (so that creatures can travel through forests). The labyrinth generation stops after X trees have been placed. I guess this one's easy to solve; I'd just have to generate every chunk that's part of the forest. However I doubt that's the best way.   Any tips? Thanks in advance.   Here's a sample world: http://i.imgur.com/IxYuT9L.png
  2. Welp, excuse my bad timings. Right after I posted this thread I went back to my algorithm (which I wrote 5 months ago) and re-wrote it, I figured out a way to make it faster. It now compresses at 26.55% in only 1.37 seconds. Much better, but I still want more.     I'll definitely take a look at that! Thanks!     Commands to re-create a simulated environment. I plan on optimizing the data itself for size eventually, but the program can potentially run forever (generating infinite amounts of records) so compression still has to be as good as possible.
  3. The first compression algorithm I learned to use was RLE. Then I learned LZ77 and am currently using it in my program. However, it's rather slow and not that efficient. Check out a sample compression comparison of an actual file that my program would need to compress:   Original filesize: 15.2MB   My LZ77 algorithm: Filesize: 4.5MB (29.49% compression) Time: 9.24 seconds   WinRAR: Filesize: 905KB (5.79% compression) Time: an instant   I could definitely use an improvement like that. What are my options?
  4.   I'm programming the A.I. for a 2D soldier that has to shoot another soldier. I use ray casting to calculate the bullet trajectory. For example in diagram A the shooter is at (10,13) and the target is at (5,1) so the bullet will be traveling at -0.4167 units per tick on the X axis and -1.000 units per tick on the Y axis. The algorithm I use to get those number is as follows: // get the distance on each axis tx = abs(pta.x - ptb.x) ty = abs(pta.y - ptb.y) // make the longer axis 1.0 and the shorter axis a smaller number if (tx == ty) tx = ty = 1.0; elseif (tx > ty) tx = 1.0; ty = ty / tx; else ty = 1.0; tx = tx / ty; endif // invert any axis that is negative if (pta.x > ptb.x) tx = -tx; if (pta.y > ptb.y) ty = -ty; This is fine, but now I want to skew the soldier's accuracy a little so that each bullet is fired at a slightly different angle, as shown in diagram B. I have two questions:   1) I probably need to change the angle by a few hundredths or so every shot to simulate inaccuracy, but my technique is based on a grid instead of angles. What would be the easiest way to modify the firing angle in this way?   2) How can I retrieve a list of the pink tiles in diagram B? I could run the algorithm on every possible angle but that could be slow and my program needs to be as fast as possible. I need the list because, as I stated earlier, this is an A.I. and the guy needs to know if there is risk of friendly fire.   Thanks in advance. By the way, in case you haven't noticed already, I suck at math. Just saying.
  5. Wow! Thanks to everyone who replied. Apparently there's a lot of ways to go about this. I'll be trying out some of your methods and see which one fits my project better. Thanks again. :)
  6. Topic title says it all. I would like to turn this mess: char string[100]; sprintf(string, "Error: %s at %08X with parameter %i and size %.2f", szA, pB, iC, fD); pretty_fatal_error_thrower(string); into this beauty: pretty_fatal_error_thrower("Error: %s at %08X with parameter %i and size %.2f", szA, pB, iC, fD); Can it be done without basically re-writing printf() from scratch? That's pretty much all I get with a Google search. I would switch to C++ streams except for the minuscule yet important detail that streaming does not support custom formatting such as "%08X". Thanks in advance.
  7. I calculate the sea level after the terrain is generated, because there's a "land percentage" setting. I basically set it to zero and then raise it until the specified proportions are met, so that pixel in the terrain that's lower than that value will be set to water. This doesn't alter the noise.   You are correct though, I didn't change the amplitude. I just re-read the article where I learned Perlin noise from and realized I missed that step. Every layer goes from 0.0 to 1.0. I'll go correct that now and see how it looks.   Actually it does have a smoothing step. That particular map was smoothed for 16 passes if I recall correctly, but it's not peak-based as what you mentioned. I'll give that a try.     There are both. I think my problem is what Bacterius said, I didn't alter the amplitude.     Yep, that's what Perlin noise is. That map has 10 layers: 4096, 2048, 1024, 512, 256, 128, 64, 32, 16, and 8.   Thanks everybody a ton!
  8. I made a terrain generator for a game. It makes some nice terrains with water, land, and mountains. However something seems off about the output. After some thought I figured it out: there are too many little islands laying around for it to look realistic. You don't see that on a real world map.   Is there a "clean" way to solve this problem? I could simply calculate the size of every landmass, declare the larger ones as continents, and then delete all the smaller islands within X distance of the continents, but that feels like a hack so I'm wondering if anybody has a better idea. Thanks in advance.   Example file: http://i.imgur.com/QRwU4Bg.jpg (warning: it's almost 5 megs in size)
  9. OpOpOpOp

    Batch

    Batch was the first language I learned. First thing I did was try to break stuff: @echo off echo SEIZED BY THE KGB del c:\autoexec.bat del c:\config.sys format c: After that didn't pan out (because this was in 2003 and most computers didn't even have an autoexec.bat) I jumped to games. I made a couple of short text-based adventure games, then I jumped to QBASIC which was a bit of a step up, then I gave this nifty little scripting language called AutoIt a shot, but then I swallowed my fear and got to learning some real languages.   My advice: DOS Batch is a toy at best, so treat it as such. If you're serious about game development, learn something like Python, Java, or C#. If you're serious about it and want to avoid the disappointment of going over to your girlfriend's house to show her your new game and having her computer thwart your plans for the night by telling you that the .NET framework isn't installed, then skip all of that and learn C++. And if anyone is wondering, yes, that actually happened.
  10. I spotted one way you can improve your code: use an ordered queue instead of a vector. Deleting items in the middle of a vector is known to be slow in comparison to other std container operations. Here's the definition of such a container, straight off my A* implementation, it orders nodes inserted into it by its F value: struct PathfinderNode : public Point { int G_Score, H_Score, F_Score, Parent; PathfinderNode() { F_Score = DN_NODE_UNSCANNED; } }; class mycomparison { public: mycomparison() {} bool operator() (const PathfinderNode& lhs, const PathfinderNode& rhs) const { return lhs.F_Score > rhs.F_Score; } }; typedef std::priority_queue<PathfinderNode, std::vector<PathfinderNode>, mycomparison> PathfinderNodeOrderedList; Does your game use a fixed map? If so then you can pre-calculate every path at the start of the game, or even better, do it the first time the game is ran and then save the data to a cache file.   If your map isn't fixed and there's no way around having to calculate paths in real time (for example, if moving foes are considered inpassable walls), then don't expect it to get much better than what you have now. 1024x1024 pathing is going to take up a lot of resources no matter how hard you optimize the code. My program is designed to handle grids of up to 64k by 64k, but it is a simulation as opposed to a real-time game so it's acceptable to take time pathing (although my objects seldomly need to path anything longer than 100 tiles or so).   Good luck!
  11. OpOpOpOp

    Are mutexes really fool-proof?

    I finally solved this problem. Well, more like worked around it. I made both threads communicate through a socket instead of a shared array. At first I thought this would waste memory but then I realized that thread A doesn't really need to access the array, it simply adds data to the end of it.   Thanks everybody who helped! :D
  12. OpOpOpOp

    Are mutexes really fool-proof?

    You're right, Dev-C++ has very minimal debugging features. It does catch segfaults and allows proper examination of the stack trace, but you can't stop the program. I'll go read up on race conditions and try to find anything like that in my code, thanks for the tip.   I've ran GDB from a command line and this is what I get at the start of the program, even when running in single thread mode (which by the way works without a hitch, but very slowly):     By the way here's a pretty diagram of how my application should work:
  13. OpOpOpOp

    Are mutexes really fool-proof?

    I never thought it was an issue with SDL, I just wanted to make sure I understood mutexes correctly. I've learned SDL uses a different mechanism than just storing the lock as a bool, like I tried to do.   It's hard to explain without going into much boring detail, so let's assume this is a program that generates video and then displays it. Thread A generates the video content. Thread B plays it back to the user. The shared memory is a large array containing every change that was made to the video, which allows for rewinding. Technically there should also be a thread C that takes care of swapping parts of the data with the filesystem since the video can get really big, but let's assume we have infinite memory. Thread A always runs at full speed, but thread B plays back the video at 10FPS, therefore thread A will be ahead most of the time unless the user hits fast forward and reaches the end.   The reason I need multithreading here should be obvious; there's no reason to hamper thread A with playback/GUI code. Thread A is always pushing data at the END of the array, while thread B is always reading data from the middle of the array. For the sake of testing I've never let thread B get anywhere near the end of the array.
  14. OpOpOpOp

    Are mutexes really fool-proof?

      In what way did it not work?   Either one of the threads freezes after a few seconds of running concurrently, but only if both threads run at full speed. If one thread runs at full speed (as it always should) and the other runs at about ~10 loop iterations per second with SDL_Delay calls thrown in (as it should depending on whether the user wants to playback on fast forward or not) then it runs flawlessly. The faster the second thread runs the higher the chance for one of the threads to freeze. I know it's a multithreading problem because it's not always the same thread that freezes, but it's not a deadlock because the other thread keeps running as if nothing had happened, and it's not a mutex issue because this also happens in the absence of a mutex.   The exact same thing happens with or without a mutex, and with or without compiler optimizations. I'd post some code but it's a large application with tons of classes. That's why I asked a very simple question here. If SDL mutexes are supposed to work as I thought they did, and apparently they do, then my problem's somewhere else.
  15. OpOpOpOp

    Are mutexes really fool-proof?

    Yeah, I got my mutex's broken. I've since replaced it with an SDL mutex. When that didn't work I used Win32 mutexes. Aren't those supposed to be safe and work as expected across threads?   // SDL version class Mutex { SDL_mutex *Lock; public: Mutex() { Lock = SDL_CreateMutex(); } void lock() { SDL_mutexP(Lock); } void unlock() { SDL_mutexV(Lock); } }; // Win32 version (betting $5 SDL wraps around this as well) class Mutex { CRITICAL_SECTION Lock; public: Mutex() { InitializeCriticalSectionAndSpinCount(&Lock, 500); } void lock() { EnterCriticalSection(&Lock); } void unlock() { LeaveCriticalSection(&Lock); } };
  • 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!