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 <noel.garw...@gmail.com> 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) && <I'm not sure what a > 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 <onp...@gmail.com> 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. >> > >
