Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411276 Posts in 69323 Topics- by 58380 Members - Latest Member: bob1029

March 28, 2024, 11:15:59 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsJobsCollaborationsTixel - Now Hiring!
Pages: 1 ... 5 6 [7] 8 9 ... 14
Print
Author Topic: Tixel - Now Hiring!  (Read 72860 times)
Gold Cray
Level 10
*****


Gold Cray


View Profile WWW
« Reply #120 on: November 20, 2008, 06:28:35 PM »

I would prefer C++ since it's faster than either one, but at the same time I don't know of any good cross-platform GUI libraries for it. I'll be glad to contribute what I can in either Python or Java (or whichever language the project ends up in).
Logged
increpare
Guest
« Reply #121 on: November 20, 2008, 06:45:14 PM »

I would prefer C++ since it's faster than either one, but at the same time I don't know of any good cross-platform GUI libraries for it.
wxWidgets, QT, GTK, &c.

Performance shouldn't be an issue for a pixelling program at all, though.  I'd love to contribute to this project, but...yeah...time...:/
Logged
Michael Buckley
Level 0
***



View Profile
« Reply #122 on: November 20, 2008, 07:00:12 PM »

No, Apple does the JVM for OS X. HotSpot's only supported platforms are Windows, Linux and Solaris. Gosling admits so in a few of his blog posts:

http://blogs.sun.com/jag/entry/how_do_i_run_tiger
Quote
There have been a few questions on various blogs/forums asking how I run Tiger (J2SE 5.0), given that I use Mac OS X rather than a PC. Well.... I have a linux box and I use the X support on OS X. My linux box is out on the open internet and generally accessible via SSH tunnel

[...]

Several folks have asked if I get magic code drops from Apple. No. I shiver out in the cold like everyone else.

http://blogs.sun.com/jag/entry/solaris_and_os_x_continued
Quote
Lots of folks ask "why doesn't sun just do the JDK for Mac?". The real answer is "because Apple wanted to do it". They've wanted to do all sorts of customization and integration that only they could do - because they own the OS.

The rub is that they do base their VM off HotSpot, but the standard library is written by Apple. A few of the optimizations were removed historically since they had to support PPC, and quite a bit of HotSpot is written in x86 assembly. I don't know if they've added those back in. Similarly, a lot of the standard library does not contain many of the optimizations as in Sun's JDK.

Because of this, you have some weirdness, especially with graphics/GUI classes. For example, the default background color for Canvas and co. is pinstripe.

The real killer of Java on OS X is memory. Instances of objects take much more memory than they should. Combined with the fact that OS X allocates memory very aggressively, you can't even run Azureus/Vuze well on a machine with 512 MB of RAM. (Well, OK, you might be able to if you didn't run anything else during that time, but I never tried that back when I use Azureus. The only other thing I had running was a browser though.)

Basically, Any large program written in Java is going to eat up memory, and in turn, lead to extensive swapping.

Apple does not make their own version of Python, but they do contribute patches to the interpreter, and ship a version with OS X that includes those patches. When new versions of Python come out, users on OS X can compile the new version with or without the patches, though unlike the differences in Java, these seem to help the Python experience on OS X. (e.g., the un-patched version uses X11 instead of OS X's built-in window manager). And again, Apple included a Python<->Objective-C bridge in the newest release of OS X, and removed the Java<->Objective-C bridge. Although the people who are working on Java at Apple may have their hearts in the right place, the language is obviously bottom priority at the company.

I've been writing cross-platform code on OS X for years. Basically, the best options are C/C++ and Python. I've been writing in C/C++ because it's what I do, but I think Python really would be the best language for something like this. It's faster to write and easier to debug than C++, and its performance should not be an issue, as Python is not the memory hog that Java is on OS X, and performance is not a huge issue with something like this.

Again though, It should be up to whoever does the bulk of the programming to decide the language.
Logged
kyn
Level 10
*****


View Profile WWW
« Reply #123 on: November 20, 2008, 07:01:25 PM »

And here I thought the logo was going to be a bit more pixely

Here's my approach

Logged
FoxBlitzz
Level 0
***


Watch out! Bad Klik & Play graphics!


View Profile
« Reply #124 on: November 20, 2008, 07:07:25 PM »

In general, I'd prefer an application with few dependencies, that is of portable nature (meaning, you can stick it on a flash drive and run it off that when you plug it into another machine). Java doesn't really sound like it'd work too well in this instance. Python might work, but I have no idea how exactly the distribution would happen. Every time I encounter another program that runs on Python, it uses a completely different installation method - I swear! Either the program includes Python in the installer, is converted to C code and then compiled, or turned into .pyc files and run through an executable that in turn uses DLL files for the Python runtime, or... honestly, I haven't a clue. If anyone knows of a Python application distribution method that will keep the program portable, please sing out. C++ should work fine, but would anyone be willing to work in that language?

Also, OpenGL? Why? Wouldn't software rendering be, like, ten times simpler and compatible with 99% of computers? I don't want to stick this thing on my aging laptop and find that I can't use it due to screen corruption or the fact that it simply crashes on start-up due to the integrated graphics not supporting it, or just running slow period...
Logged
Bad Sector
Level 3
***


View Profile WWW
« Reply #125 on: November 20, 2008, 07:19:59 PM »

@FoxBlitzz:
You can bundle the VM with the program (the same thing needs to be done with Python and other interpreted languages) and make a launcher program in C that uses this VM to run it instead of a global VM. This is what people who don't want to use the global VM do. Of course this is only the case with Windows systems since Mac systems have Java preinstalled and Linux systems are usually used by people who know how to install the Java VM without breaking anything.
Logged

~bs~
Michael Buckley
Level 0
***



View Profile
« Reply #126 on: November 20, 2008, 07:48:31 PM »

In general, I'd prefer an application with few dependencies, that is of portable nature (meaning, you can stick it on a flash drive and run it off that when you plug it into another machine). Java doesn't really sound like it'd work too well in this instance. Python might work, but I have no idea how exactly the distribution would happen. Every time I encounter another program that runs on Python, it uses a completely different installation method - I swear! Either the program includes Python in the installer, is converted to C code and then compiled, or turned into .pyc files and run through an executable that in turn uses DLL files for the Python runtime, or... honestly, I haven't a clue. If anyone knows of a Python application distribution method that will keep the program portable, please sing out. C++ should work fine, but would anyone be willing to work in that language?

For Windows, there's Py2Exe, on OS X, there's Py2App, and *nix, guys will either install from source or use a package manager. Both Py2Exe and Py2App will allow the application to run on their respective systems without any external dependencies.

Also, OpenGL? Why? Wouldn't software rendering be, like, ten times simpler and compatible with 99% of computers? I don't want to stick this thing on my aging laptop and find that I can't use it due to screen corruption or the fact that it simply crashes on start-up due to the integrated graphics not supporting it, or just running slow period...

Sorry, that was in the rough draft from when I was discussing OpenGL vs Cocoa rendering. I forgot to take it out.

EDIT: I'm not opposed to C++, especially since people here, including myself, seem to be more familiar with it. Python was just a suggestion based on the fact that it had a quicker development time for a project that may not hold enough interest.
« Last Edit: November 20, 2008, 08:03:55 PM by Michael Buckley » Logged
FoxBlitzz
Level 0
***


Watch out! Bad Klik & Play graphics!


View Profile
« Reply #127 on: November 20, 2008, 08:00:20 PM »

While I'd rather have C++ for something like a game, this is just a simple GUI application, and if you would prefer using Python, that's okay as long as it can plopped onto a removable drive. If it'll get the thing done faster, then that would probably be preferable in this instance. My main worry with this program is that with all these feature suggestions, it will take forever to implement everything. As you suggested, Python might work better for that.
Logged
sereneworx
Level 10
*****


What a terrific duvet!


View Profile WWW
« Reply #128 on: November 20, 2008, 09:50:46 PM »

And here I thought the logo was going to be a bit more pixely

Here's my approach



Awesome.
Logged
FoxBlitzz
Level 0
***


Watch out! Bad Klik & Play graphics!


View Profile
« Reply #129 on: November 20, 2008, 09:55:22 PM »

Hmm, I wonder how that particular logo would look with color variation? Like, the X as a different color? I'm sorta merging ideas here between different logos.
Logged
sereneworx
Level 10
*****


What a terrific duvet!


View Profile WWW
« Reply #130 on: November 20, 2008, 09:57:18 PM »

I suggest, as with the other logos, changing the TI and EL to a dark grey. Makes for great contrast.
Logged
Gold Cray
Level 10
*****


Gold Cray


View Profile WWW
« Reply #131 on: November 20, 2008, 10:35:33 PM »

I've started learning Python and I can see how it would make for quick development. I'm currently working on a pixel class and a layer class. Since I'm new to this language, though, I might be going about it all wrong and I'm also afraid I might be getting too general with the pixel class in all the wrong areas.

Here's what my code looks like so far. I'll gladly take suggestions from people more experienced with the language.

Code:
class pixel:
    """Contains information about a pixel"""
    def __init__(bperp = 3)
        """Creates a list of pixel values."""
        bpp = bperp
        for i in range(0, bperp):
           data.append(0)
    def get(index)
        """Returns part of the value of the pixel."""
        if index < 0 or index >= bpp:
            return -1
        return data[index]
    def get()
        """Returns the whole pixel."""
        return data
    def set(value, index)
        """Sets part of the pixel to the given value."""
        if index < 0 or index >= bpp:
            return -1
        data[index] = value
        return 0
    def set(*values)
         """Sets the whole pixel to the given values."""
         if values.length() != bpp
             return -1
         for i in range(0, bpp)
             data[i] = values[i]

class layer:
    """Manages pixel data for each layer.
   
    The layer class contains its dimensions, type of pixels, and an array of pixels as well as functions
    for retrieving and manipulating those properties.
    """
    def __init__(w, h, bperp = 3):
        """Sets width and height according to input, sets bpp to 3, and initializes the list of pixels."""
        width = w
        height = h
        bbp = bperp
        for i in range(0, w*h*bpp):
            temp = pixel(bpp)
            pixels.append(temp)
    def drawPixel(x, y, r, g, b):
        """Draws an rgb pixel at (x, y)."""
        if x < 0 or x >= width:
            return -1
        if y < 0 or y >= height:
            return -1
        pixels[bpp*(y*width+x)].set([r, g, b])
        return 0
    def get(x, y)
        """Returns the pixel at x, y."""
        if x < 0 or x >= width:
            return -1
        if y < 0 or y >= height:
            return -1
        return pixels[bpp*(y*width+x)]
Logged
Michael Buckley
Level 0
***



View Profile
« Reply #132 on: November 21, 2008, 12:16:42 AM »

I think you're definitely heading in the right direction language-wise, and it's good that you're using Docstrings to provide documentation. However, instead of returning -1 on an error, you might want to look into returning None, which is more or less the python equivalent to NULL. Yes, even when you're returning primitive types Everything in Python is an object.

The only real blunder you're making is that data is being declared as a static member of the class. instead of data, it should be self.data. You might also want to declare it as private by prefixing it with two underscores, like so:

Code:
def __init__(bperp = 3)
    self.__data = []
    ...

Anywhere else in the class that you access the variable, you should also refer to it as self.__data

However, I'd look a little more into the design of your pixel class. While on the surface it looks rather generic, there are a few cases, notably 16-bit color. Whether you're using RGB 555 or RGB 565, the green is going to be spread across the two bytes. Instead, I would define a Pixel base class, with a RGBAPixel and an IndexedPixel subclass. The RGBAPixel should have accessors for its r, g, b, and a components, and the IndexedPixel would have accessors for its index.
Logged
Corpus
Guest
« Reply #133 on: November 21, 2008, 12:52:10 AM »

Oh, I forgot. I knocked together some quick logo ideas a few nights ago. I'll post them when I get home. And also those mac program screenshots I was talking about.
Logged
Decipher
Guest
« Reply #134 on: November 21, 2008, 01:09:00 AM »

Tixel sounds interesting to me, though even if I don't have enough time and energy for being 100% active, I too would like to contribute whenever possible. So, are there any attempts for repository, project site and as such?

I might host an SVN repository, a bug-tracking tool of your choice and the project site along with whatever you want, if needed.
Logged
Loren Schmidt
Level 10
*****



View Profile WWW
« Reply #135 on: November 21, 2008, 01:45:03 AM »

It's good to see progress start on the programming. This seems like it has the potential to be a really useful tool for game development enthusiasts.

Pie menus-
I used to hate them, but I've been converted. Another benefit of using pie menus is that users memorize the locations of commands more easily than when they are arranged in a line.

Sereneworx- I miss the magenta too.

I also question the usefulness of the line, ellipse, rectangle, crop, and paintbucket tools. I think ellipses are largely useless, rectangles should be created with rectangular selection + fill, and the paintbucket should likewise be magic wand + fill.
A pox on Firefox 3 applying bilinear smoothing to everything.
I think it's already been mentioned, but I agree that the amount of mouse movement needs to be reduced as much as possible. With the paint buck, you move to the tool bar, then move back to the canvas and you're done. With magic wand + fill, you move to the tool bar, move back to the canvas to select, move back to the tool bar, and then move back to the canvas to fill.
Yeah, the Photoshop / GIMP approach of combining tools really doesn't make sense when using the mouse exclusively. Reducing it to a smaller number of more flexible tools is, however, a lot cleaner when a user uses the tool hotkeys exclusively.

Using hotkeys, a line doesn't even require a tool switch, it's just modifier + drag. A rectangle is select tool shorcut, drag, fill shorcut. Once you're used to it, it's preferable to having all the extra specialized tools.

I think this is one of those cases where the optimal solution depends on a user's style and familiarity with the program.

I also think that the line tool is useful to reduce the amount of time spent calculating and rasterizing slope. Ellipse is a similar case.
I think we're on the same page here... I'm just proposing that the line tool be part of the brush tool, rather than separate. On a subjective note, I find hand-pixelling ellipses works better. Automatic ellipses tend to make some aliasing choices which, while correct, don't read well. maybe that's just me being a control freak Smiley

I think the ellipse / elliptical selection tool is a case of an overly specialized tool that made sense for high resolution art, but doesn't when working on pixel art.

As for crop, I've never missed it in paint, but I think it could be useful as a shortcut or a menu item just because it's faster to select and area and crop than it is to move the whole image and then resize the canvas.
I agree with this- the crop tool always seemed clunkier to me than dragging out a selection and using Edit > Crop. This is probably a command that beginners won't want to be burdened with, and should only exist in the menus.

Logged
kyn
Level 10
*****


View Profile WWW
« Reply #136 on: November 21, 2008, 05:45:48 AM »

I suggest, as with the other logos, changing the TI and EL to a dark grey. Makes for great contrast.
Good suggestion.





Well, it's not exactly grey, but I think it sells
Logged
nihilocrat
Level 10
*****


Full of stars.


View Profile WWW
« Reply #137 on: November 21, 2008, 06:06:57 AM »

However, instead of returning -1 on an error, you might want to look into returning None, which is more or less the python equivalent to NULL. Yes, even when you're returning primitive types Everything in Python is an object.

Ahem... uh... or you could raise an exception, which makes it easy for any calling code to catch it.

Good to see you are going with Python, I made an app in wxPython a few years ago, and code in Python every day at work. I would be completely stoked about working on this project if I could get a very clear idea of the design from others. I'm not an artist, so I don't have a clear idea of what would best help out a pixel artist. I'd also rather not try to code a bunch of peoples' competing designs.

I can't contribute a massive amount of time, but I am always willing to do code reviews and such.

edit: Check out this, as well: http://www.eglug.org/gimpixel
« Last Edit: November 21, 2008, 06:28:27 AM by nihilocrat » Logged

Gold Cray
Level 10
*****


Gold Cray


View Profile WWW
« Reply #138 on: November 21, 2008, 07:28:03 AM »

The only real blunder you're making is that data is being declared as a static member of the class. instead of data, it should be self.data. You might also want to declare it as private by prefixing it with two underscores, like so:

Code:
def __init__(bperp = 3)
    self.__data = []
    ...

Anywhere else in the class that you access the variable, you should also refer to it as self.__data

However, I'd look a little more into the design of your pixel class. While on the surface it looks rather generic, there are a few cases, notably 16-bit color. Whether you're using RGB 555 or RGB 565, the green is going to be spread across the two bytes. Instead, I would define a Pixel base class, with a RGBAPixel and an IndexedPixel subclass. The RGBAPixel should have accessors for its r, g, b, and a components, and the IndexedPixel would have accessors for its index.
Ahem... uh... or you could raise an exception, which makes it easy for any calling code to catch it.
Thanks for the advice. I'll work on revising what I have this weekend if I can find the time.
Logged
michael
Pixelhead
Level 10
******


yo


View Profile WWW
« Reply #139 on: November 21, 2008, 09:31:28 AM »

i love you guys so much
Logged

you rob the bank, i'll rob stewart
Pages: 1 ... 5 6 [7] 8 9 ... 14
Print
Jump to:  

Theme orange-lt created by panic