Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => Topic started by: Yeong on December 06, 2012, 11:58:23 am
-
Maybe we can post sprites here. :D
-
Ooh, I'm up for helping with spriting, if I have time and a general idea of what I'm supposed to sprite.
-
Okay... I'm in on sprites, but first, we need concept art to turn into sprites...
-
I could try my hand at spriting (I can occasionally make something)
Though I can definitely help make maps. (Particularly larger ones that go beyond the length of the screen, using TileCat)
-
I would give spriting a try :)
-
We should get someone do do concept art, and then we convert that art to sprites...
-
Should we make the npc's look like the person they're based off of? :P
-
Should we make the npc's look like the person they're based off of? :P
We could ask members who wish to have cameos submit a drawing of what they wish to look like
-
Y'all also have to come up with what size and how many colors. 3 level grayscale, 16*16 ? (I personally think 3-level gray looks better on an actual calc than 4-level)
-
I wanna be in it!!!!!xD
(Only if i'm able to help you guys create the game...)
-
What size sprites are we talking about here? When I first thought about it, I thought 16x16 for the characters, but now it seems king of big in my mind(unless you can convince me I'm wrong :P). Now I'm thinking 8x8 should be fine. These are just my opinions though. :P
Edit: Also, I would like to be in it. :P That wold be cool. I help come up with more ideas about the storyline/idea if I need to contibute to be in it.
-
I can think of concepts for maps and whatnot.
But I can't draw sprites at all :P
-
I can't draw sprites as well, i'm terrible at that
But if needed (but i think there are already more then enough people) i could help design maps
Btw: shouldn't it be easyer if you guys could directly create map and scroll around in it? ;p
EDIT: how large would maps be?
-
I was originally thinking 32x32 or 24x24 for characters :P 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 :)
-
All that you say sounds cool :D
And scrolling map isn't hard, even i can do that xD
-
When we initially make maps, it might be easier to make them on comp so you can see everything going on at once and not be constrained by the calc screen itself. I'll be using my own Tilemapper for this purpose, since it generates map files in a simple format :P
Edit: I'll update my sig with my projects so people who want to use it, can find it
-
I was originally thinking 32x32 or 24x24 for characters :P 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?
-
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?
-
One byte would be better in my experience. We might have >256 sprites, but we probably won't need more than 256 tiles. That initial x,y will be very useful, too. Are those bytes or words? (I am assuming they are the width and height)
-
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.
-
Erm, how many by how many pixel sprites? I would say 8*8 :P
And I'd say 4-level greyscale :D
-
I was originally thinking 32x32 or 24x24 for characters :P 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 :P
-
but isn't that a bit big? 12x12 then?
-
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.
-
I really like the enthusiasm that this project is getting. However, the main focus at this point should be discussing sprite sizes and wether or not we should use grayscale. I don't see how concept art can be done yet as we don't even have a story nailed down, or a team developing the story/scenario yet. In regards to that; 16x16 does allow for less space per screen, but it doesn't allow for as large of a field of view. In rpgs, this is generally acceptable though. 12x12 seems it would be a decent compromise of scree space and quality. 8x8 or less allows a much larger field of view, but really limits the amount of details that can be shown. I think I'd be leaning more towards 16x16 if we are doing a turn based rpg. If it is an action RPG, 12x12 or 8x8. I'd also want to ensure that this game is playable on both 6mzh and 15mhz calcs, so grayscale may not be an option.
-
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.
-
I think 12x12 would be slower and require more complicated data and sprite drawing routines.
-
maybe some people like xeda can assemble us there something....
-
Also if the RPG decides to go to ARPG, the amount of sprite requires increase by 200% at least. (ARPG takes some good amount of sprites because of attacking motions and stuff and enemies sprites have to be semi-detailed motion wise)
-
Any votes for 11x11 sprites? That's what I used for Ultima V. 11x11 gave me the ability to have a full 9x9 grid of tiles on the screen.
I would like to see 12x12 over 16x16 or 8x8.
-
It is true that you had an 9x9 grid to play around on, but your project was on the 68k sereies. You had a larger screen to play with. We would need to do 8x8 to accomplish similar here (a 12x8 or 8x8 grid with a hud).
-
It is true that you had an 11x11 grid to play around on, but your project was on the 68k sereies. You had a larger screen to play with. We would need to do 8x8 to aaccomplish similar here (a 12x8 or 8x8 grid with a hud).
9x9 grid of 11x11 sprites.
12x12 makes better sense on the TI-83/84 calcs.
-
but the 84 screen is only 96 pixels across and 64 pixels high
-
@homer:I agree. Its much easier to map the entire world out on a pc so you can see the whole world at once.
@bluebear:12x12 isnt much different from 16x16 programming wise really.
@Ranman:A 9x9grid of 11x11 sprites is what i meant (in regards to ultima, ill edit my slip up.
@sorunome:yea, we know.
-
If we have over 256 sprites, we can always have sprite pallets for different areas.
Yes, that will definitely work. At 16x16 (or even 8x8) there won't even be >100 sprites on the screen st any given point.
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.
I already have a much more efficient algorithm planned for scrolling a 3-level gray tilemap that should take around 50000 cycles. I posted my idea in the coding section and I have PMed chickendude for his knowledge on the subject.
Also, I have my own grayscale routine (probably not nearly as optimised as the one in Axe) that is still as fast as a regular screen update.
EDIT: Here are some sprites I found on my computer that y'all are free to use. The mini ones are the same sprites that I have been using for my other RPG series, the bigger ones were what I was designing a long time ago for an RPG featuring scrolling tilemaps with 16x16 gray tiles :P I will have to see if I have code for that, now XD
-
I think that we should have a poll or something for the size and/or graylevels. Some people may want to get started on making them. :P
-
good idea, poll options then 8x8, 12x12 and 16x16?
And greyscale none, 3 or 4?/me pokes yeongJIN_COOL to add a poll
-
Res: 8x8
Grayscale: none (1/2 as much sprite data)
-
we need a poll for that as many people have different opinions :P
-
Well, I've changed my mind after talking to chickendude and seeing some screenies from zer project. I'm definitely for monochrome 16x16, but the sprites are going to be rather large and the tilemaps. Why?
(http://revsoft.tifreakware.net/phpBB3/download/file.php?id=89)
This means that sprites will need two layers for masking, and with how I am thinking of collision detection, another layer will probably be needed, meaning each tile will be 96 bytes 0.0
If we can figure out how to keep it in archive, though, that won't be a problem at all.
-
Wow that looks cool :o yeah i hope we can keep it in archive (run with shell?) cause that really looks cool
-
No, we can make code to read the sprites from archive :D
-
I'm not really sure on what sprite size I'd go for, tho I'm leaning towards 8*8 for memory and simplicity.
12*12 would be great if it can be made to work optimally both space-wise and speed-wise tho. Maybe the extra 4px on the bottom sould be used for a hud or something. (softkeys?)
As for the grayscale, a random thought that came to mind was maybe it have monochrome primarily, and have an option to make it 3-lvl gray for shininess if the player wants it? If they don't want it they could just not send an appvar or whatever with the masking sprites.
-
That would be good. Maybe some auto detection to see if it is an 83+ and automatically set to monochrome, else draw using grayscale if it is 15MHz capable. (And still have a grayscale option)
-
Well, just in case, this is 16x16 monochrome sprites I worked on long time ago. Feel free to use them if needed. :D http://yeong.57o9.org/pics.html
-
keep in mind when voting that it'll probably be a action RPG :P
-
Here are yeong's pictures converted:
-
keep in mind when voting that it'll probably be a action RPG :P
Actually turn-based is ahead now. However, people should vote based on what they think will work/look best regardless.
-
Well, I've changed my mind after talking to chickendude and seeing some screenies from zer project. I'm definitely for monochrome 16x16, but the sprites are going to be rather large and the tilemaps. Why?
(http://revsoft.tifreakware.net/phpBB3/download/file.php?id=89)
This means that sprites will need two layers for masking, and with how I am thinking of collision detection, another layer will probably be needed, meaning each tile will be 96 bytes 0.0
If we can figure out how to keep it in archive, though, that won't be a problem at all.
I really think 16x16 is the way to go, it allows for so much more detail.
4 Level gray would be great too. :D IMO if we go gray we should go all the way. ;D
*Edit*
To clarify, I want 16x16 wether we choose grayscale or not.
-
If we are designing our own npc character, this is what I want for mine(it's a pony):
(http://img.removedfromgame.com/imgs/PonySprite1.png)
Bigger:
(http://img.removedfromgame.com/imgs/PonySprite2.png)
Monochrome:
(http://img.removedfromgame.com/imgs/PonySprite3.png)
-
Pony sprites? O.o
That is EPIC!/me 'd need a derped pony
-
Well, I guess this community wouldn't be complete with all the pony talk, I guess?
Now if someone could put a bear sprite...
-
Our community consists by now out of more than 50% active members who are bronies :P
-
I just made front views:
(http://img.removedfromgame.com/imgs/PonySpriteFace.png)
Bigger:
(http://img.removedfromgame.com/imgs/PonySpriteFace2.png)
I don't know if my sprites will work for this RPG though...
-
My own character design. I'll get other sprites for it soon, hopefully.
(https://dl.dropbox.com/u/10573921/Omni_Tao.png)
-
It's not gonna look good, but I'll try to make one :P
I don't like ponies enough to have one as my sprite, nor do I really love any creature that much :P
Also a piano wouldn't be a very sociable character :P
/me has some pondering to do
-
It's not gonna look good, but I'll try to make one :P
I don't like ponies enough to have one as my sprite, nor do I really love any creature that much :P
Also a piano wouldn't be a very sociable character :P
/me has some pondering to do
Perhaps a piano player?
/me is reminded of this song)
-
Here is my final:
Side:
(http://img.removedfromgame.com/imgs/PonySprite4.png)(http://i46.tinypic.com/29b1v5x.png)
Face:
(http://img.removedfromgame.com/imgs/0-PonySpriteFace.png)(http://i48.tinypic.com/23mtoon.png)
Back:
(http://img.removedfromgame.com/imgs/PonySpriteBack.png)(http://i49.tinypic.com/lcto7.png)
-
they look awesome
ponies are awesome :D
-
Is anyone working on the tiles for the game? If so, I would like to begin working on the maps for the first parts of the game. If not, then what theme did we agree the game should be? I'm going to start with some placeholder tiles in the meantime and will post here. (Methinks a slightly medieval theme for the time being)
Edit: Here's what I have thus far
(https://dl.dropbox.com/u/10573921/TileMapEditor%202013-01-02%2004-53-53-93.png)
I attached the sprites in this post. They are under /Omni_Sprites/Tiles/ and they are numbered 0-13 due to the way I load images in TileCat.
-
I can work on tiles, but I need to know what is needed. A mockup of the world (or area I'll be starting on) is needed too. I need to know the setting from the writers (as you were saying) too. Also, I don't think graphing calculators were around in medieval times... :P
-
Also, I don't think graphing calculators were around in medieval times... :P
Or were they? o.o Sometimes they seem ancient enough XD
-
At the very least, a fantasy element is going to be present. Kind of a technological/medieval look like in FF IV? Or can fantasy work in modern day/sci fi settings?
-
I could do some artwork for the titlescreen. Or is there another artist working on this project yet?
-
I don't think there is a dedicated artist yet.
-
We could have multiple people draw a title screen and then have a vote.
Edit: I just made one. It could be better:
(http://img.removedfromgame.com/imgs/OmniRPGTitle1.png)
-
Threw this together really quick :P
I want to do a nicer font eventually.
-
Tis better than mine, but IMO, it looks kind of rough. :P It does look cool though.
-
Yeah I did not put a lot of efford in it.
-
I thought of having like a close up on the calculator and the menu itself is on the calculator screen.
-
So, you mean draw a calculator on the screen, then the screen of the drawn calculator has the menu?
-
Yeah,l something like that.
-
(http://img.removedfromgame.com/imgs/1-grass.gif)
A grass sprite. Animated according to Xeda's engine's current requirements if I did it right (4 level grey, 8 frames) also uses only the greys and white, so outlined characters are clearly distinguishable.
-
That's looking nice! :D
-
Thanks!
Oh, and for those concerned about Xeda's engine being 8x8, I'm fairly sure the plan is 8x8 tiles with 16x16 characters. You can accomplish more terrain detail, and you have the option for larger sprites if you wish.
Oh, does anyone know if we'll need edge sprites? As in, sprites that merge two types of tiles, like grass to rock.
-
Rough title screen animation(I used Keoni29's title):
(http://img.removedfromgame.com/imgs/http-__makeagif.com_media_2-18-2013_PtIr1b.gif)
The completely white frame is a flash of white and then it is supposed to fade into the Title screen, but as you can see by the makeagif thing on the bottom of the pic, I don't have my photoshop with me right now. :P
-
*BUMP*
Here are some better ones:
(http://img.removedfromgame.com/imgs/OmniRPGTitle.gif)
(http://img.removedfromgame.com/imgs/OmniRPGTitle1.gif)
(http://img.removedfromgame.com/imgs/OmniRPGTitle2.gif)
-
The bottom one I really like :D
-
The bottom one I really like :D
Yeah. I think it's the best one.
-
Make it grey.
Also, a cobble tile (like for medieval walkways)
(http://img.removedfromgame.com/imgs/Cobble.png)
like the grass, this one can be tiled vertically and horizontally. Not animated because it's just a pile of rocks.
And now a tile, like what you might see in a fancy building's kitchen or hallways.
(http://img.removedfromgame.com/imgs/Tile.png)
This time, an animated torch, for an upcoming cave/dungeon wall.
(http://img.removedfromgame.com/imgs/mosstorch.gif)
-
These are nice sprites :D
Also Spenceboy98, how did you made these intros ?
-
I don't really like the rising calc part. It feels disjointed. Here's a version I made without those frames.
(http://img.removedfromgame.com/imgs/OmniRPGTitle3.gif)
-
It feels a bit weird to me ... It's like it could be "Looney Toons" written on the titlescreen xD
-
Well, this wouldn't be the first thing on the screen in all likelihood. It would probably have at least one or two other logos first, like the omni logo.
You know what it really needs? A fire effect being applied to the torches.
-
@willrandship: Those tiles look very nice. To accomplish the grayscale, I will need to set the tile animation speed to the fastest, but that shouldn't be a problem. And yes, the plan is to have it 8x8 tiles, but a bunch of them will be pieces of 16x16 tiles, if that makes sense. This will make the tilemapping much easier and it provides a good balance of detailed tiles (16x16 tiles) and detailed tilemaps (detail is down to 8x8 tiles).
-
Makes sense. What's the limit of tiles per area? If it's high enough we could do big buildings with lots of tiles.
I was thinking of making a nice ocean tile animation. I think we'll need that too.
-
These are nice sprites :D
Also Spenceboy98, how did you made these intros ?
I used photoshop/imageready. :P
I don't really like the rising calc part. It feels disjointed. Here's a version I made without those frames.
(http://img.removedfromgame.com/imgs/OmniRPGTitle3.gif)
Yeah. It does feel a bit disjointed. :/
-
This zooming reminds me a bit of Zelda Dark Link Quest video at the end of the game :P (see 2:55)
Looks nice, though. Just make sure that you don't make it 40+ KB large like Zelda's vid :P
-
Do we have a story yet? I do not keep track of these things. If we have a definitive setting and story I might be able to do some sprites.
There you go: A generic titlescreen. Notice the staticy stuff on the sides. That's DJ's idea: Storing savedata in the picture.
-
Since this stuff is starting up again, what are the sprite sizes for this? The poll says 8*8 monochrome, but I think 16*16 would be better (for details and stuff). What do you guys think?
-
I was just going to ask this, too. From the tilemapping end, 8x8 is much easier and it is faster. I don't know if you saw the screenies in some of the other topics, but I included some tiles that were grouped together to form 16x16 tiles and some even larger. Using 8x8 tiles will give us the ability to still create and use 'fake' 16x16 tiles, along with 8x8 tiles for better detail in that way. From the perspective of data size and compression, I have been working on a tilemap compression routine that will compress be able to store large tiles (like houses or very large trees or anything else that is comprised of multiple 8x8 tiles) as a single byte, then upon decompression to RAM, it will simply take that byte and expand it to however large it needs to be. I would get into more detail on the compression methods I have in mind, but I will save that for the Coding topic.
-
I was just going to ask this, too. From the tilemapping end, 8x8 is much easier and it is faster. I don't know if you saw the screenies in some of the other topics, but I included some tiles that were grouped together to form 16x16 tiles and some even larger. Using 8x8 tiles will give us the ability to still create and use 'fake' 16x16 tiles, along with 8x8 tiles for better detail in that way. From the perspective of data size and compression, I have been working on a tilemap compression routine that will compress be able to store large tiles (like houses or very large trees or anything else that is comprised of multiple 8x8 tiles) as a single byte, then upon decompression to RAM, it will simply take that byte and expand it to however large it needs to be. I would get into more detail on the compression methods I have in mind, but I will save that for the Coding topic.
So, are we going to do 8*8 tiles to make 16*16 tiles?
-
I was just going to ask this, too. From the tilemapping end, 8x8 is much easier and it is faster. I don't know if you saw the screenies in some of the other topics, but I included some tiles that were grouped together to form 16x16 tiles and some even larger. Using 8x8 tiles will give us the ability to still create and use 'fake' 16x16 tiles, along with 8x8 tiles for better detail in that way. From the perspective of data size and compression, I have been working on a tilemap compression routine that will compress be able to store large tiles (like houses or very large trees or anything else that is comprised of multiple 8x8 tiles) as a single byte, then upon decompression to RAM, it will simply take that byte and expand it to however large it needs to be. I would get into more detail on the compression methods I have in mind, but I will save that for the Coding topic.
So, are we going to do 8*8 tiles to make 16*16 tiles?
That is exactly one issue where Streetwalker has the final say - ASAP.
-
Lol yeah IMO 8*8 with some 16*16 made of four tiles is the way to go for both technical reasons and for details (ie big trees vs small doors). ;)
-
Okay for tiles, but game characters ? Monsters ?
EDIT : also, what about the color ? Will sprites be monochrome or 3-level gray (I think 4 is out of the question) ?
-
Okay for tiles, but game characters ? Monsters ?
EDIT : also, what about the color ? Will sprites be monochrome or 3-level gray (I think 4 is out of the question) ?
Why would 4 be out of question ?
-
Because an RPG with tilemapping, masked collisions, NPCs and battle handling won't bear 4-level gray IMO. And also because Axe 4-level gray in a RPG become horrible on an 83+ BE as soon as you do anything more than DispGraphrr in a loop. Example, I find Ash:Phoenix totally unplayable on my calc.
-
Here's a tree I just made:
(http://img.ourl.ca//OmniRPGTree.png)
I don't know if it will be good enough for this (not sure what point of view angle thing we are viewing it from).
-
Tried to make it look better.
EDIT : MOAR SPRITES! I'm getting obsessed with pixel art! :p
-
I especially like the opening door animation :)
-
MOAR HOUSE PARTS! And edited the left part a little bit.
-
/me likes :D
So I guess we go with monochrome ?
-
Yeah, it's a calc game so even if we now master greyscale, we should go monochrome for speed and old-school style. ;)
Also on the map regular tiles (=one step for the character) should be 8x8. Though NPCs and the character should be higher (~9-10 high or something) and masked.
-
Could we use 8*8 for 16*16 meta tiles? I'd like to stick wth 16*16
-
Wow, those tiles are fantastic! I am also pleased to find that I actually made a map editor for Amber (though not very user friendly). I completely forgot about it.
Also, speed-wise, 4-level gray and 3-level gray LCD updates are about the same speed, and since the tilemap runs from an interrupt and is animated, you could technically make the tiles animate at about 40FPS while allowing movement (and this is at 6MHz). However, there are a handful of difficulties including how to handle grayscale backgrounds while a menu is open or text is on the screen, and energy consumption (I am pretty sure grayscale would cause more of a drain than b/w most of the time).
I really do like those 16x16 tiles!
EDIT: Also, my hope is that groups of tiles such as those for whole houses would take up 1 byte when compressed.
-
i like those 16x16 tiles too, nice job :D
-
I has to scale down to 8*8, because Streetwalker liked having a better view of the map... But still...
-
nice sprites, indeed :D
-
That won't stop!
-
Oh yeah that looks pretty good. :D Nice job Eiyeron.
-
Make me a list of what ya want.
-
If you could save a .bmp (or PNG or whatever) with the tiles in it, that would be great for me.
-
So, we're doing straight 8*8 instead of using 8*8 to make 16*16 (I prefer the 16*16)?
-
I am just taking the tiles as I get them, but I currently have this much working (see screenshot below).
I basically have most of the tiles from Amber (for now, until we get more tiles), plus a handful from this topic.
-
Looking pretty sweet!
-
There is a little problem: you have two houses with different perspesctive. Mine is Earthbound-like when yours is Pokemon-like
-
Looking sweat, but yeah, these perspectives...
-
I know, I just had a pre-built map from the last project and I only changed a few tiles to add the houses.
I really need to work on the map editor to make it more user friendly and flexible. I am trying to make it so that whole houses and trees can be placed at once. I also have to work out a final format for the tilemaps as well as the compression and decompression algorithms.
-
I also think the grass moves too quickly, i'd cut the speed at least in half. Btw, are do the animations continue when the player is moving (unaligned)?
-
I also think the grass moves too quickly, i'd cut the speed at least in half. Btw, are do the animations continue when the player is moving (unaligned)?
Animation is kept mostly smooth during walking, but as the screen is shifting, animation is kind of halted. It is still managed, so the frames stay on the correct time, but the tilemap is only redrawn once the scrolling has stopped (I use flags to indicate that the tilemap was supposed to be updated mid-scroll). As well, any newly scrolled in tiles that appear under the player are updated with the new data, so there may occasionally be a discrepancy in the correct frame used. It is difficult to notice for me unless I turn the emulator down to a really slow speed, but it shouldn't cause any problems.
Also, thanks for the input about the animation speed. The delay is currently half of the maximum, so I might need to include an extra counter.
-
YOu'll get many windows sprites because they are padded. That break the grid and offer nice positions!
EIDT: Got Pixelscape sprites. That definitly need a tileset dump to image function...
-
Good job so far :)
-
yay, more house sprites :D
-
Updating animations while scrolling is probably more trouble than it's worth anyway. It looks nice, though :) My favorite part of a new project is writing a new tilemap routine ;)