RPG engine. 16x16 tiles, or 20x20?

[Ravyne]

Here is the issue people...I have a nearly complete RPG engine in the latter stages of development. I'm talking mere months from completion. Now, I planned this to be used by not only my games, but others in the programming/RPG making community. as I look through the vast majority of RPG-making sites there are tilesets abounds in 16x16 format. However, up till now, I've been using 20x20. Personally I like the level of detail those 4 little pixels allow, but some peope out there are not artists. So, should I stick to 20x20 or jump on the 16x16 bandwagon? I'm not concerned about the tiling code, but the NPC/Object code may be a pain to re-write.

If you feel like checking it out:

http://www.nyninteractive.cjb.net

[LooseCaboose]

Be really clever and allow the user to choose any tile size from say 8*8 to 64*64 and allow different x and y heights.  

[BlueKeyboard]

I think that 8*8 would be a little to small, 64*64 would be far too big.
I've always used 20*20 tiles because they fit perfectly on the screen, excatly 16 tiles*10 tiles.
Although 16*16 tiles would be good too, but I would have used 20*20 tiles .

[wildcard]

I think 16 by 16 is common because theres optimsations(sp?) you can make for drawing on the screen. A good thing to do would be to be able to set the height and width, and just use those in your code and it should work fine and allow flexiability.

[na_th_an]

Powers of 2 are always a good choice 'cause you can optimize your code if you program in a low level language like C or ASM to make your core GFX routines. You can use shifts and simple additions instead of time expensive divisions and multiplications when making graphic calculations. That's the reason why I always use 16x16 tiles/sprites. It's a good size, and if you want bigger graphics you can combine them without any problem. They won't fit exactly in our mode 13h screen but they will look nice and make your work easier.

[wizardlife]

16 is the most popular in the community in general because you can bitshift 4 to multipy or divide by 16. But you can't use those optimizations in QB anyways, so I'd leave it the way it is.

Better to pick one than to try to support 2, since it will eliminate a lot of superfluous IF statements that could clog up and bottleneck your code.