Re: [ocemp-devel] how to use a partial screen in renderer

On 11/9/06, Marcus von Appen <marcus@...> wrote:
> Works fine for me. The only exception is that real-to-logical mouse
> positions are not translated and some updates are not handled correctly.
> Thus offsets are calculated completely wrong and mouse handling won't
> work. Or to keep it short:
>
> It is a complete mess and has to be fixed instantly.
>
> It will work however, if you assign the Renderer the whole screen, see
> http://article.gmane.org/gmane.comp.python.pygame/7590
> for an example, which could be used as workaround.
Why don't you add an extra argument to the 'set_screen' renderer method
called 'base' or something.
If one want to use a surface instead of the mainscreen you must pass
it the coordinates to
which you want to blit the renderer surface.
.....
renderer.set_screen(surf,base=(0,500))
....
screen.blit(renderer.screen,(0,500))
....
Seems the simplest way to me.
Stas
--
We are not rich because of the things that we possess,
but for what we can do without possessing them.
-- Immanuel Kant

Thread view

Hi, another day, another question :-)
I'm using the renderer in combination with a 'normal' pygame game
in which ocempgui widgets are used in the bottom part of the screen.
I don't want to assign the whole wcreen to the renderer so I tried passing
it a pygame.Surface.
I passed the surface to the renderer and then added a table with a few buttons
and call renderer.update().
Then I call renderer.distribute_events(*events) from the eventloop to check
for mouse clicks. This works very well only that I can't show the bottons :-(
I assumed I could blit renderer.screen to my mainscreen and call display.update
but that fails as the buttons are not blitted on the surface.
I could get the sprite objects from renderer.active_layer and blit
them on the mainscreen
but I don't think that's the right way.
Any help would be appreciated.
Regards,
Stas
--
We are not rich because of the things that we possess,
but for what we can do without possessing them.
-- Immanuel Kant

On, Thu Nov 09, 2006, stas zytkiewicz wrote:
> Hi, another day, another question :-)
>
> I'm using the renderer in combination with a 'normal' pygame game
> in which ocempgui widgets are used in the bottom part of the screen.
>
> I don't want to assign the whole wcreen to the renderer so I tried passing
> it a pygame.Surface.
> I passed the surface to the renderer and then added a table with a few buttons
> and call renderer.update().
> Then I call renderer.distribute_events(*events) from the eventloop to check
> for mouse clicks. This works very well only that I can't show the bottons :-(
> I assumed I could blit renderer.screen to my mainscreen and call display.update
> but that fails as the buttons are not blitted on the surface.
Works fine for me. The only exception is that real-to-logical mouse
positions are not translated and some updates are not handled correctly.
Thus offsets are calculated completely wrong and mouse handling won't
work. Or to keep it short:
It is a complete mess and has to be fixed instantly.
It will work however, if you assign the Renderer the whole screen, see
http://article.gmane.org/gmane.comp.python.pygame/7590
for an example, which could be used as workaround.
> I could get the sprite objects from renderer.active_layer and blit
> them on the mainscreen
> but I don't think that's the right way.
At least not the way it was originally intended. I'll have to fix the
whole behaviour (the Renderer needs to know, where it resides with a
partial screen, some widgets need some cosmetics to emit updates
correctly, etc.) to get this working. This however will take some time (I
think around a week or two). If you need it as soon as possible, I surely
can send you (and/or the list) the most actual fixes I've made.
Attached you'll find a small example for partial assignments, which will
work for blitting and some updates (unfortunately not for all cases as
said above - you can see it for the Button widget).
Regards
Marcus

On 11/9/06, Marcus von Appen <marcus@...> wrote:
> work. Or to keep it short:
>
> It is a complete mess and has to be fixed instantly.
>
> It will work however, if you assign the Renderer the whole screen, see
> http://article.gmane.org/gmane.comp.python.pygame/7590
> for an example, which could be used as workaround.
If I assign the whole screen I have the problem that when a button is added
to the renderer a portion of the screen at position 0,0 is cleared?
Even when the button is set to a different position before it is added,
It's perhaps a due to the way the screen is handled in the rest of my
program but that was my reason to try to use a different surface to
separate the mainscreen and the ocempgui screen.
> > I could get the sprite objects from renderer.active_layer and blit
> > them on the mainscreen
> > but I don't think that's the right way.
>
> At least not the way it was originally intended. I'll have to fix the
> whole behaviour (the Renderer needs to know, where it resides with a
> partial screen, some widgets need some cosmetics to emit updates
> correctly, etc.) to get this working. This however will take some time (I
> think around a week or two). If you need it as soon as possible, I surely
> can send you (and/or the list) the most actual fixes I've made.
I assume you have your code in SVN/CVS? If so I will just checkout your
changes, no need to send me patches.
Besides we all have day jobs, I hope, so one or two weeks is as soon
as one could expect it :-)
> Attached you'll find a small example for partial assignments, which will
> work for blitting and some updates (unfortunately not for all cases as
> said above - you can see it for the Button widget).
Thanks. I will try your suggestions.
Regards,
Stas
--
We are not rich because of the things that we possess,
but for what we can do without possessing them.
-- Immanuel Kant

On 11/10/06, stas zytkiewicz <stas.zytkiewicz@...> wrote:
>> for mouse clicks. This works very well only that I can't show the bottons :-(
[...]
> It's perhaps a due to the way the screen is handled in the rest of my
> program but that was my reason to try to use a different surface to
> separate the mainscreen and the ocempgui screen.
After some testing I know why my 'invisible' buttons react to input,
they were blitted on the position relative to the mainscreen and then when I
refactored my code to use a surface for the renderer the buttons were blitted
outside the screen but they were perfectly placed for mouse events :-)
This is basically what you have describe as a totally mess.
None the less, I consider ocempgui the best pygame based widget set and
I hope you can fix these problems.
Regards,
Stas
BTW, I'm using ocempgui in a new project called 'schoolsplay' which will replace
the 'childsplay' project.
http://childsplay.sf.nethttp://sourceforge.net/projects/schoolsplay
--
We are not rich because of the things that we possess,
but for what we can do without possessing them.
-- Immanuel Kant

On 11/9/06, Marcus von Appen <marcus@...> wrote:
> Works fine for me. The only exception is that real-to-logical mouse
> positions are not translated and some updates are not handled correctly.
> Thus offsets are calculated completely wrong and mouse handling won't
> work. Or to keep it short:
>
> It is a complete mess and has to be fixed instantly.
>
> It will work however, if you assign the Renderer the whole screen, see
> http://article.gmane.org/gmane.comp.python.pygame/7590
> for an example, which could be used as workaround.
Why don't you add an extra argument to the 'set_screen' renderer method
called 'base' or something.
If one want to use a surface instead of the mainscreen you must pass
it the coordinates to
which you want to blit the renderer surface.
.....
renderer.set_screen(surf,base=(0,500))
....
screen.blit(renderer.screen,(0,500))
....
Seems the simplest way to me.
Stas
--
We are not rich because of the things that we possess,
but for what we can do without possessing them.
-- Immanuel Kant

On, Fri Nov 10, 2006, stas zytkiewicz wrote:
> On 11/9/06, Marcus von Appen <marcus@...> wrote:
>=20
> > Works fine for me. The only exception is that real-to-logical mouse
> > positions are not translated and some updates are not handled correctly.
> > Thus offsets are calculated completely wrong and mouse handling won't
> > work. Or to keep it short:
> >
> > It is a complete mess and has to be fixed instantly.
> >
> > It will work however, if you assign the Renderer the whole screen, see
> > http://article.gmane.org/gmane.comp.python.pygame/7590
> > for an example, which could be used as workaround.
> Why don't you add an extra argument to the 'set_screen' renderer method
> called 'base' or something.
Something like that was what I had in mind. It is also necessary to
adjust the total offsets for widget rects, so that events can be handled
correctly. And of course changing the blit position of the bound screen
has to be supported, too. If you blit it at (50, 50) instead of the
previous (30, 70), the Renderer has to be adjusted correctly with e.g.
renderer.topleft =3D 50, 50 or something like that.
BTW.: No need to CC me when posting to the list :-).
Regards
Marcus

On 11/10/06, Marcus von Appen <marcus@...> wrote:
> correctly. And of course changing the blit position of the bound screen
> has to be supported, too.
>If you blit it at (50, 50) instead of the
> previous (30, 70), the Renderer has to be adjusted correctly with e.g.
> renderer.topleft = 50, 50 or something like that.
renderer.topleft seems, to me, the best way as it resembles the way
one positions
the widgets.
> BTW.: No need to CC me when posting to the list :-).
OK, but as you had two addresses in your "From:" header I assumed you wanted
to receive replies at those two addresses :-)
Stas
--
We are not rich because of the things that we possess,
but for what we can do without possessing them.
-- Immanuel Kant

On, Thu Nov 09, 2006, Marcus von Appen wrote:
[...]
> Works fine for me. The only exception is that real-to-logical mouse
> positions are not translated and some updates are not handled correctly.
> Thus offsets are calculated completely wrong and mouse handling won't
> work. Or to keep it short:
>=20
> It is a complete mess and has to be fixed instantly.
[...]
Fixed in CVS. The Renderer now exposes a rect attribute and its
attributes (x, y, topleft, etc.) similar to the BaseWidget class. The
event handling was changed, so that mouse events are only recognized,
when they are clearly within the bounds of the rect.
An example, embedded_partial.py, was added, which shows how to use
partial screen assignments.
If there are any concerns with it, please let me know.
Regards
Marcus

On 11/15/06, Marcus von Appen <marcus@...> wrote:
> On, Thu Nov 09, 2006, Marcus von Appen wrote:
>
> [...]
> > Works fine for me. The only exception is that real-to-logical mouse
> > positions are not translated and some updates are not handled correctly.
> > Thus offsets are calculated completely wrong and mouse handling won't
> > work. Or to keep it short:
> >
> > It is a complete mess and has to be fixed instantly.
> [...]
>
> Fixed in CVS. The Renderer now exposes a rect attribute and its
> attributes (x, y, topleft, etc.) similar to the BaseWidget class. The
> event handling was changed, so that mouse events are only recognized,
> when they are clearly within the bounds of the rect.
I've checked out the latest CVS, installed it and tested it with
buttons and tables.
The renderer works very good now, I can finally use Surfaces for the
renderer :-)
The way of using Surfaces as partial screens is now consistent with
the rest of widgets, nice work.
I assume you will also release the stuff currently in CVS?
Regards,
Stas
--
We are not rich because of the things that we possess,
but for what we can do without possessing them.
-- Immanuel Kant

On, Wed Nov 15, 2006, stas zytkiewicz wrote:
[...]
> I assume you will also release the stuff currently in CVS?
Yes.
I guess within the next week a new release will be made available. The
documentation has to be synchronized with the latest changes first and I
would like to have finished my time comparisions for rendering before
that release, so that any optimizations can be shipped with it.
Regards
Marcus

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details