Omnimaga
General Discussion => Art => Topic started by: TIfanx1999 on January 06, 2009, 11:49:03 pm
-
Just out of curiosity sake, which size do you prefer? Take into consideration that this would likely be used in a non-action type game. I like 16x16 as the sprites are more detailed, but I hate that you see so little of the screen. 8x8 gives you a nice area in which to move around and lets you see plenty of the screen, but the sprite detail is LOW. 12x12 is in between, but seems kinda meh to me. Anyhow, I was wondering what other peoples thought on this were.
-
i prefer 8x8 when you want a lot of stuff in the same screen and precision, but I like 16x16 too because it's easy to make sprites/tiles based on some games. As for 12x12 the problem is that then you can't work with xLIB tilemapper
-
for simpler games, i would go for 16x16 so it would look nice.
-
I use 8x8. But 16x16 is sometimes just as good an option.
-
I like 8x8. 16x16 looks nice but is too bulky (you only get 4x6 instead of 8x12 on the screen). As for 12x12, the tilemap would be 5x8 which is a fair intermediary, but you would be wasting 4 rows of pixels (although you could use them for something like a border). Plus t's not a simple task to write a routine to display Rx12 sprites (I think).
-
I go for 8x8, not too much detail..I have no pixel art skills, so I stay away from 16x16 XD
-
for 12x12 you must put your sprites/tiles in 16x12 slots and to display a map you do it tile by tile (can be slow)
-
Well for me I always finding it more beneficial to use a multiple of 8. You can get some decent stuff with 8x8 but like you said the quality is low. Again stated alread 16x16 is more detailed but you wont be able to have a whole lot viewable on the screen but imho is your best option for quality and ease. So I guess it depends on what type of a tilemap you are creating.
-
Actually, 12x12 would be arguably only as slow as 16x16; you're still shifting 2 bytes around to draw the tiles. The only difference is that you're ignoring the righthand 4 bits, a process that takes one AND command (1.3 microseconds)
-
Actually, 12x12 would be arguably only as slow as 16x16; you're still shifting 2 bytes around to draw the tiles. The only difference is that you're ignoring the righthand 4 bits, a process that takes one AND command (1.3 microseconds)
But 12x12 sprites means more sprites to handle in the screen. It will be definitely slower than 16x16.
-
Still depends on the sort of game tho..
-
I have been thinking in exploring 10x10 sprites. Or, who knows, 8x10 or eventually 10x8.
Depending on what I do the remaining pixels could be filled with some border.
Is there any works of 10x10 sprites?
Have you seen the 12x12 with 16x16 sprites combination of upcoming Sonic game in UTI forums? Those graphics are awesome. They are worth some minutes looking at them.
I am doing some sprites work. ;) I have some projects holding until I discover the sprites and I am stocking what I can find, rip and do.
I will eventually share the collection.
-
Actually, 12x12 would be arguably only as slow as 16x16; you're still shifting 2 bytes around to draw the tiles. The only difference is that you're ignoring the righthand 4 bits, a process that takes one AND command (1.3 microseconds)
Keep in mind that here we talked about BASIC + ASM libs, though. There are no ASM libs for BASIC that does 12x12 tilemaps. The only way to do this is to draw the map sprite by sprite, which is much slower.
-
You can try your hand at writing your own lib... ;)
-
Yeah, except personally I did try ASM several times and learned for a while back then and I just wouldn't get anything past Day 2 (except the definitions of XOR/OR/AND/Overwrite)
-
Yeah, except personally I did try ASM several times and learned for a while back then and I just wouldn't get anything past Day 2 (except the definitions of XOR/OR/AND/Overwrite)
Sigma, although definitely thorough, definitely puts in more information than you need, overcomplicating things. It'll be alot easier learning from multiple tutorials and piecing the ideas together from multiple sources.
-
Well, the thing is that his tutorial is not made for visual people, same for many others. The examples of programs provided in it are totally pointless and do nothing useful. It would maybe be better to include some that does something
-
I know what you mean. I also tried to learn asm a while back, but decided i liked coding on calc due to portability (and no, slow basic assemblers don't count :P) but the 28 day tutorial was really confusing in the beginning x.x. I think i managed to get a piece of text that you could move around the screen, but it had all the speed of basic and crashed horribly when you went outside the borders :) oh well.
-
lol, I can never get past day15.
-
You are making me to try to do a more comprehensive guide. :-\
Although I have a tendency to complicate and write some strange phrases...
There is few things (instructions and such) to learn in assembly. How to do stuff can be learnt from experience on solving them and learning from others.
The difficult part is implement things without doing some mistake. And discovering what was the mistake can be hard... >_<"
-
I went upto day 2 and stopped.... lol also same thing with C++ I went to day 7? and stopped also. I don't have too much time on computer now that I am so busy doing college applications and such, and I code during math/science and in bus
-
On-calc programming is one thing I love a lot from TI-BASIC
-
On-calc programming is one thing I love a lot from TI-BASIC
Someday PH1 will be done :D
-
BBC Basic also have on calc programming, but the editor is apparently a pain to use. Apparently it's almost as annoying as trying to edit a BASIC program by using Celtic III commands from the home screen one by one
-
... And I can't use the bbc basic pc editor for lack of Windows... (Wine doesn't support .NET executables natively)
-
Yes I tried BBC code, but first of all it really was annoying coding that thing, and second the manual was too confusing, especially the graphic part.
-
... And I can't use the bbc basic pc editor for lack of Windows... (Wine doesn't support .NET executables natively)
Plus the Windows version is not free :(
-
Didn't Ben post one on his site?
-
Mhmm, if he did, then I didn't know. Did he made one himself or just cracked it? If he did the later, then I guess we can't post it here :( (against 1and1 rules to post links to illegal content)
-
I think it was his own. (I remember trying (and failing) to run it, but I'm not sure whether that was the compiler or the packager, whatever...)
EDIT: It is. I checked. (at least it's not Microsoft's)
-
Yeah, he released a 'TI BBc Basic editor' in the package of BBC Basic when you download. It is unfortunate that the editing scheme is so unfriendly though, as it tuns many people away. I've worked with it some and it really is quite powerfull. (although i haven't done any sprite graphics yet D:)
-
Hay! my topic got revived from the grave after I left! XD
-
I just voted. I chose other. :D This is because I like looking at all the cool graphics people make in basic. As for with xLib, I'd choose 8*8.
-
For some games, 7x7 actually turns out alright if you get everything working, although it takes a little more work.
-
Yeah, most of my sprites in Chip's Challenge were 7x7 since having an odd number of pixels somehow makes it look a little better (especially symmetrical sprites). The 8th column/row were taken up by the grid anyway :)
-
I usually perfer 8x8 for tilemaps. They're easier to draw and fit more in one pic data.
I only use 16x16 for special occatoin like battle.