[Adonthell-devel] Fallout from inttypes.h

[Kai Sterker]

Just FYI,

looks like the change in base/types.h (which was absolutely necessary,
IMO) broke more things than the bit we had discovered yesterday.

For one, I got a linker error for the gfx module when building today
at work using mingw. I found it strange, but assumed my environment
got broken somehow. In the evening, however, I got a similar linker
error when running worldtest and the _gfx.so module would not load.
(The difference is that Windows-DLLs cannot have unresolved symbols,
so the build failed. Linux or Mac shared libs may contain unresolved
symbols, but then things fall apart when actually running the app).
Anyway, a fix for screen.h/screen.cc is in place that resolved the
issues on the Mac ... have to check tomorrow if it worked for win32.


The other issue, after worldtest would actually run again where weird
Python errors:

Traceback (most recent call last):
  File "../../adonthell/test//data/schedules/map/mapview.py", line 40,
in focus_on_character
    view.scroll_to_z (char.ground_pos(), 2) # abs(int(character.vz())))
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/adonthell/world.py",
line 786, in scroll_to_z
    return _world.mapview_scroll_to_z(*args)
TypeError: in method 'mapview_scroll_to_z', argument 3 of type 'u_int16 const &'
swig/python detected a memory leak of type 's_int32 *', no destructor found.

Turns out, SWIG knows nothing about our data types, now that we no
longer use the built in integral ones. Luckily, it comes with the
module stdint.i, which tells it about the ones from inttypes.h.
Including that in all our interface files resolved the issue quickly.

I'll commit all those changes together with my updates on the
character shadow. Still not completely done, but getting there ...

Kai

P.S.: Glad to see that I'm no longer the only one committing code
(must have been for the past year and a half or so)! Keep it up,
Frederico :-).