Pages: [1]
  Print  
Author Topic: Variable sized tiles  (Read 2032 times)
linux_junkie
Master
****
Posts: 222


View Profile
« on: November 08, 2010, 03:19:59 AM »

I'm working on a graphical roguelike, only using libtcod for utilities, like FoV and pathfinding.  My problem is, I have variable sized tiles, and I don't know where to even begin with implementing them.

Currently, I'm just using a vector containing all the tiles in the level, with their positions, and draw the ones that are in view.  The problem with this is the speed.  Scanning every tile is slow, and I have yet to find a better solution.

I feel like their must be some superior method, and it's probably an obvious one, but I'm clearly missing it.  What can I do to solve this problem?  I can't just resize the tiles, because they come from another tileset, and resizing them to fit the same area would cause graphical glitches and artifacts.  There *must* be a solution to this problem, and someone must have encountered this before.
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #1 on: November 08, 2010, 04:31:21 PM »

Hm, I don't get it -- if the tiles can have arbitrary sizes, how will you fit them together?
Logged
linux_junkie
Master
****
Posts: 222


View Profile
« Reply #2 on: November 08, 2010, 06:04:21 PM »

Hm, I don't get it -- if the tiles can have arbitrary sizes, how will you fit them together?

That's the problem, but it must be workable, because Reiner used these tilesets in his own games, and somehow pulled it off.  Likewise, 3D games feature objects and terrain of totally arbitrary sizes, and get it to work.  I'm actually considering looking into how 3D games handle it (Binary Search Trees, maybe?), and go from there.  I'm just concerned about speed, as well as having to make a much more complex map editor/generator.
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #3 on: November 08, 2010, 06:39:41 PM »

Look, if the tiles are square, and their sizes are not all multiples of a common size, there's no way to make it work without creating visible seams! However, if you have free-form objects/patches of terrain with a transparent background and which are independent, it'll work (they don't need to fit together; for example, a patch of grass that smoothly blends to a transparent border so it can be placed anywhere; same way for a patch of dirt; a tree; a house...).

See the screenshots and video of this tutorial for an idea:
http://gametuto.com/in-game-c-map-editor-tutorial-with-indielib-engine-that-dosent-use-tiles-but-pieced-images-like-in-braid-or-aquaria-games/
Logged
linux_junkie
Master
****
Posts: 222


View Profile
« Reply #4 on: November 08, 2010, 06:59:42 PM »

Look, if the tiles are square, and their sizes are not all multiples of a common size, there's no way to make it work without creating visible seams! However, if you have free-form objects/patches of terrain with a transparent background and which are independent, it'll work (they don't need to fit together; for example, a patch of grass that smoothly blends to a transparent border so it can be placed anywhere; same way for a patch of dirt; a tree; a house...).

See the screenshots and video of this tutorial for an idea:
http://gametuto.com/in-game-c-map-editor-tutorial-with-indielib-engine-that-dosent-use-tiles-but-pieced-images-like-in-braid-or-aquaria-games/

Thanks for the link, very helpful.  My own google searches failed to turn up anything useful, but this is an excellent piece of info.

As for the floor tiles, they're uniform in size, although rectangular, not square.  It's the wall pieces that are of a different size, so I'll need pixel perfect alignment to get them looking right.  Thank heavens for your link, it'll be a huge help, since they accomplish exactly what I need to do.  Time to source dive!
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #5 on: November 08, 2010, 09:31:07 PM »

Yeah it's an alien concept to us, we're used to tiled games! It must be hard to make it work with random level generation though -- the best effects are done by a human designer. But anyway it may give you some ideas on positioning those tiles automatically. Also, the concept of freely positioned alpha-blended objects is very cool; you can scatter chains and other junk on the floor and walls of your dungeon Smiley
Logged
linux_junkie
Master
****
Posts: 222


View Profile
« Reply #6 on: November 08, 2010, 09:56:06 PM »

Yeah it's an alien concept to us, we're used to tiled games! It must be hard to make it work with random level generation though -- the best effects are done by a human designer. But anyway it may give you some ideas on positioning those tiles automatically. Also, the concept of freely positioned alpha-blended objects is very cool; you can scatter chains and other junk on the floor and walls of your dungeon Smiley

Yeah, definitely not something I'm used to.  I do like the idea of having scattered debris on the ground.  Diablo is a huge inspiration, with all of their dismembered corpses and spikes and stuff.
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #7 on: November 09, 2010, 04:13:17 AM »

Yes, though I think they used isometric tiles anyway for the rest of the terrain. The idea they give there is that, as long as you got alpha-blending, you don't have to worry about pixel-perfect positioning Cheesy
Logged
linux_junkie
Master
****
Posts: 222


View Profile
« Reply #8 on: November 09, 2010, 08:05:36 PM »

Wow, this problem keeps getting more complex all the time, it seems.  As someone who's exclusively designed grid-based games, doing something like this is a mind melting experience.  Now I have to worry about handling collision detection, which is so easy in a gridded game, but extremely complex for a game like this.  I'm probably going to have to pull out crazy data structures like quadtrees and such, which I'd never imagine needing for a normal gridded roguelike game.

This is *definitely* a huge learning experience.  I think my skills will likely double by the time I finish this Smiley

Edit: I think I found an optimal solution to the tile problem.  The quadtrees I'm going to use for collision detection will also help sort the rendering function out, and should be fast.  Now I just have to figure out how to implement a damned quadtree, which I've never done before.
« Last Edit: November 09, 2010, 08:19:26 PM by linux_junkie » Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #9 on: November 09, 2010, 09:05:33 PM »

Actually there's a very simple solution! The greatest advantage of a grid is that it defines the locations of walls, and detecting collisions is trivial -- you don't wanna throw that away. But ground tiles don't have to be aligned to this grid! So, use a grid that has the size of the wall tiles to define what's floor and what's walls. For rendering, first draw the ground tiles evenly spaced around the whole screen (not necessarily aligned to the tiles grid), then on top draw the walls according to the grid. Smiley
Logged
linux_junkie
Master
****
Posts: 222


View Profile
« Reply #10 on: November 10, 2010, 07:32:39 PM »

Actually there's a very simple solution! The greatest advantage of a grid is that it defines the locations of walls, and detecting collisions is trivial -- you don't wanna throw that away. But ground tiles don't have to be aligned to this grid! So, use a grid that has the size of the wall tiles to define what's floor and what's walls. For rendering, first draw the ground tiles evenly spaced around the whole screen (not necessarily aligned to the tiles grid), then on top draw the walls according to the grid. Smiley

Perfect.  Using pixel offsets in the grid will enable this to work.  Thank you very much.  This was actually the same solution that was arrived at on the roguetemple forums as well, almost simultaneously Wink

Collision detection for creatures will still be tough, and will require a quadtree, since creature movement is pixel-based, not tile-based.  But now that I can handle wall collisions easier, it won't be so bad.  I just have to figure out how to implement the damn tree, having never used one before (never really needed it for an ASCII roguelike).

Thanks again for your help.  I can now finally get back on track with development (between all my other work, which is sucking my time away fast).  Well, back to work!
Logged
Jotaf
Global Moderator
Master
*****
Posts: 1183


View Profile
« Reply #11 on: November 11, 2010, 01:59:27 AM »

Yeah I've been swamped too; I long for the days when (if?) I'll get home at a decent hour, worry-free and without "home-work", and just code away my AwesomeRL (that's how it was called for a while) Grin

Concerning quadtrees, I'm not sure they'll help much, since monsters move around -- all the code I've seen concerns static quadtrees, dunno about updates. If your dungeon algorithm can mark different rooms and corridors, your space is already partitioned into physically meaningful chunks (rectangles?) -- so you only need to collide with objects that are in the same chunk as you, or a chunk directly connected to it. Anyway you could also just use a flat list of objects and loop through it every turn, like I do! Cheesy
Logged
Pages: [1]
  Print  
 
Jump to: