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.
>>
>
>
