I was originally thinking 32x32 or 24x24 for characters I think we should use 16x16 tiles, even though that means we won't have much to show on the screen at any given point. I made some rather nice tiles for an old game that were 16x16 that I might be able to share. I might also have to get around to writing a scrolling map engine >.>

I like the detail in 16x16 sprites, especially grayscale. It also makes the world seem so much bigger and you feel closer to the game

Sounds good to me. I agree to this.

Cool, thanks. What format are the files saved in, by the way? I am assuming bytes doing rows first, then columns?

Yes, the format is <x, y, [data], [data], [data]... etc>

Edit: I'll need to check if I still save the data in chars, however instead of ints. Or should we use ints?

They are. I believe that they are words, I can modify the source though to only work in bytes (I *should* already have it implemented since I was planning on exporting AppVars with this program eventually)

If we have over 256 sprites, we can always have sprite pallets for different areas.

I was originally thinking 32x32 or 24x24 for characters I think we should use 16x16 tiles, even though that means we won't have much to show on the screen at any given point. I made some rather nice tiles for an old game that were 16x16 that I might be able to share. I might also have to get around to writing a scrolling map engine >.>

I like the detail in 16x16 sprites, especially grayscale. It also makes the world seem so much bigger and you feel closer to the game

16x16 might allow for better detail than 8x8

I might have to pull back from this project a bit, life and A:P are keeping me quite busy as it is . I'll still be happy to act as a consultant, hehe, chipping in here and there though.

Anyway what I have to say here is that if you guys are going to go grayscale ARPG, you're going to have to sacrifice the 6mhz audience. Redrawing the screen isn't going to be an option, as that takes over 400,000 cycles by itself if you're drawing 2 layers for gray. So the screen is going to be needed to be backed up every frame to draw the enemies and whatnot; simply backing up 1,536 bytes of buffer, drawing the screen (3lvl gray) and restoring those 1,536 bytes is going to take over 123,512 cycles. In 6mhz, that's 48fps. Once you add in scrolling, enemies, and whatnot, the framerate isn't going to be anywhere close to the 45-60fps needed for decent grayscale. (Reference numbers: Horizontal/Vertical commands take about 20k cycles, drwaing an 8x8 sprite takes 2100 cycles. So scrolling with 2 16x16 grayscale sprites onscreen? Add 4*2*2*2100+2*20,000 = ~another 50,000 cycles, dropping the 6mhz framerate down to 30fps). 15mhz is going to be just about right to get you by.

well, as it currently seems due to the votings in the battle engin topic that it'll be an arpg.
But we could also do two versions, only loading different sprites shouldn't be too much a problem.
IMO we should start a poll on the sprite size and greyscale.

maybe some people like xeda can assemble us there something....