Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

102 Neutral

About samp20

  • Rank
  1. Hi, I'm currently working on a regions (cuboid) plugin for Bukkit (minecraft server API). What I'd like to know is what the best Spatial indexing algorithm would be. There's two main options that I can think of: R-Tree. This is probably the most complicated to implement. I would probably use Linear splitting when nodes get too full, however I'm struggling to understand how the algorithm works. If anyone could provide some pseudocode that would be great.Spatial Hashing. This seems like a more viable option. Minecraft is divided into 16x16x128 chunks, and so I can use a HashMultimap to store which regions are within which chunk. This seems fine for small regions, however would probably start to use a lot of memory when regions span multiple chunks. Maybe there's an option to use both of these methods. Most likely there will be very few large regions, however many small ones. Heck I could probably get away with storing the large regions in an array, and iterate through them. Probably a better idea though would be to use something like this: http://khelekore.org/prtree/. Although it only works in 2 dimensions I feel that should be enough for the larger regions since it's unlikely for there to be many large regions stacked on top of eachother. Writing this post has already helped me to come to a decision, but if anybody can give me some better guidance I'd be very grateful. Thanks, Sam
  2. samp20

    tile based lighting

    each tile is 32x32px by the way, and I'm just targeting desktops etc atm I think I understand your ideas though. To start with I have a grid of lighting values, all set to 0 (darkness). I then loop through each light adding the appropriate values to the grid (maybe from another predefined image [could allow for many light types too]). When I come around to drawing the tiles I can then draw the tiles initially, then take the lighting values and use the multiply blend mode on the already drawn tiles. The actual map is in theory infinite, and is divided into chunks 32x32 tiles in size. That means that one light from one chunk could potentially influence another chunk. This does seem a minor problem to sort out however since I will only be loading 4 chunks at any one time, so could probably get away with having each light update 4 times instead of just once (and culling will be fairly easy too if necessary). Also the lights will only be updated when the player places/removes a source (or new chunks are loaded), so it's not like it's going to happen very often. Thanks for the ideas, I'm not sure where I was going with the spreading idea (apart from to implement shadows which tbh I'm not too bothered about now). once I get it working I'll post an update of my progress. Thanks again, Sam
  3. Currently I'm working on a 2d top down version of minecraft, although was wondering how feasible a lighting algorithm I'm proposing will be. The overall intention is to be able to add/remove light sources, allow that light to spread, and make solid tiles block the light. The general idea was for each tile to get their light value calculated from the surrounding tiles, e.g. use the maximum of the surrounding then subtract one unit. For solid tiles that may or may not be lit simply take their value as zero. The update process of this is what I'm worried about however. The idea is that whenever a tile's light value changes it will add the 4 surrounding tiles to an update list. So for example when a light is placed on one tile it will be updated and cause the 4 surrounding tiles to be put on the list for pending update. These 4 tiles then would be updated, and thus more put on the list. This would repeat until the tiles no longer change brightness value. does the above process sound costly, and if so is there any way I could improve it?
  4. The tiles I'll be drawing will stay a constant size (32x32px), so yea the number of tiles could vary. from what I gather a loop like the following would be the way to go: for(x=0;x<tiles_wide;x++){ for(y=0;y<tiles_high;y++){ //work out which tile to draw } } The part which may add complexity however is working out which tile to draw. With a 2x2 array of 4 chunks I would store the coordinate of the top left chunk. When doing the above loop logic tells me I should convert the viewport coordinates into chunk coordinates, then from those work out which chunk from the 2x2 array to use. To work out which tile from the chunk to draw I would then convert the viewport coordinates into tile coordinates and % (mod) with the chunk width. In my mind this sounds like a lot of work to be doing inside a loop and would require some optimisation to work efficiently (then again I may just be underestimating the power of computers nowadays). When you mention batches I think that is how I'm doing things currently. Each chunk of the map has an image buffer to store the rendered version of the entire chunk. It is however quite a large image (1024x1024). when a chunk is loaded the tiles will be drawn to this buffer, and only redrawn when the tile changes. The buffer itself is then drawn to the screen each frame. This does however add extra complexity if (and most likely) I choose to add animated tiles (sorry forgot to mention earlier). Also when I come around to adding entities I most likely will use a quadtree. It actually sounds like it will work quite nicely with the 2x2 array of chunks that I'm using, and will come in handy for collision detection between entities too. As mentioned earlier yea I was using a texture of multiple tiles. Where you mention using a smaller texture with each texel representing a tile, that's pretty much what I'm doing to store the tile data, however I'm using an array instead. The use of the large texture was to try and optimise the render loop, however in the long run I'm thinking I would be better off rendering tile by tile. Thanks for you're advice, you've certainly helped me come to some sort of decision, and hopefully it's the right one. If not speak up quickly before I get too carried away
  5. I'm currently working on a 2d top down version of the popular game minecraft. I've made reasonably good progress in java, however I'm considering switching to c++, and was wondering if there's a better way to render my tiles. Essentially the map will be infinite which means it needs to be divided into chunks. The issue for me however is working out the most efficient way to render these chunks. From my understanding the most popular way for normal 2d tile maps is simply loop through each tile that falls within the screen and render it. This however I fear will be too slow with working out what chunk to grab the tile from, I may be wrong however and this be a perfectly viable solution. The way I'm currently doing things (in java) is creating an individual buffer for each chunk then drawing the entire thing. The buffer is then only updated when a tile changes. The downside to this however is it uses a lot of memory, and potentially I run the risk of certain graphics cards not being able to handle the larger image sizes. It does however seem to run very fast. One final note is that I will eventually be adding dynamic lighting to the tiles, so the final solution would need to be able to handle it. Thanks in advance
  • 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!