PixelArt editor - Another question :)

Started by SpacePaw, Mon 02/03/2009 16:58:47

Previous topic - Next topic

Charity

All of the following are fewatures I use frequently or wish I could use:

Multiple layers of Undo/Redo.  The more the better.

A quick way to convert tiles of a specified size into layers and layers into tiles.  This way you can stack frames in an animation or display them side by side.  Possibly, this should generate a new image.

Autosave backups.  I use the Gimp, and it crashes on me constantly, but even if you manage to construct a stable program, it is nice to know that if you do crash, you will never lose more than a couple minutes of work.

Simple lighting/tinting options with HSV and Brightness/Contrast.

Selection tools should constrict the area affected by tools and other functions.  Color picker should probably be immune.

Add/subtract/invert selection.

Transparency and alpha channel support.

At the very least, bmp, png, and gif support, and at least one lossless format capable of storing multiple layers with alpha channel.

Ability to adjust opacity of layers.

Wonkyth

Customisable Hotkeys as mentioned before, sound really good to me. using programs like Blender and the gimp I have constant problems with Hotkeys. while blender has everything Hotkeyed, they aren't really convenient.
"But with a ninja on your face, you live longer!"

SpacePaw

#42
Quote from: RickJ on Wed 04/03/2009 21:41:52
If your project is going to be open source and you wish it to work on multiple platforms then I would suggest that you consider Qt.  Windows, Linux, and Mac OSX are supported.  Their development tools are also multi-platform and the resulting applications are fast, self-contained and not dependent on bloated runtime package.  It was recently acquired by Nokia who appear to have big plans and a commitgment to open source with regard to QT.

Ahh... Now you really got me curious :)
I have 3 possibilities then...

1. .NET C# - Slower (framework dependant) and not much cross platform - but I know it really good
2. Java - still framework dependant but fully cross platform - I'm not as good at it as at C# though...
3. C++ in QT IDE+Compiler - cross platform and self dependant but I have no idea how to use it yet :)

I wish my university werent pro-Microsoft only, I would know other languages and libriaries much better now :/

AAAAND - Another question :)
I like the suggestion about it beeing designed especially for low-res game developers, what ideas do you all have concerning this? What functions (not talking about graphics now) would help you with developing the game then :) ? I'm sure that some presets about the canvas size would be nice but besides that I cant think of anything that could help us sprite-makers :)

EDIT: Oh and of course - THANK YOU ALL - You don't even know how you help me :) Thanks to you I'll write user stories and gather requirements in no time

SSH

Do it in python or ironpython or somethign!
12

SpacePaw

Nah I think I'm decided to use java. It has neat Java 2d library that will speed things up a lot :3

rharpe

Good choice, Java is cross-platformed! (PC, MAC, and LINUX people can unite!)

Also, in Java, you can cut many more corners and get a project developed in half the time... my opinion of course.  ;D

Can't wait to see the first alpha design.
"Hail to the king, baby!"

Babar

Quote from: SpacePaw on Thu 05/03/2009 19:25:58
AAAAND - Another question :)
I like the suggestion about it beeing designed especially for low-res game developers, what ideas do you all have concerning this? What functions (not talking about graphics now) would help you with developing the game then :) ? I'm sure that some presets about the canvas size would be nice but besides that I cant think of anything that could help us sprite-makers :)

I haven't gone in detail over the whole thread, so I may be covering ground that has already been done. I think someone already mentioned about grids. Being able to set them on and off, and vary the size- from 1 pixel grid to 5, 10, etc. (and whether it gets 'clipped to') would be useful. I don't know whether someone mentioned this before, but some flexible palette handling would be good. Most 'modern' art software does irritating things to the palette, like compressing it, rearranging it, etc. Having the option of doing this yourself would be good.


Kudos for going at this. The most I ever went at this was making a weird tile drawing program 8 years ago in Qbasic, that didn't even have mouse support :D
The ultimate Professional Amateur

Now, with his very own game: Alien Time Zone

SpacePaw

Quote from: Babar on Fri 06/03/2009 04:33:35
Being able to set them on and off, and vary the size- from 1 pixel grid to 5, 10, etc. (and whether it gets 'clipped to') would be useful.

What do you mean by clipping the grid?

Gilbert

I think he meant snapping to the grids. I might be wrong though. Also, (I never read all of the thread so I don't know if something similar was mentioned) be able to set the offset of the placement of the grids (not just snapped to (0,0) ) could be useful in some particular instances.

RickJ

Quote
C++ in QT IDE+Compiler - cross platform and self dependant but I have no idea how to use it yet
C++ is a good thing for a programmer to know  ;D.  QT is easy to learn and  results in clean and efficient code.  It includes 3d, 2d, and svg graphics libraries.  It also includes support for network and web (webkit used in many popular browsers), plus support for script, plugins, and other llibraries as well.  I humbly suggest you take  a test drive.

Quote
I like the suggestion about it beeing designed especially for low-res game developers, what ideas do you all have concerning this? What functions (not talking about graphics now) would help you with developing the game then..
First of all I think that "2d game developers" rather than "low-res game developers" better describes the need.

Secondly to answer your question you need to think about the process of creating graphical elements, importing them into a game, revising, reimporting, etc, and how this process can be made more efficient.  Here are some of the things I would be considering were I in your place:

Revision Control/Automation
Consider what would be required to change an animated sprite.   Ideally one would open the graphics source file (many  people don't even bother to preserve graphic source) make the desired changes, save under a different (i.e. MyGraphic-V01.pdd => MyGraphic-V02.pdd), then export each frame.  In photoshop for example each frame could be on a different layer or collection of layers, so to export a frame the appropriate layer(s) would be made visible graphic exported to a file of the form MyGraphic-V02-LLFF.png (LL=loop number, FF=frame number).  The process would then be repeated for each frame.

It would be great if this whole process could be done with a single mouse click, or perhaps two at most.   There could be a configuration dialog where the user could control the process.  This would only need to be done once.

Gale, as well as some other programs, does a better job of exporting frames but it still requires multiple clicks and some data entry each time an export is made or a new version of source is saved.   

Integration with AGS and other engines
Now that we have exported our animation to separate sprite files we need to import them into AGS and then create animation loops and select a sprite for each frame.  But inside the graphics editor we already knew which graphic went with which frame.   

What if it were possible export the source file to a single output file that contained not only the graphics but also the animation loops and frames.  AGS could then make use of this file directly and automatically import sprites, define animation loops and frames, etc, thus eliminating the need  to do all this manually. 

For backgrounds the concept of area masks could be added to the export file format.  This would mean that the masks and background image would always be coupled and that AGS could import the whole shebang in one click instead of doing it a piece at a time.

Of course all this AGS integration talk makes .NET an attractive choice, one that perhaps should be reconsidered if your project takes shape in this direction.   If a more general game integration is the goal then it would seem like self contained C++ with a Game Engine Integration API ought to be the choice.  Just my opinion of course.  :=

Grids, Guidelines and Perspective lines/tools
I noticed you are getting a lot of commentary about grids.  Take a look at Visio and how it handles grids.  As you zoom in the grid becomes finer eliminating the need to change grid spacing to achieve a more accurate placement of points.  One only need to zoom to an appropriate level an viola the grid you need is the grid you have.  Implement this kind of scheme and you will  have addressed 99% of grid issues.

The other thing to consider having different styles such as an isometric grid or a perspective grid (i.e. grid lines would be equally spaced with regard to a horizon line and vanishing point), etc. 

Guidelines are of course those horizontal and vertical lines that can be drug from the margins of the drawing surface.  They are helpful in placing graphical elements in relation to existing elements.  It would be nice if this concept could be extended to support perspective drawing.    A simple implementation would allow the user to drag/draw a guideline from one point to another point in the drawing and would allow an endpoints to be moved so that line would rotate around the other endpoint.   Perhaps there could be an ability to define a vanishing point from two or more such lines of perspective.       

Other perspective tools would also be useful.  The equal distance fence post ruler thing comes to mind but I am sure there are other things that would be useful in making perspective drawings.

Project Support
It would be nice if there could be project wide settings, project specific templates and a project root directory.   If we are going to be specific for games then the project should contain categories of graphical elements such as rooms, characters, GUI, etc.  Perhaps these categories are configurable so the user can have as many or as few (even zero) as desired.  The root would then contain a sub-directory for each category of elements.  This would be done to provide easy navigation through the project.  When the user clicked he would first select the category and then the element or directory to open.  He could also elect to navigate the file system as one wwould normally expect.   

SpacePaw

Quote from: RickJ on Fri 06/03/2009 14:53:23
Project Support
It would be nice if there could be project wide settings, project specific templates and a project root directory.   If we are going to be specific for games then the project should contain categories of graphical elements such as rooms, characters, GUI, etc.  Perhaps these categories are configurable so the user can have as many or as few (even zero) as desired.  The root would then contain a sub-directory for each category of elements.  This would be done to provide easy navigation through the project.  When the user clicked he would first select the category and then the element or directory to open.  He could also elect to navigate the file system as one wwould normally expect.  

This sounds fun. I like the idea of beeing able to create an "AGS Project" or just a blank canvas. The project would be organized with the rooms, sprites and stuff... (I might not be able to integrate it with ags as I'm not sure if there's a possibility to write an import plugin for it) you would just "add room" where you would have areas layers and your drawing layers etc etc...Nice idea... really nice

Charity

One Gimp function which I absolutely love is Copy Visible, which lets you copy sections of the image as you see it, instead of just copying information from one layer at a time.  Saves a bunch of trouble merging layers and such.

RickJ

#52
Quote
This sounds fun. I like the idea of beeing able to create an "AGS Project" or just a blank canvas. The project would be organized with the rooms, sprites and stuff... (I might not be able to integrate it with ags as I'm not sure if there's a possibility to write an import plugin for it) you would just "add room" where you would have areas layers and your drawing layers etc etc...Nice idea... really nice
Just to clarify,  what  I meant by "project support"  is that a project would be contained in a sub-directory tree.   The root could contain user defined categories such as room, character, etc.  Each of these categories would manifest as sub-directories in the root directory.  When the user selects "new" from the menu he would first have to specify what kind of entity to create by selecting a category from a drop down list then then entering a new room name.  A directory is created in project->rooms->new_room_name for the new room and is populated with project specific room template files.  Here is an example of what a project space may look like.

project
     rooms
          intro  
               intro-00.sps (spw=SpacePaw source file)
               intro-01.sps
               intro-01.spx (spx=Spacepaw export file)
               intro-01.png
               intro-00.txt
     characters
     gui
     inventory



Quote
(I might not be able to integrate it with ags as I'm not sure if there's a possibility to write an import plugin for it) you would just "add room" where you would have areas layers and your drawing layers etc etc...Nice idea... really nice
So far this is non-AGS or game engine specific.   The game engine doesn't necessarily need to know the anything about directory structure with regard to integration.  Integration would come about through an open source file format and api (i.e. .spx in the above example) for an export file containing the information required for a game engine to import  the entities which it contains.

So in AGS an editor plugin would be required. to import  the spx file.  You say that you are skilled in .NET and CJ is usually very willing to provide functionality required by plugin writers so I would be very surprised if this couldn't be done.

Quote
Nice idea... really nice
Glad you liked them   ;D

[edit]
The MNG file format may be a candidate for your spx file.  It's the PNG equivalent of a GIF I suppose.  Anyway here is the link.
http://www.libpng.org/pub/mng/spec/

SpacePaw

Quote from: RickJ on Fri 06/03/2009 19:41:53
So in AGS an editor plugin would be required. to import  the spx file.  You say that you are skilled in .NET and CJ is usually very willing to provide functionality required by plugin writers so I would be very surprised if this couldn't be done.

Well yes, it's not SO hard to make BUT I would need to have some sort of a source code or manual for making AGS plugins (if it supports them anyway). I need to know what kind of input it requires :)

Quote from: RickJ on Fri 06/03/2009 19:41:53
[edit]
The MNG file format may be a candidate for your spx file.  It's the PNG equivalent of a GIF I suppose.  Anyway here is the link.
http://www.libpng.org/pub/mng/spec/

I'll check it out - sounds fun so far :)

SSH

Quote from: SpacePaw on Sat 07/03/2009 11:31:32

Well yes, it's not SO hard to make BUT I would need to have some sort of a source code or manual for making AGS plugins (if it supports them anyway). I need to know what kind of input it requires :)

http://www.adventuregamestudio.co.uk/accomplug.htm
12

RickJ

Quote
Well yes, it's not SO hard to make BUT I would need to have some sort of a source code or manual for making AGS plugins (if it supports them anyway). I need to know what kind of input it requires Smiley
In addition to what SSH said the API is expanded as needs arise.

I should also point out that there is currently an AGS inport/export file format for characters .CHA and perhaps this would make a better starting point for the "spx" file than MNG. 

SpacePaw

Oh great! I love you guys! This helps a lot :) AGS is much better then it was many years ago...

SMF spam blocked by CleanTalk