i have no idea. Could you?
On 20 April 2017 at 11:01, Wout B wrote:
> @DiliupG: Couldn't you use any networking library for that?
>
--
Kalasuri Diliup Gabadamudalige
https://dahamgatalu.wordpress.com/
http://soft.diliupg.com/
http://www.diliupg.com
*
On 4/20/2017 8:13:22 AM, "Greg Ewing"
wrote:
Lenard Lindstrom wrote:
However, after a bit of experimenting I find a window can have both a
renderer and a display surface.
In that case, I'd suggest the Window object should have
'renderer' and 'surface' attributes. If the Renderer or
Surfa
Thanks for the link. I had not even thought of OpenGL yet. OpenGL was
something to be tackled later.
One thing to note though, a programming choice in C may not make sense
in a higher level language such as Python. C encourages choices based on
physical data representations. Python types and o
Hi Greg,
On 17-04-19 11:06 PM, Greg Ewing wrote:
Lenard Lindstrom wrote:
Extension type WindowSurface would add an SDL window C pointer to its
pygame.Surface parent. This window pointer cannot be factored out
into a separate WindowBase parent class. And any methods which access
that pointer w
Hi Marcus,
I was certain I had read about restrictions regarding a window's surface
and a renderer. But I can't find anything in the SDL API docs.
Lenard Lindstrom
On 17-04-20 10:14 AM, Marcus von Appen wrote:
On 4/20/2017 8:13:22 AM, "Greg Ewing"
wrote:
Lenard Lindstrom wrote:
Howeve
I have integrated with Steam but using different wrapper. This looks quite
impressive. Unfortunately pygame is a raster engine and Steam overlay will
not work on raster engines according to documentation. I would love to have
overlay but i think you would have to render your game to surface in open
I think that ties in with the discussions in the other thread about
supporting SDL 2 and hardware-accelerated rendering, but I don't understand
all the relevant pieces well enough to know if that work will help with
this.
On 20 April 2017 at 21:38, Bartosz Debski wrote:
> I have integrated with
Ian Mallett wrote:
I like this idea a lot, modulo that you should also store the reference
to the window.
The Renderer would hold a reference to the window itself,
so you would only need to keep a separate reference to the
window if you wanted to use different renderers with it
at different ti
Lenard Lindstrom wrote:
Unfortunately,
the special parser machinery to support Cython includes is only
implemented at the module level. It was never generalized to work in any
code block.
The include statement in Pyrex was something of a hack that I
used for sharing declarations before the ci
On Thu, Apr 20, 2017 at 5:38 PM, Greg Ewing
wrote:
> Ian Mallett wrote:
>
>> I like this idea a lot, modulo that you should also store the reference
>> to the window.
>>
>
> The Renderer would hold a reference to the window itself,
> so you would only need to keep a separate reference to the
> w
Lenard Lindstrom wrote:
I was certain I had read about restrictions regarding a window's surface
and a renderer. But I can't find anything in the SDL API docs.
I don't know about SDL, but as far as OpenGL goes, usually
the way it works is that a context can only be bound to one
window (or part
On 17-04-20 05:32 PM, Greg Ewing wrote:
Lenard Lindstrom wrote:
Unfortunately, the special parser machinery to support Cython
includes is only implemented at the module level. It was never
generalized to work in any code block.
The include statement in Pyrex was something of a hack that I
use
On 17-04-20 05:39 PM, Greg Ewing wrote:
Lenard Lindstrom wrote:
I was certain I had read about restrictions regarding a window's
surface and a renderer. But I can't find anything in the SDL API docs.
I don't know about SDL, but as far as OpenGL goes, usually
the way it works is that a context
13 matches
Mail list logo
