|
Chman
|
|
« Reply #141 on: November 21, 2008, 10:27:12 AM » |
|
Actually, this might be better : class pixel(object):
"""Contains information about a pixel""" def __init__(self, bperp = 3): """Creates a list of pixel values.""" self.bpp = bperp self.data = [] for i in xrange(0, bperp): self.data.append(0)
Couple of changes here. First, you're using the old class style, which is slower at initialization. That's why I specified an 'object' parent type ( more infos). Next, as Michael Buckley said, you're making everything static. Variables, of course, but also methods ! A non-static class method should have 'self' as the first parameter. Finally, use xrange() instead of range(), it's faster, although it won't make a difference here because you're not looping a lot There's something else you could do to improve initialization performance too (which is great for container classes used in mass like pixels, vectors, etc) : defined every class variables you'll using, so that python won't have to analyse the class to create a dict itself. How ? class pixel(object):
__slots__ = ('bpp', 'data')
"""Contains information about a pixel""" def __init__(self, bperp = 3) """Creates a list of pixel values.""" self.bpp = bperp self.data = [] for i in xrange(0, bperp): self.data.append(0)
In a case of a vector, that would be : class Vector(object):
__slots__ = ('x', 'y')
def __init__(self, x, y): self.x = x self.y = y
Oh, and something else : your pixel class will throw an error. There's a missing ':' in every methods definition. Something else you might want to take a look into : python's arrays/lists are slow as hell. Google for "numeric" or "numpy".
|
|
|
Logged
|
|
|
|
medieval
Guest
|
|
« Reply #142 on: November 21, 2008, 10:40:22 AM » |
|
I don't know if I'm right when I say this, but using OpenGL would make it incompatible with a lot of video cards.
|
|
|
Logged
|
|
|
|
nihilocrat
|
|
« Reply #143 on: November 21, 2008, 10:49:50 AM » |
|
for i in xrange(0, bperp): self.data.append(0)
Sorry for nitpicking again! This is faster: self.data = [0 for i in xrange(0, bperp)] Micro-optimizing like this isn't important, and you shouldn't bother rewriting code like this if it's not a major bottleneck, I just thought I could help you out by introducing list comprehensions. I don't know if I'm right when I say this, but using OpenGL would make it incompatible with a lot of video cards.
Frankly, I don't know what you are talking about. Every video card under the sun supports OpenGL, they are just sensitive about extensions and pixel shaders and stuff like that, and that is vastly beyond the scope of this app. I guess you could be referring to people with completely videocardless machines (pre-2000, or maybe we want to eventually port to Nintendo DS or what have you), in which case using any sort of hardware acceleration is usually not going to work or be amazingly slow, thanks to an OpenGL-via-software emulation lib like mesa. Excellent! Dr. Petter develops another niche app that is extremely useful for bedroom game developers!
|
|
« Last Edit: November 21, 2008, 11:18:12 AM by nihilocrat »
|
Logged
|
|
|
|
coderneedsfood
|
|
« Reply #144 on: November 21, 2008, 01:49:26 PM » |
|
sure but if you can't run OpenGL most games are going to fail also .. OpenGL is supported by all modern cards since 3dfx banshee i think .. most cards support it very well nowadays I don't know if I'm right when I say this, but using OpenGL would make it incompatible with a lot of video cards.
|
|
|
Logged
|
|
|
|
FoxBlitzz
|
|
« Reply #145 on: November 21, 2008, 03:20:46 PM » |
|
I'm an administrator on a forum for a Doom total conversion mod, and you'd be amazed at the amount of people who run Software mode because OpenGL doesn't work properly. Like, a lot of users are literally running old, trashed Compaqs, and OpenGL on integrated cards really doesn't work as well on Windows as it does on other systems, at least from my experience (plus, you have varying OpenGL versions that have less supported hardware with each new major release). And for an art style that practically comes from its usage on old machines, is it totally necessary to raise system requirements?
Adding to that, aren't you supposed to stick to power-of-two textures for OpenGL/Direct3D in most cases? nVidia supports it, ATI kind of supports it, and other devices are rather mixed, so wouldn't odd canvas sizes be more difficult to work with? Or perhaps I am missing something here?
About the crop tool: I guess it could probably be removed from that panel. For whatever reason, I'm just used to working with it, but it's not really that hard to make the adjustment. In a way, it's somewhat redundant...
|
|
|
Logged
|
|
|
|
nihilocrat
|
|
« Reply #146 on: November 21, 2008, 03:32:26 PM » |
|
Adding to that, aren't you supposed to stick to power-of-two textures for OpenGL/Direct3D in most cases? nVidia supports it, ATI kind of supports it, and other devices are rather mixed, so wouldn't odd canvas sizes be more difficult to work with? Or perhaps I am missing something here?
In practice, what you do is you load an image file that is a power of two and then only use a specific rectangle of it, like you would with a spritesheet. You can load non-power of two images as-is and blit the data on top of a properly-sized texture, then proceed to only use the rectangle that matches the original image. Anyhow that's sort of a moot point, your original point is completely valid. I don't see any need for using OpenGL in a pixel paint program.
|
|
« Last Edit: November 21, 2008, 03:42:20 PM by nihilocrat »
|
Logged
|
|
|
|
Bad Sector
|
|
« Reply #147 on: November 21, 2008, 03:43:07 PM » |
|
This is the last time i'm going to mention Java (for this project), but Swing (the default Java toolkit) is hardware accelerated in latest versions of the runtime and has many backends for both OpenGL and Direct3D (defaults to Direct3D in Windows and i think OpenGL in Linux - in Mac i think Cocoa is OpenGL accelerated anyway so it doesn't really matter what you use). If i leave Fraps on, i even get a framecounter in some Swing applications :-P.
|
|
|
Logged
|
~bs~
|
|
|
medieval
Guest
|
|
« Reply #148 on: November 21, 2008, 04:04:00 PM » |
|
If OpenGL runs so bad on integrated graphic cards, and this project will be built on OpenGL, I will most likely cry.
|
|
|
Logged
|
|
|
|
Agh
|
|
« Reply #149 on: November 21, 2008, 04:27:12 PM » |
|
I wouldn't use python for this. It's just too slow. If you make it create 8000 Pixel(e.g you want to make a wallpaper) it takes ~8 seconds. class pixel(object): __slots__ = ('bpp', 'data') """Contains information about a pixel""" def __init__(self, bperp = 3): """Creates a list of pixel values.""" self.bpp = bperp self.data = [] for i in xrange(0, bperp): self.data.append(0) list=[] for i in range(1000*800): list.append(pixel())
|
|
|
Logged
|
|
|
|
Gold Cray
|
|
« Reply #150 on: November 21, 2008, 05:38:35 PM » |
|
That's a good point. I've got pixelRGBA and pixelIndexed classes that inherit from a base pixel class. It probably wouldn't be too hard to convert to C++ (if I have to though, I can also do Java).
|
|
|
Logged
|
|
|
|
coderneedsfood
|
|
« Reply #151 on: November 21, 2008, 06:04:06 PM » |
|
Really all you need is Wx and SDL or Allegro , but someone was asking about python and OpenGL ,I was suggesting using Pyglet if they were going to do that .. since when does Doom support OpenGL anyway I still have the original DOS based DPaint somewhere
|
|
|
Logged
|
|
|
|
Michael Buckley
|
|
« Reply #152 on: November 21, 2008, 06:10:32 PM » |
|
Ahem... uh... or you could raise an exception, which makes it easy for any calling code to catch it. Yeah, I think that's what I get for posting at 2 AM. We could argue about error codes vs exceptions all day long, but I think in this case, it's pretty obvious that an exception would be the correct mechanism to use.
|
|
|
Logged
|
|
|
|
Gold Cray
|
|
« Reply #153 on: November 21, 2008, 07:55:54 PM » |
|
In practice, what you do is you load an image file that is a power of two and then only use a specific rectangle of it, like you would with a spritesheet. You can load non-power of two images as-is and blit the data on top of a properly-sized texture, then proceed to only use the rectangle that matches the original image.
Anyhow that's sort of a moot point, your original point is completely valid. I don't see any need for using OpenGL in a pixel paint program.
My understanding was that openGL was only going to be used for drawing the canvas to the screen and that the layer and canvas classes were going to handle the actual data. In that case, you would never need to involve openGL textures at all. Rendering with SDL would probably be faster and easier, though, because SDL already has data type for handling layers (SDL_Surface) and different pixel types, meaning several classes that we don't have to make from scratch. I imagine it can also draw a layer much more quickly than openGL can draw all the individual pixels for the layer. SDL is supported in both C++ and Python, so whichever we end up using, we can still use SDL. This way, the layer class just handles a list of SDL_Surfaces (keyframes), and the canvas class handles a list of layers.
|
|
|
Logged
|
|
|
|
team_q
|
|
« Reply #154 on: November 21, 2008, 08:32:53 PM » |
|
I just started learning SDL, its pretty interesting stuff!
|
|
|
Logged
|
|
|
|
Annabelle Kennedy
Awesomesauce
Level 8
♥Android Love♥
|
|
« Reply #155 on: November 21, 2008, 09:18:10 PM » |
|
i will vouch for the fact that loads of people have terrible, old computers.
|
|
|
Logged
|
|
|
|
Chman
|
|
« Reply #156 on: November 22, 2008, 12:10:28 AM » |
|
I wouldn't use python for this. It's just too slow. If you make it create 8000 Pixel(e.g you want to make a wallpaper) it takes ~8 seconds. Using a "Pixel" class is a design flaw. Creating a big array will be waaaay faster. The following code execution is instantaneous. from Numeric import zeros pixels = zeros((1600,1200))
I had to work with Python at work for various projects (UI frontends with GTK, game server scripting etc). If well used, it's a good language and you won't have any speed issues. Except, of course, if you're trying to create the next Crysis. Tixel is a "paint" program targeted to pixel artists, it won't matter if it's made in C++, Python or Java. I don't think people intend to use it to work on their 12Mpix photos
|
|
|
Logged
|
|
|
|
GregWS
|
|
« Reply #157 on: November 22, 2008, 12:37:10 AM » |
|
Cool to see this happening! I hadn't been here since the "would be cool if" phase! Good job guys, look forward to seeing Tixel!
|
|
|
Logged
|
|
|
|
Lazycow
|
|
« Reply #158 on: November 22, 2008, 12:53:20 AM » |
|
Tixel is a "paint" program targeted to pixel artists, it won't matter if it's made in C++, Python or Java.
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++
|
|
|
Logged
|
|
|
|
medieval
Guest
|
|
« Reply #159 on: November 22, 2008, 05:47:12 AM » |
|
i will vouch for the fact that loads of people have terrible, old computers.
|
|
|
Logged
|
|
|
|
|