New version for Debian Jessie release?

Onsemeliot
2014-07-08
2015-05-16
1 2 > >> (Page 1 of 2)
  • Onsemeliot
    Onsemeliot
    2014-07-08

    Hi people,

    has really everyone exept me left this project without any further notice? I would love to make at least all the new maps available in Debian. We have support from a maintainer who would package it for us, but we need to decide on what and how he should take for that. As far as I know we had at least some minor code fixes as well which should be in a new release. Unfortunately we seem to still lack someone able and willing to develop further improvements in the code base.

    Can we at least decide on what the next version should contain? Should we give it a new version number since there are a lot new maps and events?

     
  • landroni
    landroni
    2014-07-08

    I already said this on previous occasions: I would gladly take care of performing a new release (including Ubuntu and Debian packaging) if the changes in textures/ads/names weren't rammed through as they have been. As far as I'm concerned, at the moment there is no middle-ground consensus, and I have no inclination to fight over this matter.

    This said, I think a new release is long overdue, not least to show-case the much improved collection of playable tracks and to put the new textures for a test to a wider audience. Also new releases have the beneficial side-effect of signaling that a project is not dead, potentially encouraging new contributors.

     
    Last edit: landroni 2014-07-08
  • Onsemeliot
    Onsemeliot
    2014-07-08

    Because I don't expect Trigger Rally becomming a sudden hype I don't think the textures are a base for stopping giving out a new version.

    If it's that important to you, from my view we could as well just stick with the original non-free versions. I don't know if we can get any feedback from Ivan on this. Is there anyone else interessted in taking part in this decision?

     
  • Onsemeliot
    Onsemeliot
    2014-07-10

    Since Ivan seems to have vanished you could just replace his textures with the old ones and we should be ready to go. What do you think?

     
    Last edit: Onsemeliot 2014-07-11
  • landroni
    landroni
    2014-07-14

    Hi Onsemeliot,
    This works for me.

    Here's what I propose:
    - Textures (not discussing ads here): Even though I have a strong preference for the old look of the cars (and I know for a fact that I'm not the only one of this opinion), the new textures that Iwan created are excellent work and probably should stay. It also has the benefit (from memory) of switching a different "engine" (or whatever that was) that was "better" (more open, more wide, I don't really remember). From what I recall, this switch would allow adding more cars more easily. [r88]
    - Ads: Some of the ads in the new textures should be changed before the release. Things like 'grep', 'less', 'Tex technologies' don't work very well and should go. Personally I would prefer if we went for a selection of real-life FOSS projects, with or with no relevance to Trigger. Things like FSF with its logo, OpenAL with its logo, etc. I would replace TRI with TRC: Trigger Rally Championship. If concerns arise wrt if said projects agree to this use of their logos, then we should seek confirmation on respective lists. We should start a separate thread for this, to try to come up with a list of suitable projects/logos, and then edit the textures that Iwan created. [r88]
    - Splash screens: To my surprise black screens actually work OK. Although I'd rather that we had a "Loading..." or similar, if we can find nothing sports-related. [r96]
    - Names: The current names are no good and should definitely be replaced. If we insist on having non-trademarked names, then we could simply take a pick from Speed-Dreams: https://sourceforge.net/p/speed-dreams/wiki/ListofCars/ . But I believe it would be just fine if reverted to the old names; for example TORCS uses Mitsubishi Lancer EVO V WRC or Ford Focus WRC with no apparent trouble ( http://www.berniw.org/trb/cars/carlist.php ). In any case I again suggest that we open a separate thread to decide on keeping old car names or new names, and if the latter which ones. [r88]
    - Old car textures/ads/names: Whichever the result of the potential changes from above, if technically feasible I would strongly prefer that we continue shipping the old textures (or make them available via a download online), with a config file option to change between old and new textures. The new textures would be enabled by default, but users desiring the old look could still get it. I think this would be the best compromise for the current impasse.
    - Build warnings: I've just compiled Trigger and I've got a long list of build warnings. Someone (maybe Jasmine) should look over these and fix them where possible.
    - Packaging: Once we get all these items in order, I'll need to have a chat with the Debian maintainer for Trigger to make some subtle changes to the packaging. Nothing too important.
    - Release version: I think we will have enough changes to warrant a new "major" release: 0.7.0
    - Release schedule: Debian Jessie Freeze date is announced for November 2014. If we can get all the above ready until November (which sounds quite feasible), then we could make the freeze date.

    Let me know what you think of all this,
    Liviu

     

    Related

    Commit: [r88]
    Commit: [r96]

  • Onsemeliot
    Onsemeliot
    2014-07-15

    Hi Liviu,

    I think we've got a deal:

    • Textures: All textures are fine for me. I have no clear favourites. My argument was only based on legal concerns because of brands on textures and in names.

    • Ads: We have just three cars right now (since I wasn't able to figuere out how to create a new mesh for Trigger Rally yet). Therefore the list of possible ads is quite limited. I would love to promote free software (projects) on ads. Which actual projects do you want to see as ads on the car textures? I guess it's quite easy to adapt Ivans svg files. The original files are a little trickier to adjust, but I believe I would be able to adapt all of them, if You want me to do that. (I did not check yet if we are even allowed to adapt the old textures.) I just need clear instructions on what you want to have where.

    • Splash screens: As far as I know we didn't find a solution for disproportional scaling. I would rather have no background than an distorted image. (The only exception from this would be an abstact background with mud or any other structure which doesn't look too bad if it is distorted.) On morguefile.com there are many CC images we could use for that.

    • Names: I'm also not apologetic on car names. I would prefer not too complex names which are hard to remember. Beside that any names would be ok for me - if nobody is offended by it.

    • Old car textures/ads/names: From my point of view we do not even need to use the new textures (by default) if you prefer the old ones. I would just recommend (but not insist on) getting rid of actual brands.

    • Build warnings: I fear I don't really get what that means. The only issue I have since years with my source code generated instance of the game is the fact, that it often doesen't manage to start. After a short black flash the game just doesn't start at all. It's no big deal since I can start it again and then it usually works. It's only annoying when I am working on new maps since then I very often start the game in order to test what I'm working on.

    • Packaging: I have already had contact with Stefan and he is willing to help with the Debian packaging again if we can decide on a new release version on the developers mailing list.

    • Release version 0.7.0 is what I had in mind as well.

    I'm happy to help in all ways I can in order to get this new release out in time. I hope I can finish at least two new maps in the mean time as well since I already started working on it...

    Thank you for taking my suggestion for this new release seriously and for all the effort you put into the project. :)

    Cheers,
    Onsemeliot

     
  • landroni
    landroni
    2014-07-15

    OK, sounds good to me. I have no plan on rushing on things, as I'm currently somewhat busy in real-life, so I propose that by the end of the week we start the separate threads on ads, splash screens and car names. And move on from there.

     
  • Onsemeliot
    Onsemeliot
    2015-05-05

    Last week Debian 8 "Jessie" was released. Therefore I installed Trigger Rally from Debians Repository after switching to the new stable version of Debain. Unfortunately our new game icon wasn't incorporated. Each time I tried to start the game in full screen it crushed. Therefore I uninstalled it and I will attempt to build it from source again.

    I fear Trigger Rally wasn't implemented in Debian in a very convincing way. I even encountered poor performance (no smooth animations) and constantly reoccuring texture glitches. I can't tell why I am having issues with the Debian implementation I didn't have before with my source code build from the same release. I'm still using the old hardware.

    So unfortunately from my point of view the implementation into Debian doesn't serve as an advertisement for Trigger Rally at all.

     
    • That sounds like graphic card driver issues. Comparing the packaged vs self-compiled versions would be very helpful.

       
  • landroni
    landroni
    2015-05-05

    Not sure what's going on. Could be packaging glitches. Will have to contact the Debian maintainer...

     
  • Onsemeliot
    Onsemeliot
    2015-05-06

    Today I built the 0.6.1 version from source. Unfortunately I run in exactly the same issues than with the normal repository install. There really seems to be a problem with my graphics chip which didn't exist in Debian Wheezy.

    In the attached screenshot I circled one of the texture glitches. They jump around in different sizes like crazy. The full screen mode opens a black window and it vanishes (with some fragments left) again in less than a second. And over all the frame rates are very unsatisfying - much worse than ever before.

    Since "Super Tux Kart" (for instance) doesn't have similar issues I can only assume Trigger Rally talks to my hardware in a more or less deprecated way.

     
    Attachments
  • Andrei
    Andrei
    2015-05-06

    Today I built the 0.6.1 version from source. Unfortunately I run in exactly the same issues than with the normal repository install. There really seems to be a problem with my graphics chip which didn't exist in Debian Wheezy.

    This is a bit silly to suggest, but just to be sure TR 0.6.1 itself is not the problem you should try building old 0.6.0 from source and see how it behaves.

    Since "Super Tux Kart" (for instance) doesn't have similar issues I can only assume Trigger Rally talks to my hardware in a more or less deprecated way.

    Well you're using the same hardware if I understand correctly and 0.6.1 should talk to it just like 0.6.0 did. That's the purpose of the test above, if you see the same bugs in 0.6.0 then maybe the problem is in Debian's drivers.

    Another suggestion: please start trigger from the console and give us the output it logs.

    EDIT: start it and play it, start it fullscreen and crash it, etc. maybe something useful gets logged to the console shell.

     
    Last edit: Andrei 2015-05-06
  • Onsemeliot
    Onsemeliot
    2015-05-06

    I don't think I would need to go back to 0.6.0 since I used a 0.6.1 build on Wheezy.

    This is the shell output with full screen mode activated:

    Trigger init
    Build: 0.6.1 on May  6 2015 at 21:54:20
    Initialising PhysFS
    Set writable user directory to "/home/user/"
    Reset writable user directory to "/home/user/.trigger"
    Application base directory "/home/user/Documents/div/trigger/trigger-rally-0.6.1/data/"
    Main game data directory datadir="${prefix}/share"
    Failed to add PhysFS search directory "${prefix}/share"
    PhysFS: File not found
    Loading game configuration
    Initialising SDL
    Create window and set video mode
    Found 0 joysticks
    GLEW initialized
    Graphics: Intel Open Source Technology Center Mesa DRI Intel(R) 965GM 
    Using OpenGL 2.0
    Initialising render subsystem
    Initialising texture subsystem [SDL_Image]
    Initialising effects subsystem
    Initialising model subsystem
    Initialising audio subsystem [OpenAL]
    Performing app load
    Loading image "textures/splash/splash.jpg"
    Initialisation complete, entering main loop
    
    [... here I skip a long list of loaded data output ...]
    
    Failed to open BO for returned DRI2 buffer (1280x800, dri2 back buffer, named 17).
    This is likely a bug in the X Server that will lead to a crash soon.
    Segmentation fault
    

    So the X Server seems to cause the problem. On the other hand: PhysFS doesn't get found also - even if I checked it for being installed.

     
    Last edit: Onsemeliot 2015-05-06
  • PhysFS: File not found

    This is just PhysFS telling you that it can't find some file. I get the same message and everything runs fine: https://www.youtube.com/watch?v=ud1OYCU3ZmM

    Failed to open BO for returned DRI2 buffer (1280x800, dri2 back buffer, named 17). This is likely a bug in the X Server that will lead to a crash soon. Segmentation fault

    This is surely a problem. I'm surprised Trigger still runs (does it?) Looks like it's a non-rare Intel driver issue.

     
    Last edit: Iwan Gabovitch (qubodup) 2015-05-06
  • Andrei
    Andrei
    2015-05-06

    On the other hand: PhysFS doesn't get found also - even if I checked it for being installed.

    That's not what the PhysFS error message is about. PhysFS works and basically says that the datadir directory "${prefix}/share" is not valid ("file not found"). Note that the game cannot expand variables like BASH can, so it uses that path literally. This bug usually occurs when the user doesn't build with the --datadir parameter.

    Just to make sure that your build is correct, you should download and build trigger 0.6.1 again, like this:

    ./configure --datadir=`pwd`/data
    jam
    ./trigger
    

    Tomorrow I'll prepare an experimental build for you, which will probably require you to install libglew-dev from Debian. The GLEW that's static in Trigger Rally is from 2006, so who knows.

    EDIT: after reading Iwan's post I realized that the alternative build probably won't help with your problem. We'll see.

     
    Last edit: Andrei 2015-05-06
  • Andrei
    Andrei
    2015-05-07

    Onsemeliot (and Iwan too if you want to test) here's the experimental version which removes GLEW from the source tree, and relies on the user to install the GLEW dev libraries from the distro repository.

    Ignore its version (0.6.1) -- it is a full game archive, so it shouldn't interact with your previously installed version of TR if you set datadir correctly.

    How to build is a bit tricky; some manual editing of files is needed:

    1. install libglew-dev from your distro repo (it should drag in libglew1.xx)
    2. open a shell where you extracted the tar.bz2 and run:

      ./configure --datadir=`pwd`/data
      
    3. open the file Jamconfig with a text editor

    4. locate the line defining GLU_LIBS and change it so:

      GLU_LIBS ?= "-lGLU -lGL " ;
      GLU_LIBS ?= "-lGLU -lGL -lGLEW " ;
      
    5. run jam and the game:

      jam
      ./trigger
      

    Let me know if this fixes the graphical problems you have Onsemeliot, although I'm pessimistic.

    On the other hand, I want to remove GLEW from the source tree in future versions anyway -- because it simply doesn't belong there. Before I can do this, however, I need to learn how to use GNU Autoconf. (That's why you have to edit Jamconfig manually and it is unacceptable for regular users to have to do this.)

    Download link:
    http://www.fileconvoy.com/dfl.php?id=g056bbfcde6e0bf079996602365f8138010e0084a6

    MD5 sum:

    476cac4c6b498aa5bcd9a6810ff07b90  trigger-rally-0.6.1.tar.bz2
    
     
    • Onsemeliot
      Onsemeliot
      2015-05-09

      Your instructions work perfectly but unfortunately this new version doesn't make any difference on my system. I end up with the exactly same behaviour than described before.

       
  • Onsemeliot
    Onsemeliot
    2015-05-08

    Sorry for being slow. I will try it as soon as I get enough time. This will probably be at the coming weekend.

     
  • Andrei
    Andrei
    2015-05-09

    Your instructions work perfectly but unfortunately this new version doesn't make any difference on my system. I end up with the exactly same behaviour than described before.

    According to this thread (found by Iwan) the problem may be fixed if you install the Intel drivers from Experimental. Does it help if you update your drivers?

    https://packages.debian.org/sid/xserver-xorg-video-intel

     
  • Onsemeliot
    Onsemeliot
    2015-05-10

    Don't I get all updates from experimental if I enable the experimental sources? I don't want to end up with a non-reliable system since it's my only pc to work with.
    Maybe it's a better choice to reinstall my whole system. I have the impression it has some issues anyway. I can't extract tar.bz2 files with nautilus; the webserver was only half way installed and I had to add some other things which where present in past Debian releases by default. I probably need to use the expert install in order to ensure I have everything I need. Maybe there have been some changes in the default configuration in Jessie.

     
  • Onsemeliot
    Onsemeliot
    2015-05-10

    Fortunately someone made a backport of this version from experimental. Therefore now I can start the game in fullscreen mode again and I think the performnance is better as well.

    Only the texture glitches haven't gone away. (Screenshot) But since I am getting increasing graphics problems lately anyway there might be a connection. For months I had the issue of horizontally shifted stripes on my screen when I switched from one application to an other after I was using my system for many hours. Since I installed Jessie it got even worse. Now it's happening even after startup. Especially bad are texts which become completely illegible very soon. (See second screenshot.)

    Both effects could be caused by the same problem Friends of mine argued it could be a broken RAM chip. Maybe I need to replace my memory chips if I want to get rid of these issues.

     
    Last edit: Onsemeliot 2015-05-10
  • Sorry to hear about the issues.

    If you have more than one ram bar, you could try running with one and then with the other to identify the culprit. There's also the tool memtest, which you might be able to run from your boot manager.

    The screenshot reminds me of this bug description:
    http://blog.wolfire.com/2009/04/always-initialize-your-memory/

     
  • Onsemeliot
    Onsemeliot
    2015-05-16

    For me it rather looks like these texturing glitches result from planes which do not get drawn at all. In different levels the color of the glitches always correspond with the sky. Therefore I think I can just see through the ground.

    I made heavy memtesting already and I think I narrowed the problem down to a broken graphics card caused by dust and overheating.

     
  • I see. When I used an onboard AMD graphics card, I had issues with one of my screens showing red pixels all over the black area of my screen like ants, which would resolve by unplugging for a second. I was sure it was the screen's fault but when I started using an PCIe card, the issues were resolved.

    Hopefully your system can be extended with a different graphics card then.

     
  • Onsemeliot
    Onsemeliot
    2015-05-16

    Hopefully your system can be extended with a different graphics card then.

    No, unfortunately it's an onboard graphics chip. I might have to replace my whole system soon - at least if I want to actually see what I do. ;)

     
1 2 > >> (Page 1 of 2)