I compiled TASpring and all of its dependencies (i.e. boost, glew, openal, etc.) on a Slackware 10.1. Of course I also had to install a recent GCC.
After some pain in configuring the scons scripts I was able to finally obtain a working version of the game, but here came the nastiest problem: all the maps are shown with a white texture (completely white). No missing OpenGL primitives errors are given.
By seeing previous posts on some TASpring-related forums I see someone already had the same problem and, in my understanding, the most probable cause maybe an error related to the graphics driver I compiled for the card on my laptop. In particular it seems there may be a problem loading the compressed map textures, but I've never seen any practical suggestion to solve it.
Of course the problem could also be in a wrong configuration file.
Could anyone aware of the problem post his observations/possible solutions?
white maps
Moderator: Moderators
-
jabberwock
- Posts: 3
- Joined: 18 Sep 2006, 08:23
unfortunately, the reply given from the command glx is "Yes", so direct rendering is surely enabled.
Morevoer, I tried to test the windows spring binary through wine , still obtaining the same result (white maps).
The same executable launched windows with the same hardware (I must admit I have a dual boot machine) works well, so the problem is probably related only to the software layer between the hardware and the application.
Morevoer, I tried to test the windows spring binary through wine , still obtaining the same result (white maps).
The same executable launched windows with the same hardware (I must admit I have a dual boot machine) works well, so the problem is probably related only to the software layer between the hardware and the application.
-
jabberwock
- Posts: 3
- Joined: 18 Sep 2006, 08:23
of course,
the lspci | grep VGA output is:
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
If I remember well the specific chipset is the 915G.
The driver is the one included in xorg 7.0, downloaded and compiled from me (of course with mesa).
DRI and DRM work both well:as i said in aprevious post glxinfo tells me so. Moreover I played to the 3D game nexuiz and glxgears run in a maximized window at about 120 fps.
I found Intel released a specific version of xorg 6.9 aimed for the use with my graphic chipset... I'll try it as soon as I will be albe to and, hopefully, I'll post any result.
the lspci | grep VGA output is:
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
If I remember well the specific chipset is the 915G.
The driver is the one included in xorg 7.0, downloaded and compiled from me (of course with mesa).
DRI and DRM work both well:as i said in aprevious post glxinfo tells me so. Moreover I played to the 3D game nexuiz and glxgears run in a maximized window at about 120 fps.
I found Intel released a specific version of xorg 6.9 aimed for the use with my graphic chipset... I'll try it as soon as I will be albe to and, hopefully, I'll post any result.
Re: white maps
I saw the same thing with my AIW Radeon 7200 (r100 core, 32MB RAM) on an Athlon64 3200+ w/ 1.5GB of RAM, running Debian unstable (xorg 6.9, then 7.0, now 7.1). I searched for info on s3 texture compression with xorg, and found http: // homepage.hispeed.ch/ rscheidegger/dri_experimental/s3tc_index.htmljabberwock wrote:I compiled TASpring and all of its dependencies (i.e. boost, glew, openal, etc.) on a Slackware 10.1. Of course I also had to install a recent GCC.
After some pain in configuring the scons scripts I was able to finally obtain a working version of the game, but here came the nastiest problem: all the maps are shown with a white texture (completely white). No missing OpenGL primitives errors are given.
(sorry, forum spamfilter blocks URLs, so I added spaces)
The trick is to use driconf to turn on support for pre-compressed textures. You can compile up the library to provide proper support for compressing textures, but spring map textures seem to be pre-compressed.
That didn't seem to fix the fact that all unit surfaces were all white, too, except for the XTA flea. I think a 32MB vid card just isn't enough with those drivers. (not that there are others for that hardware). Playing with other driconf options, specifically the one controlling what it does with large textures, made it display, but locked the machine consistently
, esp. on larger maps or once more different units were built. Things looked kind of streaky with it set to allow all textures regardless of being too big. It may have worked better if my kernel DRI driver had matched the xorg driver, since there was a message in Xorg.0.log that the DRI revisions didn't match. Then it could use more than 64MB of AGP memory, which might help, but the card is probably just too slow to be useful.I also have an old laptop w/ a P4M 1.7GHz, 512MB of RAM and a 32MB GeForce 440 Go. Using the proprietary binary-only Nvidia drivers works pretty well, and it does ok on 16x16 maps. Occasionally it can turn all the unit textures black, probably when it runs out of texture memory. That only happens after the frame rate drops to unplayable levels (< 7FPS). Even on some 20x20 maps, it's just too slow (<10 FPS). A desktop with a GeForce 2 MX 400 (64MB of RAM) seems to do pretty well. So yeah, Spring seems to need > 32MB of video RAM except on smallish maps.
My mom's laptop w/ an Intel 945G graphics chip didn't seem very fast when I tried Spring on it (under WinXP), even though it has a pretty fast P-M CPU. Maybe it wasn't reserving very much RAM for video. Good luck with yours, but be aware that Intel 3D hardware isn't very fast. You can change the amount of memory that the video hardware takes from the main system memory by setting
VideoRAM 65536
or somthing in the "Device" section of your xorg.conf.
--
Peter Cordes