Re: [pygame] Alternate to graphics modules
Hi, Elias. Just condensing all the responses. It seems if you want to do it all in Python without requiring third-party modules or libraries, the best answers is write your own interface to OpenGL. You may not have to write everything from scratch. Take a look at pyglet's OpenGL bindings, they are completely in Python. And pyglet has a liberal license which IIRC allows copying and modifying (be sure to read the license and use your own judgement). The main reason I think this is your only option is because, wherever you find a modern video card you are likely to find OpenGL already installed. You can use other libraries, and I daresay you'd find them a lot easier to learn and use, but these others are not already installed. Hope this helps your pursuit. Gumm On Fri, Feb 8, 2013 at 6:11 AM, Noel Garwick wrote: > True. Still, some might see a distinction between the compiler taking > code that a human has made, breaking it down and optimizing the calls into > operations, and then assembling that vs. using python to make calls to > functions written in python that call functions that someone else has > written in C. > > Of course, all of this is just academic (vaguely :p). The cool thing > about this thread is that Elias' request was not met with "use C, n00b", "> > suggesting python should be used for low level ops..", or even just > silence. Instead, pygame-users explained the logical issues with the > request (that the OP likely wasn't aware of), and explained why the request > becomes more of a question of semantics than anything else. As well, they > offered suggestions for what could qualify as the next closest method to > fulfill that request. That is cool. > > But yeah: If you want to use python's syntax to work with low-level > graphics calls, the modules with low-level bindings can offer a pretty > direct 'middle man.' If you want to write C to use the libraries those > wrap directly, that's a possibility (and not as hard as it looks at first.) > Or if you really want to get into it (mostly just useful for education, > but we wouldn't be here if pedagogy wasn't of some interest), try out some > assembly. You will need to emulate an older set of hardware, since as far > as I'm aware things like 0x13h mode don't exist anymore, and as far as I > know most APIs to directly access a graphics card are going to be in C (if > I'm mistaken here, someone please correct me.) > > If your overall goal is to get a better understanding of how graphics and > programming in general work, doing a small project in each of these > languages in order could be pretty enlightening (this is how it 'clicked' > for me, at least) -- tutorial links included: > > 1. Pygame ["Okay, so I take input, then I update the values from that > input, and then I draw.. I guess that's easy enough?] > http://inventwithpython.com/ > > 2. 6502 Assembly (NES) [Registers, memory management, reading/writing to > ports/specific addresses, what loops, containers, and other things we take > for granted actually look like, etc.] > http://www.nintendoage.com/pub/faq/NA/nerdy_nights_out.html > > 3. C [Working directly with C and SDL or OpenGL calls] > http://www.lazyfoo.net/SDL_tutorials/ (SDL) && solid, modern opengl tutorial would be; can anyone provide a link? :p> > > 4. C/Pygame ["Now that I understand how all that boilerplate works, I can > feel comfortable using 'shortcuts', since I see the benefits they really > offer (so now the only benefit of rolling my own is going to be '..just > 'cause' 95% of the time), and can foresee/avoid the things that could cause > bottlenecks. Or I can use C since I want to experiment with designing more > complex 3d shaders, physics, etc. Or just because I think it's fun to use > C."] > > [Sorry for the wall of text; hopefully it's helpful] > > > > On Thu, Feb 7, 2013 at 11:20 PM, Julian wrote: > >> On 02/07/2013 10:06 PM, Ian Mallett wrote: >> >>> The point is that you need to go through some kind of middle layer. >>> Python code, by definition, does not interface directly with anything--you >>> must go through some library/package--whether it is a built-in within >>> Python's runtime, a 3rd-party distribution, or a wrapper you make around >>> existing C functionality. >>> >> >> Well, if you want to get really technical, only machine code interfaces >> directly with anything. C abstracts this so your code can work on more than >> one type of processor. Even assembly languages abstract a little bit, if >> I'm not mistaken, though it's pretty direct. >> > >
Re: [pygame] Alternate to graphics modules
True. Still, some might see a distinction between the compiler taking code that a human has made, breaking it down and optimizing the calls into operations, and then assembling that vs. using python to make calls to functions written in python that call functions that someone else has written in C. Of course, all of this is just academic (vaguely :p). The cool thing about this thread is that Elias' request was not met with "use C, n00b", "> suggesting python should be used for low level ops..", or even just silence. Instead, pygame-users explained the logical issues with the request (that the OP likely wasn't aware of), and explained why the request becomes more of a question of semantics than anything else. As well, they offered suggestions for what could qualify as the next closest method to fulfill that request. That is cool. But yeah: If you want to use python's syntax to work with low-level graphics calls, the modules with low-level bindings can offer a pretty direct 'middle man.' If you want to write C to use the libraries those wrap directly, that's a possibility (and not as hard as it looks at first.) Or if you really want to get into it (mostly just useful for education, but we wouldn't be here if pedagogy wasn't of some interest), try out some assembly. You will need to emulate an older set of hardware, since as far as I'm aware things like 0x13h mode don't exist anymore, and as far as I know most APIs to directly access a graphics card are going to be in C (if I'm mistaken here, someone please correct me.) If your overall goal is to get a better understanding of how graphics and programming in general work, doing a small project in each of these languages in order could be pretty enlightening (this is how it 'clicked' for me, at least) -- tutorial links included: 1. Pygame ["Okay, so I take input, then I update the values from that input, and then I draw.. I guess that's easy enough?] http://inventwithpython.com/ 2. 6502 Assembly (NES) [Registers, memory management, reading/writing to ports/specific addresses, what loops, containers, and other things we take for granted actually look like, etc.] http://www.nintendoage.com/pub/faq/NA/nerdy_nights_out.html 3. C [Working directly with C and SDL or OpenGL calls] http://www.lazyfoo.net/SDL_tutorials/ (SDL) && 4. C/Pygame ["Now that I understand how all that boilerplate works, I can feel comfortable using 'shortcuts', since I see the benefits they really offer (so now the only benefit of rolling my own is going to be '..just 'cause' 95% of the time), and can foresee/avoid the things that could cause bottlenecks. Or I can use C since I want to experiment with designing more complex 3d shaders, physics, etc. Or just because I think it's fun to use C."] [Sorry for the wall of text; hopefully it's helpful] On Thu, Feb 7, 2013 at 11:20 PM, Julian wrote: > On 02/07/2013 10:06 PM, Ian Mallett wrote: > >> The point is that you need to go through some kind of middle layer. >> Python code, by definition, does not interface directly with anything--you >> must go through some library/package--whether it is a built-in within >> Python's runtime, a 3rd-party distribution, or a wrapper you make around >> existing C functionality. >> > > Well, if you want to get really technical, only machine code interfaces > directly with anything. C abstracts this so your code can work on more than > one type of processor. Even assembly languages abstract a little bit, if > I'm not mistaken, though it's pretty direct. >
Re: [pygame] Alternate to graphics modules
On 02/07/2013 10:06 PM, Ian Mallett wrote: The point is that you need to go through some kind of middle layer. Python code, by definition, does not interface directly with anything--you must go through some library/package--whether it is a built-in within Python's runtime, a 3rd-party distribution, or a wrapper you make around existing C functionality. Well, if you want to get really technical, only machine code interfaces directly with anything. C abstracts this so your code can work on more than one type of processor. Even assembly languages abstract a little bit, if I'm not mistaken, though it's pretty direct.
Re: [pygame] Alternate to graphics modules
On Thu, Feb 7, 2013 at 5:29 PM, Greg Ewing wrote: > Ian Mallett wrote: > >> At some level, you need to interface with the graphics drivers. Since >> Python is an abstraction layer over C, this means either writing in C (not >> Python), or using a package that does that for you. >> > > Not necessarily -- you can use ctypes to wrap a C library. > Yes. In this case, you're creating your own package. The point is that you need to go through some kind of middle layer. Python code, by definition, does not interface directly with anything--you must go through some library/package--whether it is a built-in within Python's runtime, a 3rd-party distribution, or a wrapper you make around existing C functionality. Ian
Re: [pygame] Alternate to graphics modules
Ian Mallett wrote: At some level, you need to interface with the graphics drivers. Since Python is an abstraction layer over C, this means either writing in C (not Python), or using a package that does that for you. Not necessarily -- you can use ctypes to wrap a C library. -- Greg
Re: [pygame] Alternate to graphics modules
On 13-02-06 06:43 PM, Richard Jones wrote: On 7 February 2013 10:29, Ian Mallett wrote: On Wed, Feb 6, 2013 at 4:20 PM, Richard Jones wrote: You'd better start writing then :-) At some level, you need to interface with the graphics drivers. Since Python is an abstraction layer over C, this means either writing in C (not Python), or using a package that does that for you. You must use some package in Python to do low-level graphics--whether you write it yourself or no. For a package that gives you low-level access, my recommendation is PyOpenGL. It's lower-level than PyGlet and much cleaner, I think. That's not quite right. PyOpenGL and pyglet exist at about the same level architecturally. PyOpenGL does not provide an OpenGL context - you need another library (like pyglet or pygame) to provide that. Minor note: PyOpenGL does provide an OpenGL context (via GLUT), it's just not a very elegant or modern one :) . It *can* work with almost any external GUI library as well, but for demos/learning GLUT is often acceptable. Have fun, Mike -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com
Re: [pygame] Alternate to graphics modules
On Wed, Feb 6, 2013 at 4:43 PM, Richard Jones wrote: > > For a package that gives you low-level access, my recommendation is > > PyOpenGL. It's lower-level than PyGlet and much cleaner, I think. > > That's not quite right. PyOpenGL and pyglet exist at about the same > level architecturally. PyOpenGL does not provide an OpenGL context - > you need another library (like pyglet or pygame) to provide that. > While I have not used PyGlet extensively, that is not my impression. PyGlet, for example, provides a dedicated shader class, and an entire rendering backend. I do recall that there is some direct exposure of some OpenGL calls (particularly OpenGL 2 callbacks), but by and large I have seen PyGlet applications that do not touch a single line of GL. Conversely, PyOpenGL is a "binding" of raw OpenGL, with facilities for extensions. You will need to use these OpenGL calls to accomplish anything. There are a few helper classes (e.g. for VBOs), but the most complicated thing it provides IIRC is a testing framework. At any rate, I feel like PyGlet is a binding on top of OpenGL, but it's not meant to be used that way. While you can make direct GL callbacks, PyGlet encourages the use of their abstracting classes built on top of it. Whereas, PyOpenGL is just a binding, with maybe a few higher level classes added on top of it for convenience. Ian
Re: [pygame] Alternate to graphics modules
On 7 February 2013 10:29, Ian Mallett wrote: > On Wed, Feb 6, 2013 at 4:20 PM, Richard Jones > wrote: >> >> You'd better start writing then :-) > > At some level, you need to interface with the graphics drivers. Since Python > is an abstraction layer over C, this means either writing in C (not Python), > or using a package that does that for you. You must use some package in > Python to do low-level graphics--whether you write it yourself or no. > > For a package that gives you low-level access, my recommendation is > PyOpenGL. It's lower-level than PyGlet and much cleaner, I think. That's not quite right. PyOpenGL and pyglet exist at about the same level architecturally. PyOpenGL does not provide an OpenGL context - you need another library (like pyglet or pygame) to provide that. Richard
Re: [pygame] Alternate to graphics modules
That kind of answer is what I wanted. Thank you! On Wed, Feb 6, 2013 at 3:29 PM, Ian Mallett wrote: > On Wed, Feb 6, 2013 at 4:20 PM, Richard Jones wrote: > >> You'd better start writing then :-) >> > At some level, you need to interface with the graphics drivers. Since > Python is an abstraction layer over C, this means either writing in C (not > Python), or using a package that does that for you. You *must* use some > package in Python to do low-level graphics--whether you write it yourself > or no. > > For a *package* that gives you low-level access, my recommendation is > PyOpenGL. It's lower-level than PyGlet and much cleaner, I think. > > Ian > -- "The validity of internet quotes are getting sketchy nowadays" -Abraham Lincoln
Re: [pygame] Alternate to graphics modules
On Wed, Feb 6, 2013 at 4:20 PM, Richard Jones wrote: > You'd better start writing then :-) > At some level, you need to interface with the graphics drivers. Since Python is an abstraction layer over C, this means either writing in C (not Python), or using a package that does that for you. You *must* use some package in Python to do low-level graphics--whether you write it yourself or no. For a *package* that gives you low-level access, my recommendation is PyOpenGL. It's lower-level than PyGlet and much cleaner, I think. Ian
Re: [pygame] Alternate to graphics modules
You'd better start writing then :-) On 7 February 2013 10:19, Elias Benevedes wrote: > Not to be picky, but I want to do it completely without internet installed > modules. > > > On Wed, Feb 6, 2013 at 3:17 PM, Julian wrote: >> >> On 02/06/2013 06:12 PM, Elias Benevedes wrote: >>> >>> There must be a way to write it in pure python code for the fact that >>> pygame uses python (I assume?). >> >> Pygame does not use Python for the low-level stuff. It's mostly a >> front-end for SDL, which is in C. >> >> Like Richard suggested, try Pyglet. That is written entirely in Python >> (and that's a really nice thing, because that means it works with PyPy). > > > > > -- > "The validity of internet quotes are getting sketchy nowadays" > -Abraham Lincoln
Re: [pygame] Alternate to graphics modules
Not to be picky, but I want to do it completely without internet installed modules. On Wed, Feb 6, 2013 at 3:17 PM, Julian wrote: > On 02/06/2013 06:12 PM, Elias Benevedes wrote: > >> There must be a way to write it in pure python code for the fact that >> pygame uses python (I assume?). >> > Pygame does not use Python for the low-level stuff. It's mostly a > front-end for SDL, which is in C. > > Like Richard suggested, try Pyglet. That is written entirely in Python > (and that's a really nice thing, because that means it works with PyPy). > -- "The validity of internet quotes are getting sketchy nowadays" -Abraham Lincoln
Re: [pygame] Alternate to graphics modules
On 02/06/2013 06:12 PM, Elias Benevedes wrote: There must be a way to write it in pure python code for the fact that pygame uses python (I assume?). Pygame does not use Python for the low-level stuff. It's mostly a front-end for SDL, which is in C. Like Richard suggested, try Pyglet. That is written entirely in Python (and that's a really nice thing, because that means it works with PyPy).
Re: [pygame] Alternate to graphics modules
On 7 February 2013 10:12, Elias Benevedes wrote: > I've just been wondering lately. I want to not use pygame, or any other > modules for controlling graphics. There must be a way to write it in pure > python code for the fact that pygame uses python (I assume?). Have any of > you came across a tutorial for low level graphics programming with python? Consider pyglet.
