For fun, I tried manually stripping the GL libraries from Pyglet and adding
the needed lines back in again by hand -- essentially, a brute-force
implementation of what I was describing here. It didn't take long to add
back in all the needed instructions to get my application running -- maybe
Addendum: I found that another 2-3 MB can be saved by stripping the
constants in the win32 library as well. Again, not something I'd recommend
while you're actually developing an app! But it does seem to work.
--
You received this message because you are subscribed to the Google Groups
That sounds really cool. I'm not very familiar with OpenAL, but would love
to play around with those effects.
I was looking at that message at the top of lib_openal.py about why
alSource3i is commented out to begin with. OSX 10.4 is over seven years out
of support at this point, so maybe that
That's a pretty significant memory savings. I'll have to give this a try. A
pyglet app usually takes about 32MB on my (Linux) system, but now I'm
curious what it can get down to.
On Wednesday, August 31, 2016 at 9:47:25 AM UTC+9, Serdar Yegulalp wrote:
>
> Addendum: I found that another 2-3
In what way are you blending objects? The source of that issue could be a
number of things, could you provide a working example? Generally you should
only have to update each visible objects vertices and Z axis every update
cycle.
Also, you can increase the depth range of the Z axis by setting
I have been working on something for a while now and have been trying to
figure out a layered order properly. I have searched these forums for
recommendations and read numerous articles but none of the proposed
solutions have worked out.
Basically I want a layered order based on the Y value