Re: [Adonthell-devel] py-wrappers and rpath

[Kai Sterker]

2011/8/11 Michał Kaliński <address@hidden>:

> I've recently tried to run python tests from src/test and found out
> that they can't find the libraries. Looking at
> src/py-wrappers/adonthell/CMakeLists.txt I found out that
> INSTALL_RPATH for the wrappers is set to ${LIB_INSTALL_RPATH}, but
> that variable is not defined anywhere, which results in empty rpath.
> The standard cmake variable for setting rpath is CMAKE_INSTALL_RPATH.
> Is there any reason why it is not used?

Probably just ignorance.

> Anyway, I've added those lines to CMakeLists.txt:73
> ----
> # the RPATH to be used when installing, but only if it's not a system 
> directory
> LIST(FIND CMAKE_PLATFORM_IMPLICIT_LINK_DIRECTORIES
> "${CMAKE_INSTALL_PREFIX}/lib" isSystemDir)
> IF("${isSystemDir}" STREQUAL "-1")
>        SET(LIB_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
> ENDIF("${isSystemDir}" STREQUAL "-1")
> ----
> which I simply copied from cmake's wiki, and it works fine. I haven't
> looked into autotools yet, I'll commit when I've done it.

Great!


> As for the gui stuff, I'm don't really feel qualified to design it,
> but I wanted to check the wrappers. But I've found that most of the
> python tests don't work because they call nonexistent methods from the
> wrapped modules. For example, guitest.py wants to create an instance
> of gui.container, but dir(gui) doesn't show anything named so, and
> guitest.cc (which works) uses completely different objects. You
> mentioned that the c++ implementation is outdated (and the latest font
> tweaking broke it for me) and that it should be implemented on the
> python side. What exactly is to be done?

The idea for the GUI is to have the low-level stuff (widgets, "window"
manager, input) implemented on C++ side. This is nearly complete.
We're lacking a grid layout type widget, and the API may need changes
to make stuff more comfortable to use. Mouse support is also missing,
but I see that as less critical as we're targetting keyboard/gamepad
control in the first place.

The actual user interface (stuff like main menu, load/save screen,
inventory, etc.) should be written in Python, so it can be more easily
adapted for different games. Therefore, I consider the dialogue widget
(conversation.cpp) as outdated because it should live on Python side.
The rest is okay.


Now, from the GUI test code, only guitest.cc is up-to-date. The python
counterpart hasn't been touched in a very very long time.

As for what is left to do: I could put together some designs and specs
for things over the weekend. Until that is done, looking into the
collision stuff would also be worthwile:

> Also, the collision detection is really wonky at the moment - the
> character slides down on stairs (even though the task of making stairs
> climbable is marked as done), it's possible to climb walls by jumping
> against them, etc. I could try fixing that next.

Yes, that would be quite useful. For the sliding (which also happens
on sloped ground, btw.), introducing friction somewhere in the
collision code could help. For the wall climbing, we'd need additional
checks whether jumping is allowed from the current position or not.
Right now it only checks if vertical velocity is zero (I believe), so
there are enough loopholes for actions that should be impossible.

Kai