A New Commercial Game For Linux That's Not An FPS

[CoreCode]

>Everything seems to be working on r300g, with the exception of static lightning.

thats weird since static lighting is a very simple shader that is a small functional subset of the static+dynamic shaders. its beyond me how static can be broken and static+dynamic still works.

> so I'll do some reverse git bisecting too find out what commit fixed this and suggest it be cherry picked for the next stable release.

thats great, thanks

>On the Intel GPU object outlines are broken, there's a lot of outlines where none should be

that sounds a bit like the awful fglrx / catalyst driver bug i had to work around - the lines would be completely randomized if the line width ( glLineWidth() ) was set to a value equal or larger than 2.0 (although they claim to support line width up to 63). perhaps its also related to line width, setting the outlines to thin and using a small resolution could test that.

>I will file bugs about this later (with screenhots)

thanks thats great.
i guess once we have the final version we can link it to the bug-reports because the URL won't change every day then.

>I guess it will run pretty fine on the contemporary GPUs

thanks thats good to hear. no intel hardware for testing around here.



btw since benmoran also mentioned the Mesa Postprocessing crash after i posted beta 3 i wondered if my workaround for defaulting to "no postprocessing" actually works. i de-installed the catalyst drivers from my ubuntu 11.10 installation to test the Mesa drivers instead. however this only yielded these drivers:

"VENDOR": X.Org "RENDERER": Gallium 0.4 on AMD JUNIPER "VERSION": 2.1 Mesa 7.11

they are "completely" broken since they don't support the DXT compression, meaning only black instead of all textures (but funnily they also crash on postprocessing - not much point working around it if they don't work anyway though)

i installed "mesa-dri-drivers-experimental" in hopes to get the mentioned "Mesa DRI R600" drivers, but drivers are still "Gallium" after the reboot. also there is no xorg.conf to edit to force the driver change. any linux gurus wanna chime on how i can change to the "Mesa DRI R600" drivers? i have a 5770 btw.

p.s. i think what the output these open source drivers give for the "VENDOR" and "RENDERER" strings are complete madness. my card is from ATI not from X.Org

[curaga]

DRI r600 would be the old driver, which was deprecated in the latest release IIRC. You have the current Mesa driver for your card.

[whizse]

>Everything seems to be working on r300g, with the exception of static lightning.

thats weird since static lighting is a very simple shader that is a small functional subset of the static+dynamic shaders. its beyond me how static can be broken and static+dynamic still works.

Yeah, odd that, the lower part of the screen is just black:

http://img840.imageshack.us/img840/2924/screenshotat20111201150.png

>On the Intel GPU object outlines are broken, there's a lot of outlines where none should be

that sounds a bit like the awful fglrx / catalyst driver bug i had to work around - the lines would be completely randomized if the line width ( glLineWidth() ) was set to a value equal or larger than 2.0 (although they claim to support line width up to 63). perhaps its also related to line width, setting the outlines to thin and using a small resolution could test that.

Screenshot here:

http://img521.imageshack.us/img521/976/outlinesparticles.png

(also shows the misrendering of the engine flames)

I can run a few more tests with different resolutions.

btw since benmoran also mentioned the Mesa Postprocessing crash after i posted beta 3 i wondered if my workaround for defaulting to "no postprocessing" actually works. i de-installed the catalyst drivers from my ubuntu 11.10 installation to test the Mesa drivers instead. however this only yielded these drivers:

"VENDOR": X.Org "RENDERER": Gallium 0.4 on AMD JUNIPER "VERSION": 2.1 Mesa 7.11

they are "completely" broken since they don't support the DXT compression, meaning only black instead of all textures (but funnily they also crash on postprocessing - not much point working around it if they don't work anyway though)

i installed "mesa-dri-drivers-experimental" in hopes to get the mentioned "Mesa DRI R600" drivers, but drivers are still "Gallium" after the reboot. also there is no xorg.conf to edit to force the driver change. any linux gurus wanna chime on how i can change to the "Mesa DRI R600" drivers? i have a 5770 btw.

Right, this is where it gets confusing. There have been two different sets of Mesa drivers, the classic ones (now only Intel uses this infrastructure) and the Gallium3D ones. "Mesa DRI R600" would be the deprecated ones, so you should check for Gallium.

Unfortunately all FLOSS drivers are crippled out of the box when it comes to DXT compression, you need to install the libtxc_dxtn library for this to work.

http://dri.freedesktop.org/wiki/S3TC

p.s. i think what the output these open source drivers give for the "VENDOR" and "RENDERER" strings are complete madness. my card is from ATI not from X.Org

I actually think Mesa does this right (though someone who's an actual developer should chime in) the vendor and renderer is supposed to reflect the OpenGL implementation, not the hardware.

[Hamish Wilson]

Anyway, I grabbed the latest Beta and gave it a go on my machine. Here are my specs:

Operating System: Fedora 16 Linux
Video Card: AMD Radeon HD 4670
Memory: 4 Gigabytes
Processor: AMD Sempron CPU 2.7 Ghz
Hard Drive: 2 TB Western Digital Caviar Green

I am also using the system supplied R600 Gallium drivers. Like the other posters, it would crash when I hit a wall and at one point in the middle of the game when post processing was turned on, which it was by default. Turning off post processing solved this issue with little or no detriment to game graphics. I kept all the other settings at their apparent defaults.

Playing at my native resolution of 1280x1024 on XFCE with composting on resulted in no performance problems, although I do have "Display fullscreen overlay windows directly" selected in Window Manager Tweaks.

So, other than the reported driver bug up-stream which should hopefully get fixed, it seems to be working fairly well on the free software radeon drivers.

[ninez]

thanks ninez. looks like we can post the final version to desura early next week.

are there any other linux (game) stores besides desura, ubuntu software center, tux games, gameolith, fun4tux, wupra and indievania?

Hey, No problem CoreCode!

Even though i don't really play games, for the time it takes to download/install - it is worthwhile for anyone to test out. If it had turned out that i had found a bug, rendering issue, etc - reporting back would have been very useful to you guys (although, i am sure hearing that it works well, is also good

...as for linux game stores - i have no idea, this is the 1st game i have installed in a very long time. I do from time to time play some classic NES games, mainly 'River City Ransom' ...but that is about as far as it goes. so i have no idea where people purchase games (in fact, in your list i've only heard of 'desura' and obviously ubuntu software center (which i have never actually used before).

sorry i couldn't be of more help.

cheerz

[CoreCode]

>DRI r600 would be the old driver

ok thanks

>Yeah, odd that, the lower part of the screen is just black:

yes i investigated this issue, but have been unable to find a workaround because very simple steps are completely failing in the shader. if you file a bug somewhere please let me know, i can contribute some information and a reduced shader that also exhibits the issue.

btw turning off the "extended shadows" also works around the issue.

shouldn't be a big deal since the prettier "Dynamic Lighting" works just fine and is the default anyway.

>(also shows the misrendering of the engine flames)

ok i guess the intel driver guys have some work ahead of them

>Unfortunately all FLOSS drivers are crippled out of the box when it comes to DXT compression, you need to install the libtxc_dxtn library for this to work.

good news, thats actually not true. we don't need any DXT *compression* since we are using pre-compressed textures. setting force_s3tc_enable=true in the launcher seems to completely solve the issue since it makes the driver accept the pre-compressed textures.

>the vendor and renderer is supposed to reflect the OpenGL implementation

ok well, maybe, though its awful that i can get random "vendor" results for an ATI card. the whole concept of obtaining information about the card and drivers through 3 random strings is broken. it works good enough on the mac where there are few well defined strings, but on linux this gets insane. anyway, no use complaining

>So, other than the reported driver bug up-stream which should hopefully get fixed, it seems to be working fairly well on the free software radeon drivers.

thanks for testing! good news is that the new beta 4 works around the driver bugs so there should be no need to disable postprocessing anymore. i do feel like the post-processing effects have a very large impact on overall visual quality

>although, i am sure hearing that it works well, is also good

yes thanks, thats really what i wanted to hear


ok i've uploaded a new beta 4 here for those people with ATI mesa drivers:

http://corebreach.corecode.at/CoreBreach-1.1-beta4-linux32.tar.bz2

http://corebreach.corecode.at/CoreBreach-1.1-beta4-linux64.tar.bz2

the only changes are improved compatibility with the mesa drivers:
• it should now work with post-processing on mesa drivers without crashing (thanks to Vadim from the mesa bug report for the workaround)
• it should now work on mesa drivers even with libtxc_dxtn not being installed

additionally there is a script to install a link to the game in the gnome/KDE "start" menu.
cd CoreBreach-1.1-beta4-linux64/;sudo ./installMenuShortcut.sh

thanks for all the testing and bug-reporting.

[Hamish Wilson]

thanks for testing! good news is that the new beta 4 works around the driver bugs so there should be no need to disable postprocessing anymore. i do feel like the post-processing effects have a very large impact on overall visual quality

I have done testing for other Indie games before on the free drivers (Dirk Dashing 2) so this is no biggie.

As to the fourth beta, it does indeed fix the post-processing problems, but I had troubles with the launch script. In the end I had to bypass it and use the actual game binary like so:

cd /home/hamish/Downloads/Games/CoreBreach-1.1-beta4-linux32/CoreBreach.app
[hamish@Griffindor CoreBreach.app]$ export LD_LIBRARY_PATH=/home/hamish/Downloads/Games/CoreBreach-1.1-beta4-linux32/CoreBreach.app/standalone
[hamish@Griffindor CoreBreach.app]$ ./CoreBreach

Once I did that, everything worked fine.

[CoreCode]

>As to the fourth beta, it does indeed fix the post-processing problems,

thanks, great.

>but I had troubles with the launch script

thats bad, i had to do some changes to the script would work when invoked from the gnome/kde "start" menu (`pwd` not working), i believe these are to blame.

can you give this launcher script a shot?

http://corebreach.corecode.at/CoreBreach.sh

[whizse]

>As to the fourth beta, it does indeed fix the post-processing problems,

thanks, great.

>but I had troubles with the launch script

thats bad, i had to do some changes to the script would work when invoked from the gnome/kde "start" menu (`pwd` not working), i believe these are to blame.

can you give this launcher script a shot?

http://corebreach.corecode.at/CoreBreach.sh

This new one is working, the one in beta4 broke the ability to run the script right from the directory.

[CoreCode]

good thanks, i've re-uploaded the beta4 package with the fixed launcher script in case someone else tries them out.