At Fedora, even if I start multiple Flare, Flare doesn't warn.

[sujiniku]

Even if I click the shortcut to "flare" in the "flare-game" folder multiple times, Flare doesn't warn.

[dorkster]

So you're using the "Engine (x86_64) + Game" Linux release? I've tested that on Ubuntu 16.04 and got the proper warning. I'll try Fedora.

[sujiniku]

Sorry, I don't know how to start and build "Engine (x86_64) + Game" Linux release. That is why I build the following script.

git clone https://github.com/clintbellanger/flare-engine
git clone https://github.com/clintbellanger/flare-game

cd flare-engine
cmake . && make

cd ../flare-game
ln -s ../flare-engine/flare flare
cd mods
ln -s ../../flare-engine/mods/default default
cd ..
./flare

I would like you to write a script to start "Engine (x86_64) + Game" Linux release" in README etc. I checked the multiple-start issue on Flare 1.0 (Linux) now, Flare doesn't warn.

[dorkster]

With "Engine (x86_64) + Game", I was referring to the binary Linux release that I added to the website. It shouldn't need anything added to the README, but I discovered it actually doesn't run on Fedora anyway. But that's another issue.

Try removing the Flare lock file and seeing if Flare warns of multiple instances afterwards:

rm ~/.config/flare/flare_lock

[sujiniku]

after below: [sujiniku@localhost flare-game]$ rm ~/.config/flare/flare_lock

I clicked the shortcut to "flare" in the "flare-game" folder multiple times, Flare doesn't warn.

[McSinyx]

I'm not sure if I've encountered a separate bug or something is wrong with my system. About a year ago, flare ran fine on my system, now it can't start because of some problem with D-Bus:

INFO: Flare 1.05 (Linux)
dbus[29749]: arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" f
ailed in file ../../../dbus/dbus-message.c line 1362.
This is normally a bug in some application using the D-Bus library.

  D-Bus not built with -rdynamic so unable to print a backtrace
Aborted

Next run this prompt popped up:

This is probably because the first run failed to remove ~/.config/flare/flare_lock. Choosing either Continue or Reset dump the same dbus error as shown above. Also note that Reset can't reset the lock.

Edit: I'm on Debian testing with D-Bus 1.12.6.

[dorkster]

@McSinyx I don't think there's any issue with the prompt in your situation. If Flare crashes, it can't decrement the lock file properly. So even if you reset the lock file, a crash will leave one dangling instance.

We don't interact with DBus directly, so it is either SDL or one of SDL's dependencies. Are you using the binary Linux version from the website? That version is built on an Ubuntu 16.04 LTS system. A mismatch of linked DBus versions could be the source of your issue. If you haven't already, I'd suggest compiling from source in order to use your system's libraries.

[McSinyx]

Sorry I didn't mention that I was trying to play the git version. Also additional info on SDL version:

• libsdl2-dev 2.0.8
• libsdl2-image-dev 2.0.3
• libsdl2-mixer-dev 2.0.2
• libsdl2-ttf-dev 2.0.14

[dorkster]

@McSinyx Hmm, this bug looks like it was fixed in SDL 2.0.8. But that's obviously not the case if you're building with 2.0.8. One thing I noticed in the comments there is that the issue apparently disappears when DBus is built with --disable-asserts. DBus is built as such for my distro, but there's a chance that's not the case for Debian. I did some more searching and have a few things you can try:

1. Try running Flare with DBUS_FATAL_WARNINGS=0 ./flare
2. Try running Flare as root to bypass DBus altogether.

[McSinyx]

Hooray both of your suggestions worked! I've also noticed that the game's performance had improved a lot (which is, partly because of enabling hardware accel I think, although sdl renderer seems to be less resource hungry).

I have a few not-very-related questions about rendering though:

• Disable HW sufaces in my case makes the game a lot more laggy instead of improving performance which is suggested by the tooltip.
• On broken HW graphic (I don't have proper driver for my ancient GPU :stuck_out_tongue:) sdl_hardware works mostly fine accept alpha channel (in minimap and text as shown below). Just curious, does that mean the other HW drawings works for me or they are falled back to software rendering, and if HW accel does work in this case, should we provide a work-around for the alpha channel?

[dorkster]

@McSinyx What's your GPU? I assume switching from the sdl_hardware renderer to the sdl renderer removes the glitches?

[McSinyx]

It's ATi Radeon 9200 (codename RV280) but no worries about it, latest version of the proprietary driver only supports Xorg 6.x (6.8 and below IIRC). Libre driver (with non-free firmware) support rendering at some certain level as I said above. Now I can confirm that it does work for other drawing (since ~40% CPU is used on sdl_hardware and ~100% on sdl). And yes, there isn't any gliches if rendered using sdl.

I'd also want to add that the D-Bus problem is not Flare's fault since it happens with Red Eclipse too. 'long as no additional user complain about it, I don't think we need to investigate any further.

Edit: since the amount of area used for drawing text and minimap is relatively small, I think it's a good idea to provide a fix for this. If you don't think it's too hard, you can guide me to write that work around as I'm having the old machine to test it :smiley: