I didn't realize that he was an anime char....gangsta wrote:tootin' ur own horn, eh Tim? but I second you. and kalan_vod, what are you talking about?
Edit: Its cool what 2 mins. in photoshop can do.
Thank you I don't want to bother anyone with it, but I really believe it can help people make better software, so yes, I like to promote itgangsta wrote:tootin' ur own horn, eh Tim? but I second you.
Requests:kv83 wrote:Right now?Jim e wrote:So when can I make request?
Animation is something handled in the code. You just place the start tile on the map, and your code should recognize it as 'start tile'. The editor will not show the sprite animated in first versions. But maybe I'll add something later on.so, will this support animate tiles/maps?
I don't get what you're saying. Isn't this something the code handles? Maybe you can explain it more in detail or even better with examples.Support masking and different method of drawing, i.e. OR then XOR, to support trasparency and invert.
Neither do I understand this one. What I can say is that I plan to use something like a 'build script' to indicate how the map and sprite data is converted (compressed or not, order, extra indicators) into the include file for the z80 source.Reordering of the mask layers(to satisfiy code end)
You can create different spritesheets. Spritesheets can have different sizes. Sprites within a spritesheet have to be the same size. Maps can only use one spritesheet as tileset. Is that good enough? Or are you requesting something else?Individual sprite size idependant of the other sprites(unlike how calcGS is purely TILE editor)
Can you explain me the concept behind this? I'll see what I can do then.Support submaps to save memory with tiles(like ducks zelda)
In first versions sprites will be limited to an ammount of 255 (8bit). However, I plan to expand that to a 16bit value as soon as you add more than 255 sprites.Maps support entries 8bit or 16bit(incase I need alot of tiles Wink )
Isn't this just a 2nd map? Just create a 2nd map collection and then create a 'Spritesheet' to make 1x1 sprites or something to indicate different states. Finally you draw the map of walkable tiles and which are not. In the build script you include that you don't want to include the 2nd map collection. Another way to do this, if you have walls which are walkable and which are not, to create a 2nd sprite which get's another number. In that case you'll only have to check in your code which wall-tile it is.Allow indicator bits on the map and methods of flagging them(you know defineing whats walkable)
Import functions is certainly planned, but I have yet to determine the ammount of features.Probably a little useless for the TI world (?) but one thing that could be useful is an option to import a bitmap, have your application split it into 8x8 tiles, discard any redundant tiles (identical) and possibly even match tiles as redundant if they just need a flip, then build the map/tile set out of that image.
Code: Select all
sprites:
.incsprite "resources/sprites.em", 0, 9 ; Include sprites 0->9
title_map:
.incmap "resources/sprites.em", 0 ; Include map 0
tiles:
.incsprite "resources/sprites.em", 10, 42 ; Include sprites 10->42
main_maps:
.incmap "resources/sprites.em", 1, 9 ; Include maps 1->9
Well for me when I do greyscale sprites I will have mask layer, light grey layer and a dark gray layer. So If I had to use calcGS, grey was easy enough but I had to make the mask layer seperate(even in a seperate gst file). Real pain if I needed to make hundreds of those things.I don't get what you're saying. Isn't this something the code handles? Maybe you can explain it more in detail or even better with examples.Support masking and different method of drawing, i.e. OR then XOR, to support trasparency and invert.Neither do I understand this one. What I can say is that I plan to use something like a 'build script' to indicate how the map and sprite data is converted (compressed or not, order, extra indicators) into the include file for the z80 source.Reordering of the mask layers(to satisfiy code end)
The thing is that in games like zelda there are a lot of redundant blocks on the map(like trees, paths, buildings) so submaps can save drawing time and compress the map a great deal. Basically what I am asking is if it's possible to treat a set of small sized maps(like 2x2,3x3,4x4) as if they were tiles and use them to draw a bigger map. So it would go:Can you explain me the concept behind this? I'll see what I can do then.Support submaps to save memory with tiles(like ducks zelda)
Problem with a second map is that it's wasteful, if I am only using seven bits in the actual map, adding an extra bit per tile will only cost memory and not gain anything. Also if I update one map I'd have to update the other seperately.Isn't this just a 2nd map?Allow indicator bits on the map and methods of flagging them(you know defineing whats walkable)