COMPILE: Linux Port

[lynx_abraxas]

Concerning the fbcon: If you can see a penguin or a "fancy" splash screen at boot time you have fbcon. You can have a look in dmesg mentioning framebuffer or read about it in the kernel docs. The old vesafb is controlled by the vga option which can give you a very neat console resolution see the kernel docs. SDL will tell you too, I think.

[lynx_abraxas]

Committed my changes to the linux branch which solve a few segfaults and most important make the sprites stay visible. The are now even animated when moving. I also implemented movie playing with a system mplayer.
I changed the routine used for setting file positions and it might help with the rim problem.
I can't change the status of the linux port reported in the FAQ: http://apolyton.net/forums/showthrea...hreadid=139275 Could someone update that to fully playable? Also advertise the linux branch as much as possible so perhaps some day the changes for linux get merged into trunk...

[lynx_abraxas]

Solved the battle screen bug as well. As suspected both sprite bugs didn't come from porting to linux...
That only leaves the mouse artefact bug on my list. Does anybody from the ctp2_win know if there ever has been such a problem? Or should I look in the porting parts of the code?

[lynx_abraxas]

I see, I haven't ever posted a screenshot here to what I mean with the mouse artefacts. The main panel is messed up after a few moves over it. I think the problem is that one mouse pointer update is sometimes skipped after the first and the background rec for the second event is used for the background of the third event. Any ideas where to start debugging?

[lynx_abraxas]

Forgot: If I start the game with 1280x1024 in windowed mode the performance is much better than in 1280x1024 fullscrenn mode. Could that come from my window manager fluxbox?

[Fromafar]

Originally posted by lynx_abraxas
Committed my changes to the linux branch which solve a few segfaults and most important make the sprites stay visible.

I couldn't help noticing that the code in the linux branch - in particular Anim.cpp - is really old. The changes you made do prevent crashes (when an Anim copy has a larger lifetime than an original), but will probably introduce memory leaks.
Did you have a look at the trunk version of Anim.cpp? It has been modified in revision 494 to solve the crashes without introducing memory leaks.

[lynx_abraxas]

I haven't looked at anim.cpp at all yet. I'm wondering what it is for. The animation of the faced sprites is in the sprite file itself.

[Fromafar]

My understanding of the Anim class is that it contains the basic bookkeeping (current frame number etc.) of an individual instance on screen. So there can be multiple instances of the same "file" animation, and each instance may be executing at a different stage.

[lynx_abraxas]

I'm currently looking into the code that evaluates the keyboard input because in the linux port it is not possible to type into textfields (eg when saving a game or renaming a city). It seems to me the keyhandler for the ui_control is incomplete. It only evaluates \t and ' '. When I compared the code with trunk I could not find any differences.
So I'm wondering if input into textfields works under windows and if so where that is handled?
Another thing: I made the mouse wheel work under the linux port but I had to notice that the wheel input is disgarded for lists in the loadsave window. How is that under windows and is there a reason it has no mouse_over handler?

[Martin Gühmann]

Originally posted by lynx_abraxas
I'm currently looking into the code that evaluates the keyboard input because in the linux port it is not possible to type into textfields (eg when saving a game or renaming a city). It seems to me the keyhandler for the ui_control is incomplete. It only evaluates \t and ' '. When I compared the code with trunk I could not find any differences.
So I'm wondering if input into textfields works under windows and if so where that is handled?

That works under windows, otherwise we would have heard of complains, already. (And I just have tested it to be sure ) Unfortunately I cannot answer your second question.

Originally posted by lynx_abraxas
Another thing: I made the mouse wheel work under the linux port but I had to notice that the wheel input is disgarded for lists in the loadsave window. How is that under windows and is there a reason it has no mouse_over handler?

The loadsave list doesn't react on mouse wheel input on windows either. I have no idea why it does not have a mouse_over handler.

-Martin

[Fromafar]

Originally posted by Martin Gühmann
The loadsave list doesn't react on mouse wheel input on windows either. I have no idea why it does not have a mouse_over handler.

History. Most of the user interface stuff is based on a general framework (aui_classes), most likely inherited from earlier Activision projects. The Call to Power specific stuff (for CTP1: c3_classes, for CTP2: ctp2_classes) must have been added later. The mouse wheel handling for list boxes is missing in aui_ListBox/c3_ListBox, and only present in ctp2_ListBox. Actually, it had been deactivated in the original Activision CTP2 release. They probably did not have enough time to debug it, and there was an issue with a possible "null-pointer-dereference" in the code.

[lynx_abraxas]

Thanks Fromafar for that explanation. Knowing that now the code makes much more sense to me. At least it then took me only about 20 minutes to implement mouse wheel reaction to the c3_ListBox
When investigating the textfield problem further I could implement the textfield height to be dependent on the fontsize but I'm still stuck on the normal key handling.
Something I wonder is what CallWindowProc is doing and where it is implemented or when/what is calling TextFieldWindowProc?
I also wonder if any text field implicitly inherits aui_control?

Could some one check if under M$ windows the key handler of the top window does some thing if there is a textfield in the window?

ctp2_code/ui/aui_ctp2/keypress.cpp:398: if(topWindow->HandleKey(wParam)){

[roberthuff]

It has been six months since the last message. Has the conversation moved elsewhere, or has there been no progress worth reporting?

[J Bytheway]

I can't change the status of the linux port reported in the FAQ: http://apolyton.net/forums/showthrea...hreadid=139275 Could someone update that to fully playable?

Done.

[roberthuff]

help for port to new OS

Is anyone out there still actively working on UNIX-specific aspects of CTP2?
I've managed to get things compiled under FreeBSD; I have a list of what it took to make that happen, and would like to hand it off someone who can a) integrate it and b) commit it.
The compiled version does not run. Or rather it runs for about 3 seconds and segfaults. Does anyone have the time and programming skills to help me get it working?

Robert Huff