Some minor problems and questions about the code [resolved]

[Knitter]

Hi,

I know I must be the only OS X user looking at Linwarrior so please bear with me a bit, some of the issues are really Apple's fault... I updated my system to Lion and a few new issues arose and I would like understand what you think of them and if you have any interest in working to solve them.

First thing: ALUT, not part of OpenAL implementation offered by Apple and freealut fails to properly compile, besides having some name/symbol collision with OpenAL 1.0 (at least that's what the docs I found on the issue say, can anyone confirm that this is [still] a problem?). Since linwarrior uses ALUT and some things that are not available in current macs I had to resort to a unofficial, generously offered, obscure and temporary build that I found in Flight Gear's forums.

Question: Is there an alternative that is multiplatform and can be implemented to replace ALUT?

Second: New C++ features are great but keeping up with compiler versions and finding compiler versions for new C++ features is not nice . Some of the code uses the new C++11 ranged for loop that currently GCC 4.6 has but it means yet another compiler from macports installed in the system. This is not really an issue but are there any more such "new" features? I've so far found only the ranged for loop but can't install GCC 4.6 yet to compile the code.

Last: 32bit VS 64bit. OS X is 64bit by default since Snow Leopard but it gets harder to maintain both 32 and 64bit software and having to always compile under 32bit is something I would like to avoid. Currently there are a few casts that will cause compiling errors/warnings since they are not 64bit ware. Like casting the Thread object to int in the hashCode method of the Thread class. I don't really know how to solve this with minimal effort and am still investigating the possible solutions. For the moment I added the -m32 flag to the compiler flags Doesn't work since some of Apple provided libs are 64bit only.

What are your plans for the development? I understand this is a project to develop in your spare time but are you only working towards GNU Linux/MS WIndows support or supporting other platforms is also an option?


Edit:
After a few tests I managed to compile the code but it crashes randomly with memory access violations that I can't seem to track. I spend several minutes trying to figure out where the crash occurred but it's not always in the same place so I suspect that some thread is crashing maybe due to the difference in int sizes and pointer sizes. I removed the optimizations and added the debug flag but step-by-step execution provided no real info so far.

Regards,

Knitter

[hc]

I am a user-friendly developer
So please don't hesitate to ask further...

ALUT:
ALUT is only used loading complete WAV-files into buffers.
Ideally it will be replaced with OGG-Vorbis loading or streaming.

32/64bit:
Are you experiencing any crashes on 32 bit? Because that would really really worry me (I did some radical refactoring recently that may be the cause).
The thread-pointer-cast-issue was solved just yesterday ( https://github.com/hackcraft-de/linwarrior/issues/1 ).
I am glad for every such 64bit issue or bug you report and I really appreciate your efforts to bring linwarrior to another OS.
@qubodup: Have you had any crashes with the recent version yet?

C++0x:
I think I'm currently only using range-based-for.
But I think I'll be using the extended initialiers in the future.
These are basically the two features I was longing for.
The range based for could be replaced with some macros I was using before
(possibly demanding the "auto"-type-keyword but that was already supported in earlier GCCs).
Maybe you can automatically search/replace with a shellscript and regular expressions?
That could possibly be run by the makefile prior to compiling.

Supported Plattforms:
Basically I'm only developing for any *nix but that would be only half the truth.
I'll try to be as platform agnostic and thus portable as possible and my choice of libraries excludes any unportable libs.
I've tried to incorporate necessary changes for OS X (that you pointed out before) and
I am going to try my best to include necessary changes that don't break my general portability.
And I'll give support as much as I can without having OS X at my disposal.

[hc]

Oh and everyone: Don't hesitate to post *any* issues and wishes to https://github.com/hackcraft-de/linwarrior/issues for whatever system or demand.
I'm still free to close the issue

[Knitter]

32/64bit:
Are you experiencing any crashes on 32 bit? Because that would really really worry me (I did some radical refactoring recently that may be the cause).

I had to go with 64bit, so I only see crashes with my 64bit build.

The thread-pointer-cast-issue was solved just yesterday ( https://github.com/hackcraft-de/linwarrior/issues/1 ).
I am glad for every such 64bit issue or bug you report and I really appreciate your efforts to bring linwarrior to another OS.

Noticed it a few moments ago . Compiler doesn't complain any more and the game stopped crashing randomly but it still crashes on shutdown.

C++0x:
I think I'm currently only using range-based-for.
But I think I'll be using the extended initialiers in the future.
These are basically the two features I was longing for.

OK, just wanted to know if I had to keep upgrading my compiler

Supported Plattforms:
Basically I'm only developing for any *nix but that would be only half the truth.
I'll try to be as platform agnostic and thus portable as possible and my choice of libraries excludes any unportable libs.
I've tried to incorporate necessary changes for OS X (that you pointed out before) and
I am going to try my best to include necessary changes that don't break my general portability.
And I'll give support as much as I can without having OS X at my disposal.

I'll try to find any problems and preferably suggest solutions that can be used in a portable way, instead of just complaining

After some pocking around I managed to have a steady set of instructions on how to build in OS X so I think I can manage from now on, and I even managed to make dead enemies show as black dots in the radar .

[sireus]

ALUT:
ALUT is only used loading complete WAV-files into buffers.

Hmm, can't you use builtin SDL functionality for that (SDL_LoadWAV and friends)?

[hc]

http://adrianhenke.wordpress.com/2008/0 ... l_loadwav/

[qubodup]

Oh and everyone: Don't hesitate to post *any* issues and wishes to https://github.com/hackcraft-de/linwarrior/issues for whatever system or demand.

Glad you like their issue tracker!

I recommend you add a link to the normal github page to http://hackcraft.de/games/linwarrior_3d/downloads.htm and a link to the issue tracker to http://hackcraft.de/games/linwarrior_3d/bbs.htm so people find their way there better.

[hc]

As for the missing range-based-for-loop on not-so-recent compiler versions:

I've composed a regular expression for searching these and replacing them with what should be equivalent iterator-based-for-loops (backporting). These loops still require the "auto"-type-keyword but that already exists in not-so-recent compilers. You can use Netbeans "Replace In Project"-feature (with regular expression checked) or possibly use a shell-script.

Replace for (Typename* loopvar : listvar[->subvar]) { with oldschool iterator style - requires auto-keyword:
search: for\s*\(\s*([A-Za-z0-9_:\<\>\,\*]*\s*[\*\&]?)\s*([A-Za-z0-9_]*)\s*:\s*([\*]?[A-Za-z0-9_\->]*)\s*\)\s*\{
replace: for (auto $2_it = ($3).begin(); $2_it != ($3).end(); $2_it ++) { $1 $2 = ($1) (*$2_it);
in: *.cpp, *.h

(Note to visitors: This regex was specificaly designed for occuring cases in this project and may not be suited for the general case - make sure it works for you.)

EDIT: You should review rNavcom.cpp:87 for that assignment to the reference variable (&).

[Knitter]

I've composed a regular expression for searching these and replacing them with what should be equivalent iterator-based-for-loops (backporting). These loops still require the "auto"-type-keyword but that already exists in not-so-recent compilers. You can use Netbeans "Replace In Project"-feature (with regular expression checked) or possibly use a shell-script.

Thanks, that will come in handy.

Since I wanted to ask questions about the code I'll just re-use this topic for some more. I've been working on changing the use of SDL and adding SFML, http://www.sfml-dev.org, since I wanted to learn more about the code base I took the opportunity to try this library and I've managed to replace all SDL functionality for SFML equivalent, my current problem is that in linwarrior files are read relative to the working directory that is the project root but in my project the working directory is the dist folder. Is there anything that you do to change the working directory or anything that SDL does?

I didn't want to add code to find the correct path but I can't find out why one binary uses the project root as working dir and the other uses the dist folder, even if I execute the file from the project's root the files are loaded from a dist/data that does not exist.

[hc]

The program is usually started from the project root directory as the current work directy.
There are shell scripts for starting in the project-root-directory - the binary in dist isn't meant to be started directly from that directory.
So there is nothing in the code.

Distributions usually choose to install application data in a fixed directory like /usr/share/games/linwarrior/data and I've seen the source beeing patched to match that directory. Effectively search and replace all occurances of "data/ in the source with "/usr/share/games/linwarrior/data/ before compilation.

[Knitter]

As a quick workaround that may only work on my system I've added '../' at every path. Now I can start the game and test my changes and I've started adding more screens and converting the keyboard code (this will require some reading as SFML joystick handling is different from what SDL offers).

[Knitter]

I've searched for this but I'm finding it difficult to find any OpenAL/ALUT docs. Could you shed some light on what this line does:

{l Code}: {l Select All Code}

void rWeapon::transform() {
//...
//line 114:
alSourcefv(soundSource, AL_POSITION, &weaponPosef[12]);


From what I could find online (I wasn't able to find exact documentation on the function) it changes the origin of the sound, but how are those origins stored? SFML offers me a method that requires 3 float coordinates.

That and the cMech::spawn() method of the cMech class are the only places where I'm having trouble changing to SFML (aside from difficulty with the input ).

[NaN]

This is OpenGL style. You are passing a pointer to an array containing 3 floats(x,y,z) as parameter. weaponPosef is a 4x4 matrix I guess. Then the origin is stored in 12,13,14.

[Knitter]

I thought so, and I used the method SFML offers me and sent the coordinates for x, y and z as index 12, 13 and 14, but as soon as I do that the sound stops playing. If I don't change the position the sound plays correctly but setting the positions using the array indices mutes the sound.

[NaN]

From what I see SFML is using OpenAL for sound. So it is either you or sfml doing something incorrectly.

[NaN]

Look here: https://github.com/LaurentGomila/SFML/b ... Source.cpp

{l Code}: {l Select All Code}

void SoundSource::setPosition(float x, float y, float z)
{
    alCheck(alSource3f(m_source, AL_POSITION, x, y, z));
}

[Knitter]

From what I see SFML is using OpenAL for sound. So it is either you or sfml doing something incorrectly.

It's most likely my fault since I'm still getting the hand of C++.

I changed this:

{l Code}: {l Select All Code}

alSourcefv(soundSource, AL_POSITION, &weaponPosef[12]);


For this:

{l Code}: {l Select All Code}

soundSource.SetPosition(weaponPosef[12], weaponPosef[13], weaponPosef[14]);


My soundSource is a sf::Sound object. With my code there is no sound, if I comment my code then every sound plays correctly.

[NaN]

A sf::Listener calls are missing in cMech: //KNT alListenerfv(AL_POSITION, pos);
http://www.sfml-dev.org/documentation/2 ... stener.php

Another thing:
In int GameMain::run() you are calling app.Close() on exit and then app.Display(). This will fail, app won't exit. Either do event processing after display or move app.Close() out of the loop, use a flag to exit the while loop.

[Knitter]

A sf::Listener is missing in cMech: //KNT alListenerfv(AL_POSITION, pos);

Ahh, now that makes sense

Another thing:
In int GameMain::run() you are calling app.Close() on exit and then app.Display(). This will fail, app won't exit. Either do event processing after display or move app.Close() out of the loop, use a flag to exit the while loop.

I was a bit puzzled by that but I saw it in the tutorials I found about events and since it has been working I paid no more attention to it. Thanks for the advice, I'll change that loop when I some more screens, now I have the sound to properly change

[NaN]

I was a bit puzzled by that but I saw it in the tutorials I found about events and since it has been working I paid no more attention to it. Thanks for the advice, I'll change that loop when I some more screens, now I have the sound to properly change

Small correction. It is not Display() that is the problem, but the drawFrame() call. As it calls OpenGL when the window/context is already gone.

[NaN]

To fix the mouse controls you could use(this is pretty much what the original code does I think), window is app in your code

{l Code}: {l Select All Code}

      // get mouse delta relative to window center
      int x0 = window.GetWidth() >> 1;
        int y0 = window.GetHeight() >> 1;
        int xd = input.GetMouseX() - x0;
        int yd = input.GetMouseY() - y0;

      // center/reset mouse cursor
        window.SetCursorPosition(x0, y0);

        pad->setAxis(Pad::AX_LR2, pad->getAxis(Pad::AX_LR2) + 10.f * xd / (float)x0);
        pad->setAxis(Pad::AX_UD2, pad->getAxis(Pad::AX_UD2) - 10.f * yd / (float)y0);

[Knitter]

Thanks for the answers NaN. I haven't yet looked at the mouse and joypad/gamepad input but I'll try your code as soon as I do.

And here is another question for hc, how do I change the time a mission starts? I tried changing the value for the mission time but it always starts at night, I would like to change that and have a mission start during daytime.

[hc]

That's a bug in the Background-System:
Time is never initialized properly - the bug was most likely introduced with the change to the Subsystem-Interface.

Besides there is a time scaler in advanceTime(..) - you can remove the scaling so that the environment dome and light is "linked" 1:1 to the current time.

I've pushed a fixing commit but note that the Background doesn't trace the current world time - it is just copied once on instanciation of Background and then advanced using that scaler in advanceTime(..).

[hc]

Whoops, just noticed world time wasn't set in OpenMission before instanciating Background, I've fixed that.
[Beware, I'm kind on a blind flight currently on a holiday system that can compile but not run...]

BTW I think I'll better put the mission time into the property file, too.