next »

[Annabelle Kennedy]

Well, I would prefer a program that does not force you to install 10 different runtime systems like dot-net, java, etc. on your computer. Just for a small program to set some pixels. So I vote for C++

ill also vouch for this.. IDRAW3 can run as just a standalone EXE and does everything.. and its really compact and great we need more compact and great and less bloat.

[michael]

we need more compact and great and less bloat.

[Laremere]

i will vouch for the fact that loads of people have terrible, old computers.

On another note I have a idea for how the menus could work, I'll try to get an example done today.

[Michael Buckley]

Well, I would prefer a program that does not force you to install 10 different runtime systems like dot-net, java, etc. on your computer. Just for a small program to set some pixels. So I vote for C++

ill also vouch for this.. IDRAW3 can run as just a standalone EXE and does everything.. and its really compact and great we need more compact and great and less bloat.

Again, Py2Exe wraps everything up in a single exe. No need to install any other runtime.

I'd just like to explain the rationale for my suggestion of Python one more time, and some reasons why it shouldn't be used.

The primary reason to use Python for something like this is speed of development. I'm not sure that a project like this can maintain enough sustained interest to last for a long development cycle. It might, but it might not. It's faster to develop a program in Python than in C++.

Most C++ programmers who use wx are used to dealing with it directly. I was hoping in suggesting Python that it would be easier to convince whichever programmer takes on the job to design a set of GUI classes which encapsulate wx, Again, this could be done in C++, but I felt it had a better chance in Python. In the end what this means is that if wx doesn't work well on a certain platform, it would be easier to replace the GUI code using a different library.

Finally, python would simplify the development and porting process. No need to worry about different compilers on different systems. No need to mess with configure scripts on *NIX-based systems.

The two reasons I see to go with C++ are speed and familiarity. I forgot that this, being a gaming forum, has a lot of C++ programmers. I program primarily in C++ myself. Even if C++ has a longer development cycle, if we have 10 people working on the project who know C++ but only 2 who know Python, C++ development will probably go faster.

The second is speed. As Agh pointed out, it's going to take about 8 seconds to initialize a 8000x8000 canvas the way things are designed now. I definitely agree with Chman that there are definitely ways to optimize the design to run faster.

I think the key is how fast we want it to run. I have seen some amazing pixel art that stretches for thousands of pixels in one direction. Do we want to accommodate folks that want to use this as a general-purpose pixel art program? Although that artwork is amazing, it doesn't really have an application in games. As such, these people aren't going to be served by the features in Tixel targeted towards game designers.

If the answer to that question is yes, then C++ is pretty much your only answer. If the answer is no, then I believe that Python can be made fast enough.

Also, I would like to point out that no one, including myself, is advocating for OpenGL. Although I think that even software emulated OpenGL would be up to this task, it's just overkill. Even SDL is overkill for what this program would need, as wx contains a Frame class that would be more than adequate for this task.

[Corpus]

we need more compact and great and less bloat.

We need... the µTorrent of pixel apps.

[Mr Dumle]

Add customizable keyboard shortcuts and you probably end up with the best pixel software ever created. 

[Nitro Crate]

Just a minor suggestion from me.

Right click opens up a circular menu around the mouse, with a quick access toolbar menu, maybe even replace the standard toolbar with it?

[Chman]

Yep, it's a Pie Menu

Although it shouldn't be on the right mouse button as you can put a tool on it, but a middle mouse button click (wheel click) or the big & easily accessed space bar.

[FoxBlitzz]

Right-click? No, right-click is used for the secondary tool.

I'm thinking it could be assigned to Space or middle-click. Maybe the Menu key (the key between Right Alt and Right Control on Windows keyboards), though that might confuse some people.

Maybe it could also provide quick access to colors? Or should that be the job of the quick color-picker?

Also, the standard toolbar is not going anywhere. It'll be dockable, undockable, and closeable, but it's not going to be completely removed from the actual program. The Pie Menu should only be seen as an alternative, instead of the only method for certain tools.

[Melly]

Ideas I second:

- Flash-like animation timelines with layers and an easy way to show onion skins. (pretty much what I'd love the most. I really like aniamting in Flash, with the sole exception it doesn't do pixels)

- Fully customizeable keyboard shortcuts for nearly everything, including binding zoom in/out to single buttons, and not forcing the use of ctrl/alt on people.

- The pie menu seems very interesting.

- Easy pallete editing and management.

- Keep the program light, fast and compact. I hate the bloated mess that most artistic programs are nowadays. I wanna be able to open the thing in less than 2 full minutes.

- This:





Ideas I suggest:

- Have Annabelle do actual pixel art for the whole interface (would be so awesome). Or another equally awesome pixeler.

- Have software rendering as well as hardware rendering, but make software priority. Like it's been often said, many people have trash computers with trash on-board video cards. The light and fast suggestion works very well for them as well.



Overall this project greatly excites me. Good luck.

[Michael Buckley]

- Accept Decipher's help. He's crazy with graphical coding.

I totally agree. The stuff he's offered to help out with is absolutely essential for a project like this.

[Laremere]

This is my idea for how the menu could look:



How this could work is this:
The center wheel is what the pie menu looks like when activated.  My idea for activation is the center wheel, then either clicking left or right on the color/tool will select it for that button.  Just clicking and holding the center wheel and moving it to an item and releasing defaults to the left mouse button.

What you do to select things are to click on the tool to select it (in my example "them" is selected) and then you can assign it to a position on the wheel by hitting the position on the wheel you want it.

The area left and right below the wheel shows what you have selected, if it works better to have the tool on top away from the color, that would work fine also.

My idea for the color selector (which is more or less separate from the rest of the idea) is that there are two "menus" for colors.  The first is your base colors, then second is a derivative menu of the select color.  The idea behind this is this:  Say you have a few "base colors" for your pixel art:  A green for the grass, a brown for your beach, and a blue for your water.  What you want to do is have several variants of each of those colors so that you have lighter or darker versions oh each for detail.  So you assign your three base colors, then for each base color, you select it, click an empty box and select one of several preset filters (such as lighten, darken, shadow [that adds a little more blue when darkening], burn [little more brown when darkening], and so on) and the intensity of that filter, or manually set the addition and subtraction values.  You then can use these colors and assign them to the wheel, and use them.  The variants title bar could easily be clicked to turn this off.

Also because I wanted to: colour.


Any suggestions, ideas, comments, rejections?

[Gold Cray]

I like the idea of putting a color pallet on a pie menu. That way it wouldn't be in the way, but you wouldn't have to cross the screen every time you want a different color. I also suggest that the button used to activate the pie menu be customizable so that people with mouse wheels can set it to the center button and people without reliable mouse wheels can set it to the keyboard.

As for language, we could perhaps write it in python for a general release and then port it over to C++ for a set of platform-specific fast versions. After all, getting everything working in the first place is the hard part. After that it's just a matter of syntax.

[Laremere]

True, all buttons really should be customizable...

[Decipher]

I'm glad to see this project pacing, but my concerns about its structure and design are still there...

First of all the project has no planning, the programming language is an issue, the feature list, approaches, patterns, design, coding guidelines, syntax, notation, ..., everything is an open issue and they will never be solved if we keep this forum based discussion as such. We have no plan on how to develop, yet spare the question of "what to develop?".

Also who's doing what, did they ask others before doing that and if they didn't who put them in charge of doing it? I'm so sorry if I sound as if I'm disdaining those who show an effort for the project, but I am not doing that. My point is, it is quite clear that this project is a community effort and collaboration. It's not an individual's personal project. Which means we also need a system to represent the heaviness of an individual's rights on deciding for the project's now and future.

Thus, I'd like to suggest a meritrocratic structure, the more you contribute the more you can change.

As for the repositories, not everyone should be able to change the files however they want, I also support a voting process before accepting new features for development and changes to the source code. If everyone is positive about me hosting the project I will set up the environment with whatever the community needs to develop, maintain and manage the project.

And now there go my ideas:

• Totally customizable interface: Everything should be customizable, some might like a toolbar, let's say I don't. Then instead of being forced to have it, I should be able to remove it, but still have its functionality reachable. So, something like Opera's interface editor would be really cool; being able to move the individual components of the bars instead of the bar itself. So, if I don't like toolbars I can create a pie menu and add the buttons I use in the toolbar to my pie menu.
• Humanized messages: I am quite sure almost all of us find the message boxes that pop up every now and then while typing something or drawing a line annoying. They simply murder the flow. So I think humanized messages would fit very well into a project where the tasks are precision-critical.
• Own GUI toolkit: Now this might sound a bit extreme, but it totally isn't pointless. If we have our own GUI toolkit we can decide not only for their traits but also their workflows. Such as, we can modify what happens when you press a scrollbar's arrow button. This would provide us with an immsende flexibility and liquidity. One other pro of coding a GUI toolkit is, we can change the renderer (let's say from GDI to OpenGL) and still have the exact same functionality. With the native GUI, things like transparency won't work on hardware overlays, which I believe is important for humanized messages and many other features.
• Module based codebase: I suggest our codebase to be totally modular. We must be able to extend every single component without any workarounds, hacks or hooks. Also this way we can have plugins that can pretty much change anything in any way desired. And that won't help us only with the coding process but the artist will be able to drop the features he/she doesn't need, thus completely avoiding the bloat.
• Developer console: Yes, sounds weird for a graphics editor I know, but it might be really useful within the development process. With a simple scripting language such as MonkeyCode, LUA or hell even Python (*simple* eh? ) this feature might save us huge amounts of time that would have been spent while re-compiling the project otherwise. This will be the most beneficial when the project gets quite big in means of code size.
• Colour history: This is one thing I'd die for. Whenever I use more than two colours in my craptastic art, and try variations of a colour, I always feel like returning to the previous colour "I found nice but thought of improving". But, of course ^Z works to a certain point, and there's always the risk that you can press a button unintentionally and fork the history tree, ending up losing all the stuff you have done (yes this happened to me more than once). So, a simple colour history or colour cache could be really nice, and at the worst case scenario a single colour would be represented using 1024 bits (128 bytes) of data considering we can take the representation to an extreme level of a double-precision floating-point value per channel. Comparing that to the memory available on modern PCs, it shouldn't be a problem to have such a feature.
• Workspaces: This one is quite simple, different projects might require different interfaces customized by the artist. A way to save and load these interfaces (preferably in a seemless way, 3D rotatable interfaces? ) would be so awesome.
• Bird's eye view: A bird's eye view where we can see the individual layers and the filters attached to them as well as the specific modification, colour, etc. histories per layer. I will post a mock-up as soon as possible, this idea comes from a demotool that me and a few scener friends develop (if you know what demoscene is, a demotool is a tool that provides one with the features to be able to easily create audio-visual demonstrations).
• Silk-smooth: I think everything should be silk-smooth. Let's not forget that our target audience is graphics artists who might expect their products to be flawless and stylish, this is mostly an interface-design issue, though I believe heavy use of effects and transparency might help us a lot, this way we can have a non-interruptive environment that flows with the artist.
• Touch-screen mode: This is another interface-design issue and I think we can leave this for a later phase as of now, but I'd appreciate a touch-screen mode where we can control self-defined tasks with our touches, a simple concept-demonstration of what I am trying to say can be found
  
  . And I believe this kind of an interface can even change the future of every other software out there .
  

[Decipher]

Also I forgot to add this morning, despite being totally in love with Python, I am all for C++. Matter of personal taste and opinion I guess, but I believe C++ would give us more power and flexibility with less overhead and cost (as in resources).

[FishyBoy]

Gale has layers, so you could do stuff like that.

I would use that, but I'm lazy so I just use the default Game Maker editor, which is surprisingly good!

[Nitro Crate]

Also maybe the quick color pallet on the pie menu could be a sub-pie menu?
As in, you hover over a pallet icon and then a color pallet pops up.

Also I love this:



And I have to second the notion that the gui should be pixelized.

Edit:
Customizable hotkeys?
(Also not all mice have the middle mouse button, so maybe holding both right and left down, or a keyboard key should be default? Heh, if the mouse wasn't a concern, I'd say 4th mouse button is optimal.)

Also what about animation?

Edit2: What about keeping the program as small as possible and then adding additional functionality through the use of addons (like firefox)?

[Chman]

Gale has layers, so you could do stuff like that.

Yeah, but I don't like Gale's layers as it's per-frame. Something like flash layers would be cool.

[coderneedsfood]

Did anyone check out PixelToaster ?

looks like it could be a good match http://www.pixeltoaster.com/

PixelToaster is a library for C++ programmers who want to write their own software rendering routines, instead of using hardware accelerated rendering with OpenGL or Direct3D.

To use PixelToaster, all you need to do is ‘open’ a display at the desired resolution, then each frame, render into an array of pixels and ‘update’ your pixels to the display.

Pixels are 32 bit truecolor or 128 bit floating point color at your choice, and are converted to the native display format automatically each update.

You also get basic keyboard and mouse input and a high resolution timer, plus portability across PC, Mac and Unix boxes with quality open-source code.

PixelToaster is designed by Glenn Fiedler, author of the PTC, OpenPTC and TinyPTC libraries.

If you liked PTC, you’ll love PixelToaster!

for plugin support , lua , python , monkeyscript or angelscript could work really well

for examples look at http://www.angelcode.com/texgen/ of texture generation scripts ..