Out of curiosity what types of texture compression does jME support other than dxt? Not talking about png or jpg, but hardware supported compression like dxt.
I’m currently using dxt, but noticed that GNU/Linux MESA drivers don’t support dxt out of the box due to licensing issues so I was wondering what other formats might be recommended and/or supported by jME users.
There’s some confusion then … DXT is typically implemented in hardware so patents shouldn’t be an issue if the application presents DXT textures to the GPU - its just passthrough from the driver’s point of view. The only problem arises when the application either requests the textures to be compressed, or if the OpenGL implementation is done in software, like Mesa’s LLVMpipe which can run without a GPU.
There’s a more detailed explanation of the nuances here:
https://secure.freedesktop.org/~cbrill/libtxc_dxtn/
When I try to run my game under Fedora it crashes and jME says that dxt compression is not supported by the hardware. Under Windows on the same system it works fine. I’m running an ATI Radeon 4100 Mobility which definitely supports it.
Under Linux I’m using Mesa because FGLRX is no longer being developed and has not been updated for Fedora 21.
I read that Mesa doesn’t support S3 texture compression, DXTn, due to licensing issues here:
http://www.phoronix.com/scan.php?page=news_item&px=MTQzNTg
It did not specify if support was included with hardware acceleration and not software, if that’s the case maybe I’m running in software mode and don’t know it. How can I tell, the desktop , Gnome3, runs well enough so I just assume I’m running hardware acceleration.
I’m using pre-compressed textures. Most were compressed with The Compressonator while others were compressed with a GIMP plugin.
Apparently you have to set the “force_s3tc_enable=true” environment variable. Mesa cannot fully support DXT texture compression, only the part of it where the texture is passed verbatim to the hardware (which is the only part jME requires). The other parts of the feature, like compressing the texture or decoding it are not supported but are still required by the specification.
Check out this answer to find out which driver is currently in use for your gpu.
If its not using your GPU at all, it should show you some virtual adapter or something along those lines:
(Answer is linux generic using “lshw”, not ubuntu-specific)
P.S. did you also try out the “catalyst legacy” drivers?
They include support for GPUs which are unsupported by the mainline catalyst
Alright, spent some time getting Fedora up to date and installing a new desktop environment, running KDE Plasma 5 now 
@zanval:
Thanks, the lshw command was not found, but there was another post in your link that gave me the right command to find out if I’m on hardware and I am yay!
I tried out your suggestion to no avail:
$ export force_s3tc_enable=true
$ echo $force_s3tc_enable
true
$ sudo /bin/sh "/home/adam/jmonkeyplatform/bin/jmonkeyplatform"
Some pertinent output from jME:
Running on jMonkeyEngine 3.0.10
Extraction Directory: /root/.jmonkeyplatform/3.0
Lwjgl 2.9.0 context running on thread LWJGL Renderer Thread
Adapter: null
Driver Version: null
Vendor: X.Org
OpenGL Version: 3.0 Mesa 10.4.7
Renderer: Gallium 0.4 on AMD RS880
GLSL Ver: 1.30
Audio Device: OpenAL Soft
Audio Vendor: OpenAL Community
Audio Renderer: OpenAL Soft
Audio Version: 1.1 ALSOFT 1.15.1
AudioRenderer supports 64 channels
Audio effect extension version: 1.0
Audio max auxilary sends: 4
and the error:
SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
com.jme3.renderer.RendererException: Image format ‘DXT1’ is unsupported by the video hardware.
at com.jme3.renderer.lwjgl.TextureUtil.getImageFormatWithError(TextureUtil.java:220)
at com.jme3.renderer.lwjgl.TextureUtil.uploadTexture(TextureUtil.java:231)
at com.jme3.renderer.lwjgl.LwjglRenderer.updateTexImageData(LwjglRenderer.java:1913)
at com.jme3.renderer.lwjgl.LwjglRenderer.setTexture(LwjglRenderer.java:1936)
at com.jme3.material.MatParamTexture.apply(MatParamTexture.java:86)
at com.jme3.material.Material.render(Material.java:1088)
at com.jme3.renderer.RenderManager.renderGeometry(RenderManager.java:523)
at com.jme3.post.FilterPostProcessor.renderProcessing(FilterPostProcessor.java:202)
at com.jme3.post.FilterPostProcessor.renderFilterChain(FilterPostProcessor.java:281)
at com.jme3.post.FilterPostProcessor.postFrame(FilterPostProcessor.java:294)
at com.jme3.renderer.RenderManager.renderViewPort(RenderManager.java:987)
at com.jme3.renderer.RenderManager.render(RenderManager.java:1029)
at com.jme3.app.SimpleApplication.update(SimpleApplication.java:252)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.runLoop(LwjglAbstractDisplay.java:151)
at com.jme3.system.lwjgl.LwjglDisplay.runLoop(LwjglDisplay.java:185)
at com.jme3.system.lwjgl.LwjglAbstractDisplay.run(LwjglAbstractDisplay.java:228)
at java.lang.Thread.run(Thread.java:745)
P.S. I had actually installed jME in Fedora 21 a couple of months ago and after having this problem uninstalled it and just continued to use it under Windows. I posted this thread because I decided to give it another go so I re-installed jME and, obviously, am still having the same issue. As a side note for some reason I have to run jME with ‘sudo’ and I don’t know why. I didn’t have to the last time I installed it and I did not install it with ‘sudo’ or anything like that. If I don’t the splash closes after it’s finished loading modules and then just returns to the terminal.
OpenGL Version: 3.0 Mesa 10.4.7
Renderer: Gallium 0.4 on AMD RS880
You are running jMonkey on the hardware, but with the open source MESA drivers.
You have to install the amd catalyst drivers to use all features of your hardware.
I just googled fglrx and fedora 21 expecting to find “yum install fglrx”. Seems fedora doesn’t officially support proprietary drivers. What the 
installing Ubuntu and running “sudo apt-get install fglrx” is probably 10 times faster >_<
Okay, now for the sudo part…
never run a graphical application with sudo. Use gksu. If you run it with sudo, it will spit UI config files into your root account and mess things up.
If you have to run jMonkey with su right, you have permission problems somewhere. Never run jMonkey as su. In general, you should never run any software with root permissions unless you know why it needs them (software installation, etc)
Easiest way is probably just to re-download JMonkey, install it somewhere where you have permissions (inside your home folder).
You probably want to create a folder for executable software installed this way (i.e. not through the systems package manager).
Thanks again @zanval very helpful and helped me to resolve that particular issue. I had been doing lots of updates last night before installing jME so I guess I got a little sudo happy and installed jME with sudo, realizing my mistake I uninstalled jME and then installed again without sudo, but after that I still needed to use sudo to run it.
It turns out that while running and/or installing jME with sudo it installed a couple of hidden folders in the /root directory. I uninstalled jME, deleted those hidden folders and also deleted the hidden folders created in my user directory then re-installed not using sudo and presto it’s working without the need of special permissions!
In addition to that I added the export force_s3tc_enable=true to my .bash_profile thinking maybe if I made it global rather than terminal session specific it would work and now it does work, jME prints out the following now:
ATTENTION: default value of option force_s3tc_enable overridden by environment.
ATTENTION: default value of option force_s3tc_enable overridden by environment.
I no longer receive errors regarding unsupported DXT1 formats! On the other hand I am now having a problem with one of my shaders that, again, worked under Windows, but not under Fedora… At least not yet:
SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
com.jme3.renderer.RendererException: compile error in:ShaderSource[name=Shaders/Shared/Animated_ScaleUV1.vert, defines, type=Vertex, language=GLSL100] error:0:16(64): error: could not implicitly convert operands to arithmetic operator
0:16(59): error: cannot construct `vec2’ from a non-numeric data type
0:16(13): error: operands to arithmetic operators must be numeric
The line in question here being:
texCoord = (inTexCoord * vec2(m_uvScaleX, m_uvScaleY)) + vec2(m_uvScaleX * m_frameX, m_uvScaleY * m_frameY);
the two uvScales are floats while the two frame variables are ints. :chimpanzee_nogood:
Here’s the whole vertex shader, pretty straightforward:
uniform mat4 g_WorldViewProjectionMatrix;
attribute vec3 inPosition;
attribute vec2 inTexCoord;
//frame size in percentage of texture
uniform float m_uvScaleX;
uniform float m_uvScaleY;
//current frame position
uniform int m_frameX;
uniform int m_frameY;
varying vec2 texCoord;
void main() {
texCoord = (inTexCoord * vec2(m_uvScaleX, m_uvScaleY)) + vec2(m_uvScaleX * m_frameX, m_uvScaleY * m_frameY);
gl_Position = g_WorldViewProjectionMatrix * vec4(inPosition, 1.0);
}Fixed it, had to edit the material definition to specify GLSL120 instead of GLSL100. All fixed up 
Yeah, mesa is very specification nazi like, while the usually windows drivers are more whateverish (especially nvidia)
Good for end users, bad for programmers
nVidia gets a bad rap for this because when you don’t specify a shader version it defaults to compatibility mode. This is because they supported GLSL shaders before there was an official spec. I guess they didn’t want to break all existing apps when the spec went final.
In JME, (pre 3.1) if you use GLSL100 as your version this is essentially saying “no version” because there is no such GLSL version. So JME leaves out the #version header (in 3.0) and thus dumps nVidia into compatibility mode.
Since I modified all of my shaders to use GLSL110 I no longer seem to have so many strange “works on my platform but not yours” compiler issues.
Keep in mind that your game now requires either this workaround or the proprietary drivers.
You no longer support the open source drivers “out of the box” now.
This is not a terrible thing, most people (especially gamers) will be running the proprietary drivers.
@zanval
I’m going to be including the jre with Carpe Diem so for Linux I was already planning on distributing with a shell script launcher, I’m assuming I can add the force_s3tc_enable line there.
@Empire_Phoenix & @pspeed
Should be good for me that Mesa is more picky, it’ll help me better understand the nuances between GLSL versions I’m sure. Thanks everyone for the assist.