Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Runer112 on November 27, 2010, 10:07:44 pm
-
As some may have learned from a poll I posted a while ago, I've been working on a sprite editor in Axe. Or at least I was working on it, but put it down for a while to work on other stuff. But I want to come back to it, and I want to make sure it's as feature-packed and awesome as it can be. So before I get back to work on it, I'd like to know: What features would you want to see in the on-calc sprite editor of your dreams? Did I miss any useful editing tools? Did I miss a file operations feature? Request any features that you don't already see in the list below, or tell me about features already in the list below that you would especially like to see implemented.
Potential features (some are obviously more fundamental than others and will definitely be implemented, whereas others would probably be ridiculously complex to implement):
- Black and white, 3-level gray, and 4-level gray sprites
- Masked sprites
- Sprites of any size
- Viewing and editing at any zoom level, including zoom levels that don't fully fit on the screen (scrolling will be necessary)
- Point tool
- Line tool
- Box tool
- Circle tool
- Variable pen size for drawing commands
- Fill tool
- Text tool
- Hex editing
- Area selection, transforming, cut, copy, and paste
- Palette transformations (e.g. changing the color of all dark gray pixels to light gray and all light gray pixels to dark gray)
- Sprite transformations (flip, rotate, shift)
- Sprite conversion/attribute editing (e.g. changing size, changing gray level)
- Tilemaps
- Animations
- A full filesystem (files, folders, shortcuts, etc. with names and attributes)
- A file explorer
- A menu system
- Shortcut keys for most menu items
- Search
- File sorting in folders by various attributes
- Importing data from and exporting data to pictures, strings, and Ans
- Undo/redo
- File selecting, moving, copying, and deleting from the file explorer
- Batch sprite transformations
-
something i'm doing in mine is having a "Set", where it's a bunch of sprites with the same size and color. useful for sprite animations and tilesets, though i think this could be covered with a filesystem. Tilemaps would be interesting to see.
if you end up implementing most of what's on this list i wouldn't call it a sprite editor, i'd call it an image editor.
edit: feature request, loading from Str1-Str9.
-
I see what you mean by how sets could be useful. I think that can probably be covered by the user having multiple sprites with the same attributes in a folder, so I don't know if I'd need a specific "Set" function.
And even if this thing ends up with AI, I'd probably still just call it a sprite editor. ;)
-
That's a lot of features O_o
I can only think of a couple things that are missing:
Ability to scroll (So we can edit, say, a 32*32 sprite at 4x zoom)
Cut/Copy/Paste (Box selection, unless you really want to add the ability to deal with user-drawn shapes ;D)
Can't wait to see if you implement this! :)
-
That's a lot of features O_o
I can only think of a couple things that are missing:
Ability to scroll (So we can edit, say, a 32*32 sprite at 4x zoom)
Cut/Copy/Paste (Box selection, unless you really want to add the ability to deal with user-drawn shapes ;D)
Can't wait to see if you implement this! :)
That would be great! Does it work with frames/animations already? if it doesn't, I'd like to see that too
-
That's a lot of features O_o
I can only think of a couple things that are missing:
Ability to scroll (So we can edit, say, a 32*32 sprite at 4x zoom)
Cut/Copy/Paste (Box selection, unless you really want to add the ability to deal with user-drawn shapes ;D)
Can't wait to see if you implement this! :)
Both of those were features that had crossed my mind but I never wrote down. I'll add them to the list and make sure that whenever I build the editing platform, it's very flexible and can support things like arbitrary zoom levels and scrolling.
Does it work with frames/animations already? if it doesn't, I'd like to see that too
I already have planned animations as a potential feature, although I haven't worked on it (or most things on that list). Most of what I've worked on so far is the filesystem itself and making sure I set up a framework that will support a vast array of features, like animations.
-
"I already have planned animations as a potential feature, although I haven't worked on it (or most things on that list). Most of what I've worked on so far is the filesystem itself and making sure I set up a framework that will support a vast array of features, like animations."
There is a sprite editor made by Deep Thought I think which has animations, you could check it :)
-
I think the filling tool should be for both sprites and tilemapping. When making world maps, for example, it's nice to be able to fill an entire area with water, for example.
Also, for tilemapping, variable tilemap size would be nice. Also it would be cool to have support for 1, 4, 8 bit and if it's not too complicated, 2 bit tiles. Example of 1 bit tilemaps are Illusiat 6, 7, 9-12, Mana Force 2 and the Reign of Legends dungeons.
-
I haven't really thought about how the tilemap editor will end up, but that's a nice idea. And I've already built room into the tilemap filetype's metadata to support any tile bit depth from 0-15.
-
Cool.
I would really love a complete tilemapper because sometimes I want to work on something, but what demotivates me is the fact I would need to write a tilemapper and sadly, my last two attempts were futile. (despite the help I got)
-
Export function, thats what I've missed in your last version xD
-
Also would this be an APP? The issue with the other tilemapper was having to archive/unarchive everything back and forth during development. I know I can use Doors or CalcUtil, but when I develop, I prefer that no other ASM stuff is being used on my calc. In other words, only Axe and my work will run. It's quite easy to mess something up in Axe and if it happens to conflict with CalcUtil or Doors it has higher chances to mess things up.
-
Export function, thats what I've missed in your last version xD
It's already in the list, bundled in with an import function.
Also would this be an APP? The issue with the other tilemapper was having to archive/unarchive everything back and forth during development. I know I can use Doors or CalcUtil, but when I develop, I prefer that no other ASM stuff is being used on my calc. In other words, only Axe and my work will run. It's quite easy to mess something up in Axe and if it happens to conflict with CalcUtil or Doors it has higher chances to mess things up.
There are multiple reasons that this will definitely be an application:
- Running the program as an assembly executable would take up a large portion of user RAM just to hold the executable. This will leave little free space for anything else, like the data appvar.
- The finished program will undoubtedly be larger than the assembly executable code limit. (I hope I can even fit it into an app!)
- This will leave more user RAM free, allowing all data to exist in RAM. This (hopefully) means no constant unarchiving and archiving will be necessary.
- Leaving more user RAM free will also allow for the free space to be used as an extensive undo/redo history.
- It seems more suitable for large utilities like this to be an application, anyways.
-
This sounds really cool! How about different size tools for the point on/off? Like a 1x1, 2x2, 4x4 space by each. :)
-
Export function, thats what I've missed in your last version xD
It's already in the list, bundled in with an import function.
Also would this be an APP? The issue with the other tilemapper was having to archive/unarchive everything back and forth during development. I know I can use Doors or CalcUtil, but when I develop, I prefer that no other ASM stuff is being used on my calc. In other words, only Axe and my work will run. It's quite easy to mess something up in Axe and if it happens to conflict with CalcUtil or Doors it has higher chances to mess things up.
There are multiple reasons that this will definitely be an application:
- Running the program as an assembly executable would take up a large portion of user RAM just to hold the executable. This will leave little free space for anything else, like the data appvar.
- The finished program will undoubtedly be larger than the assembly executable code limit. (I hope I can even fit it into an app!)
- This will leave more user RAM free, allowing all data to exist in RAM. This (hopefully) means no constant unarchiving and archiving will be necessary.
- Leaving more user RAM free will also allow for the free space to be used as an extensive undo/redo history.
- It seems more suitable for large utilities like this to be an application, anyways.
Yeah. With many BASIC utilities, you need to archive the entire game, unarchive the sprite editor/map maker, make sprites/maps, archive the editor, unarchive the map program to paste the data in, archive it, unarchive the game, test, and repeat for your 200 or so maps/sprites. X.x
-
Maybe the user could set it as an animation and, after they've drawn the sprites, he could preview it?
Wait--is that already planned?
-
I know this one would be hard, but how about this:
Pressing [On] and [Vars] at the same time would launch the sprite editor if you were editing a program. When finished editing sprites, you would return to the same spot in the program you were editing.
Sounds like fun to code. :P
-
yes, very fun to code indeed ;)
-
This sounds really cool! How about different size tools for the point on/off? Like a 1x1, 2x2, 4x4 space by each. :)
I completely forgot about that. I'll definitely want to make sure that you can change the pen size for all drawing commands.
Maybe the user could set it as an animation and, after they've drawn the sprites, he could preview it?
Wait--is that already planned?
Already planned. :)
I know this one would be hard, but how about this:
Pressing [On] and [Vars] at the same time would launch the sprite editor if you were editing a program. When finished editing sprites, you would return to the same spot in the program you were editing.
Sounds like fun to code. :P
I'll probably end up writing this in Axe, so hooks are probably out of the question. Not to mention I know nothing about hooks in the first place. But you never know. If I figured out how hooks could work it might be possible to code the hook in assembly and just insert it into the rest of the Axe source.
-
One feature I'd love is to be able to move the image around, like the select tool in some image software. I know it's possible from experience, but I'm not sure you could implement it efficiently.
-
One feature I'd love is to be able to move the image around, like the select tool in some image software. I know it's possible from experience, but I'm not sure you could implement it efficiently.
i like that idea.
-
One feature I'd love is to be able to move the image around, like the select tool in some image software. I know it's possible from experience, but I'm not sure you could implement it efficiently.
i like that idea.
Me too. Great idea! ;D
-
One feature I'd love is to be able to move the image around, like the select tool in some image software. I know it's possible from experience, but I'm not sure you could implement it efficiently.
That sounds really hard to implement... Let's try it anyways! *Puts on list*
EDIT: I also added palette changing, as I thought about it before but it seems to have missed making the list. By palette changing I mean things like changing all dark gray pixels to light gray and changing all light gray pixels to dark gray. This could also be used to invert images.
-
Would it also inverts white with black, white with dark gray and that stuff? It really sounds promising. How large is it so far, btw?
-
One feature I'd love is to be able to move the image around, like the select tool in some image software. I know it's possible from experience, but I'm not sure you could implement it efficiently.
That sounds really hard to implement... Let's try it anyways! *Puts on list*
Assuming that you're treating each pixel as an individual unit (think cellular automata), then it's actually fairly easy. You just read the screen image and write it to a known location in RAM. When you paste it again, just copy from RAM back to the screen. It's displaying the image during movement that's the tricky part :P
-
Are you using it for a project you're working on or something Qwerty?
-
Actually, I've already implemented it in my own Sprite editor ;D
-
I meant the sprite editor. :P
-
I still use Quigibo's BASIC Hex editor. I don't even use the one I wrote :P
Now if Runer decided to include Text-to-Image in his program...
-
Text to image?
-
Text-to-image would turn text such "Hello" into the hex codes corresponding to an image of the text. Probably not feasible though.
-
I still use Quigibo's BASIC Hex editor. I don't even use the one I wrote :P
Now if Runer decided to include Text-to-Image in his program...
I see, lol. If you don't use it, though, why not releasing the source or parts of it if it can be helpful for other sprite editor makers?
-
Because it has one bug: It doesn't generate Hex code :P
-
Text-to-image would turn text such "Hello" into the hex codes corresponding to an image of the text. Probably not feasible though.
It's very feasible, and is already on the list. All you would need to do is print the text onto the sprite.
-
So can you type in the text or you have to do the printing by hand? The latter takes forever and I try to avoid it as much as possible.
-
So can you type in the text or you have to do the printing by hand? The latter takes forever and I try to avoid it as much as possible.
Print, as in using the OS text routines to print characters onto the screen.
-
No, I mean having to draw the image yourself so that it resembles text.
-
That's why I was trying to tell you that I plan to implement a text tool so you can type characters and they get drawn right into the sprite.
-
Oh, then I'll definitely be downloading it. ;D
-
That sounds like a great feature! It would be useful for those designing custom fonts. ;D