[$threadinfo[title]]

[Gonetz]

I'm trying to build new version of Glide64 with GCC.

Tools:
NASM
MinGW
Dev-C++

Problem:
Resulted dll does not work.

Symptoms:
When project type is 'Win32 DLL', emulators just don't see the plugin.
When I set project type as 'Win32 Console', set Linker parameters '-shared' and rename result from *.exe to *.dll, resulted dll is initialized by emulators, but actual call of any function causes crash.
Stripping Glide64.dll with strip.exe does not help.

Can anybody create for me Dev-C++ project for Mupen64Plus version of Glide64? I need to know, which options are actually needed to build N64 video plugin for windows emulators with GCC. I'm not familiar with GCC and makefile format, but with Dev-C++ I can see in which direction to dig.

Another question: which NASM output format to use with GCC for windows? For MSVS I use '-f win32', the result works with GCC too, but it's probably better to use another format? Elf does not work.

[Slougi]

I suspect that WIN32 DLL is the right type. Are you sure you are marking your DLL entry functions (those defined in the gfx spec) correctly for export/import? The syntax between GCC and MSVC is different, see here (http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Function-Attributes.html#Function-Attributes). Look for dllimport/dllexport.

Note: I am not intimately familiar with the whole windows linking system (it is weird viewed from a unix perspective).

[Slougi]

Another question: which NASM output format to use with GCC for windows? For MSVS I use '-f win32', the result works with GCC too, but it's probably better to use another format? Elf does not work.

I strongly suspect you want -f win32 regardless of the compiler.

[Pyromanik]

I recommend diging through the (vanilla) Mupen64 v0.5 source, specifically at the RSP plugin to see how it compiles using Dev-C++.
Here you can see all the entry points for opening the DLL and you can also inspect how it is set up within the environment.

Also be aware that the GCC version bundled in with Dev-C++ is somewhat old and deprecated. This may be giving you issues.

[h4tred]

And Gonetz, if you want a more updated GCC:

http://www.tdragon.net/recentgcc/


Thats what I use. Much better than the trash in Dev-C++.

Plus, Dev-C++ is outdated, you could try Code::Blocks. That supports loading Dev-C++ projects too.
--mudlord

[Gonetz]

I recommend diging through the (vanilla) Mupen64 v0.5 source, specifically at the RSP plugin to see how it compiles using Dev-C++.
Here you can see all the entry points for opening the DLL and you can also inspect how it is set up within the environment.
I'll try it, thanks

Also be aware that the GCC version bundled in with Dev-C++ is somewhat old and deprecated. This may be giving you issues.
Dev-C++ is just is a wrapper over MinGW binaries, and MinGW GCC in particular. Since my MinGW version is not very old, GCC should be quite fresh too.

[Gonetz]

I suspect that WIN32 DLL is the right type. Are you sure you are marking your DLL entry functions (those defined in the gfx spec) correctly for export/import? The syntax between GCC and MSVC is different, see here (http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Function-Attributes.html#Function-Attributes). Look for dllimport/dllexport.


dll export is defined as
#define EXPORT __declspec(dllexport)

The document you pointed says:
"dllexport:
...
You can use __declspec(dllexport) as a synonym for __attribute__ ((dllexport)) for compatibility with other compilers."

Thus, there should be no problems.

I tried to check my dll with Dependency Walker. This tool shows all exported functions - all are there. But emulators can't call them.

[Richard42]

I tried to check my dll with Dependency Walker. This tool shows all exported functions - all are there. But emulators can't call them.

One likely cause for this problem is that the glide64.dll itself may have dependencies on other libraries (SDL, opengl, etc) which cannot be satisfied at load time. This happens a lot for mupen64plus with our blight input plugin; if a user doesn't have the SDL_ttf package installed (which is a dependency for the blight input plugin), then the plugin won't even show up in the drop-down list.

IIRC, dependency walker should flag any unresolved dependency in red.

[Pyromanik]

Dev-C++ is just is a wrapper over MinGW binaries, and MinGW GCC in particular. Since my MinGW version is not very old, GCC should be quite fresh too.

No, I don't think you understand...

Dev-C++ comes with it's own localized copy of GCC, which it will use even if you have a system wide install. Unless you do some tricky business to tell it otherwise. This is extremely old and very depricated (being that Dev-C++ itself hasn't been updated in about 8 years).

Also the most recent stable ports of GCC by mingw are still in version 3, which in itself is old. To get the mingw gcc version 4 alpha you need to get the manual install file from their sourceforge page.

"GCC Version 4 Testing: gcc-4.3.0-20080502-mingw32-alpha"



But I suggest your problem is probably more with your DLL entry points and environment setup rather than the compiler. Otherwise as Richard said, it's probably a runtime problem rather than compile time.

[h4tred]

Also the most recent stable ports of GCC by mingw are still in version 3, which in itself is old. To get the mingw gcc version 4 alpha you need to get the manual install file from their sourceforge page.

"GCC Version 4 Testing: gcc-4.3.0-20080502-mingw32-alpha"

The site I linked to, is more up to date, and its even maintained by a MinGW dev.....And I had zero problems in using it for development.

[Gonetz]

Dev-C++ comes with it's own localized copy of GCC, which it will use even if you have a system wide install. Unless you do some tricky business to tell it otherwise.
Actually "Bloodshed Dev-C++ is a full-featured Integrated Development Environment (IDE) for the C/C++ programming language. It uses Mingw port of GCC (GNU Compiler Collection) as its compiler." There is distributive of Dev-C++ version 4.9.9.2, without Mingw compiler system, which I use.

The problem is not because of compiler version. Actually, GCC version is working. Crash is because of wxWidgets library, which I use for system-dependent stuff. Functions, which do not use wxWidgets objects, work ok.
Check this for details:
http://wxforum.shadonet.com/viewtopic.php?t=23766

[Gonetz]

The site I linked to, is more up to date, and its even maintained by a MinGW dev.....And I had zero problems in using it for development.
I downloaded and installed this package along with Code::Blocks, thanks!
I rebuilt everything with newer version.
Nothing changed, as expected.

[Pyromanik]

The site I linked to, is more up to date, and its even maintained by a MinGW dev.....And I had zero problems in using it for development.

Oh yup, cool.
Thanks mudlord.

[Gonetz]

I solved the problem (mostly). DLLMain must be declared as "C" function to be called by MinGW. Stupid rake.
Now GCC build works with 1964 and Mupen64. Pj64 crashes though.
Anyway, Glide64 sources are GCC ready and can be ported to other platforms.

[smcd]

Awesome news, thanks for fighting that battle :)

[Pyromanik]

Sweet, good work!
Thanks Gonetz!

or should that be "спасибо"? :)

[h4tred]

Just a notice.

Gonetz and I are working more on porting the wrapper to Unix.

I recently started work on porting the VRAM detection to SDL for Mac/Linux. Though, there is the issue with the wrapper specific extension used for Windows configuration of it.

Just wondering with the source of Mupen64Plus to clarify, how did the Linux port work around that issue?

[Gonetz]

I've an issue with Linux port.
When I run Mupen64Plus, it says
"Couldn't load plugin 'Glide64.so': /home/lipski/Mupen64Plus-1-5-bin-32/plugins/Glide64.so: undefined symbol: DetectSIMD"

DetectSIMD is an asm function, which is in 3dmathSIMD.asm, compiled with "nasm -f elf".
Any ideas, what can cause this? I use the following makefile:

.PHONY: all clean realclean

DLLNAME = Glide64.so

EXT_INC = ./inc
EXT_LIB = ./lib

CC = g++
STRIP = strip
CFLAGS = -DBUILDING_DLL=1 -fexceptions -D__unix__
CFLAGS += -ffast-math -funroll-loops
CFLAGS += -I. -I$(EXT_INC) `wx-config --cppflags`

ifdef DEBUG
CFLAGS += -DDEBUG
endif

LD = g++
LDFLAGS = -shared -lstdc++

LDLIBS = -L"." -L"lib" $(EXT_LIB)/3dmathSIMD.o $(EXT_LIB)/FixedPoint.o $(EXT_LIB)/Texture.o $(EXT_LIB)/glide3x.so `wx-config --libs`

RM = rm

SOURCES = \
3dmath.cpp \
Combine.cpp \
Config.cpp \
CRC.cpp \
Debugger.cpp \
DepthBufferRender.cpp \
Ext_TxFilter.cpp \
FBtoScreen.cpp \
Main.cpp \
rdp.cpp \
TexBuffer.cpp \
TexCache.cpp \
Util.cpp

OBJECTS = $(SOURCES:.cpp=.o)

.cpp.o:
$(CC) -o $@ $(CFLAGS) -c $<

all: $(DLLNAME)

$(DLLNAME): $(OBJECTS)
$(LD) -o $@ $(LDFLAGS) $^ $(LDLIBS)
#$(STRIP) -R .comment $@

clean:
-$(RM) *.o

realclean: clean
-$(RM) $(DLLNAME)

-include depend

[Richard42]

I've an issue with Linux port.
When I run Mupen64Plus, it says
"Couldn't load plugin 'Glide64.so': /home/lipski/Mupen64Plus-1-5-bin-32/plugins/Glide64.so: undefined symbol: DetectSIMD"

DetectSIMD is an asm function, which is in 3dmathSIMD.asm, compiled with "nasm -f elf".
Any ideas, what can cause this? I use the following makefile:


One possible cause for this type of problems is that Win32 and Unix have different conventions for C function naming. Windows uses a preceding underscore, while Linux does not. So you need a macro in your .asm file to correctly define the function names, depending upon the target OS. The functions also need to be declared global in the ASM file, but that's true for both Win and Linux.

[Gonetz]

Yes, the problem was caused by a preceding underscore. Thanks!
Now the plugin is attempting to load.

[Gonetz]

Could you explain me, how plugins are initialized under Linux? I need to start wxWidgets on dll load. For windows port it is done in DllMain function, which is automatically called when dll is loaded.

[smcd]

There are functions that you can use named _init and _fini that are called when loaded/unloaded for linux shared objects .so is that what you mean? The compiler attributes __attribute__((constructor)) and __attribute__((destructor)) might also be used but I'm not really familiar with those

[Gonetz]

I've reproduced DllMain behavior, and I see in my log file that wxWidgets initialization was successful, but plugin still crashes on load. I need to debug it. I'm not familiar with Linux IDE. Has anybody KDevelop or Anjuta project for MupenPlus version of Glide64?

[Funto]

If by "crash" you mean "segfault", you had better use the powerful tool that Valgrind is :)

[Gonetz]

I don't know, what happens. There are few error messages:

(process:2292): GLib-GObject-CRITICAL **: /build/buildd/glib2.0-2.20.1/gobject/gtype.c:2458: initialization assertion failed, use IA__g_type_init() prior to this function

(process:2292): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

(process:2292): Gdk-CRITICAL **: gdk_cursor_new_for_display: assertion `GDK_IS_DISPLAY (display)' failed

after which mupen loading hangs. I just want to run it in a debugger and get the call stack. So far I have no idea, where to dig.

[Funto]

If Mupen64Plus segfaults, Valgrind can give you the call stack (better if you compile with the -g option for debugging).

If you want to run it step by step in a debugger, personnaly I use GDB through the Code::Blocks IDE for this.

[Gonetz]

I fixed this particular issue. It was my bug.
Now I have to fight with wxWidgets issues - it crashes on some basic stuff.
I even managed to load the plugin with some hacks and get GUI working, but when I start a rom it crashes (segfaults) during some initialization routines. It seems that memory became corrupted, because it crashes where nothing wrong can be.

[Tillmann]

why don't you try to use gdb? Just run "gdb /pathtomupen/mupenplus64" and then start to use when it crashes look at the traceback output.

Simple and good debbuger :D (it will pinpoint problems with your plugin for sure)

[h4tred]

Sorry Gonetz about me being busy, I've been busy on a big reverse engineering project, as well as other things.

I even managed to load the plugin with some hacks and get GUI working, but when I start a rom it crashes (segfaults) during some initialization routines. It seems that memory became corrupted, because it crashes where nothing wrong can be.


Sure its purely a wrapper problem or a plugin problem? I know certainly the Unix VRAM detection code could do with tuning (since I did a completely non tested implementation)...could that mess with memory allocation perhaps?

[Gonetz]

I use Nemiver for debugging. It shows me the callstack, values of variables, but now I'm in the point, where I just can't understand, how segfault can happen in this place:
void debug_init ()
{
debug.capture = 0; <-- crashed on this line

[Gonetz]

Sure its purely a wrapper problem or a plugin problem?

I know only that it is crashed inside the plugin.

I know certainly the Unix VRAM detection code could do with tuning (since I did a completely non tested implementation)...could that mess with memory allocation perhaps?
Hmm, I may try to build the wrapper without VRAM detection code to be sure.

[Tillmann]

I use Nemiver for debugging. It shows me the callstack, values of variables, but now I'm in the point, where I just can't understand, how segfault can happen in this place:
void debug_init ()
{
debug.capture = 0; <-- crashed on this line

Well i've never used this program, but this output really do not says nothing at all (besides The init problem) maybe if you try gdb (pretty polished software) you could trace what is going on...

[Gonetz]

"Nemiver is an ongoing effort to write a standalone graphical debugger that
integrates well in the GNOME desktop environment. It currently features a
backend which uses the well known GNU Debugger gdb to debug C / C++
programs." That is, it is just gdb shell. Using pure gdb will give me nothing more.

[h4tred]

I know only that it is crashed inside the plugin.

Okay, I thought it was caused by something I did :P.

Hmm, I may try to build the wrapper without VRAM detection code to be sure.

I do intend though on completely testing out that SDL code with a test case I have, so that Unix code should be fixed when I get time. But I guess using a hardcoded value when your testing your port wouldn't hurt.

[Gonetz]

If by "crash" you mean "segfault", you had better use the powerful tool that Valgrind is :)

Is there any good front end for it? When just running valgrind mupenplus, it outputs to console, where it hard to read.

[Richard42]

Is there any good front end for it? When just running valgrind mupenplus, it outputs to console, where it hard to read.

Valgrind isn't an interactive tool like a debugger. The idea with Valgrind is that you can run it with "valgrind --leak-check=full ./mupen64plus" and then after you're done with the test case, look through the list of warnings and errors that it dumps out. It can dump the info out in XML format, and you can use a GUI front-end for parsing the XML and displaying it in a slightly more pretty format, but it's really not worth the trouble.

As far as debugger front-ends, DDD is an old X application that sits on top of GDB for debugging. It's not terribly pretty but it has a lot of features and works well.

[Gonetz]

MacOsX link error:

g++ -o glide3x.so -shared -lstdc++ combiner.o geometry.o main.o textures.o SDLMain.o -L"." -L"lib" -framework OpenGL `sdl-config --libs` --out-implib=libglide3x.a
Undefined symbols:
"_SDL_main", referenced from:
-[SDLMain applicationDidFinishLaunching:] in SDLMain.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [glide3x.so] Error 1

SDLMain.o is built from SDLMain.m for MacOs. Without it linker error is:
Undefined symbols:
"_SDL_main", referenced from:
-[SDLMain applicationDidFinishLaunching:] in libSDLmain.a(SDLMain.o)
ld: symbol(s) not found

What's wrong?

[Gonetz]

Found: the code must have int main(int argc, char*argv[]) procedure. I wonder, how you managed to compile the wrapper on MacOs without it?

[h4tred]

Not entirely sure in how MacOSX dynamic libs operate, sorry :(


http://developer.apple.com/DOCUMENTATION/DeveloperTools/gcc-4.0.1/gcc/Link-Options.html

Its funny: MacOSX's version of GCC does not support -shared.......

[Gonetz]

Found: the code must have int main(int argc, char*argv[]) procedure. I wonder, how you managed to compile the wrapper on MacOs without it?
!!!:angry:
Now I have:
ld: in ./lib/glide3x.so, can't link with a main executable

[h4tred]

I know, its batshit crazy under Mac..........

http://www.dreamincode.net/forums/showtopic42363.htm

That explains how to do dynamic libs under MacOSX.

[Gonetz]

Thanks! At least I built it.

[h4tred]

Yay! :D

Now we need it to load....I finally got a full Linux dual boot setup up and running, complete with Wine and Code::Blocks for Linux. Plus the newest Mupen64Plus for testing reasons....

[Gonetz]

So far I can't load it. This Mac does not belong to me, and it does not have GTK installed because of conflicts with mc. I can't run Mupen without GTK.
I asked the owner to fix it, but I will take time.
In any case, it's too early to get excited. I'm fighting with Linux port for a few days, and it already fuc*d me to death.

[h4tred]

Well, if it makes you happy....finally fixed and commited the Unix/Mac VRAM detection.

It outputs the same expected output as the Windows version. Expects a HW accelerated rendering context though when detecting, since thats how the video RAM detection in SDL works.

[Slougi]

SDL on mac is a little weird.

In the SDL headers there is a line like this:
#define main SDLMain

SDL defines its own main function, that then calls your main, which got its name redefined as SDLMain. You do not need that for plugins, don't link to SDLMain.

[Gonetz]

MacPort: plugin loaded, GUI works, but when I open config dialog, message window with Mupen logo appears: "Error, Failed to read config options". Moreover, my plugin can't read its ini file. I tried everything. Without ini it can't work properly. Are there any tricks with config load on Mac port?

PS At least my code does not crash in weird places, as on Linux.

[Slougi]

PS At least my code does not crash in weird places, as on Linux.
It would help if you would elaborate on those crashes.

[Gonetz]

It seems that crashes are caused by bugs in g++ compiler. Current version is 4:4.3.3. I switched to 4.2 – the result became much more expected. Now I met the problem, which is outside Glide64. Details:
main_gtk.c, 83

void gui_init(int* argc, char*** argv)
{
/* Initialize multi-threading support. */
g_thread_init(NULL);

This call causes “GThread-ERROR **: GThread system may only be initialized once.
aborting...”

gui_init is called after plugins load. Glide64 calls wxWidgets initialization on load. wxWidgets use GTK. I guess, threads are already initialized by wxWidgets, which caused this error. How it can be resolved?

Edit:
Solution:
void gui_init(int* argc, char*** argv)
{
/* Initialize multi-threading support. */
if (!g_thread_get_initialized())
g_thread_init(NULL);

Please fix it in official Mupen64Plus sources too.

[Gonetz]

Report: Linux port - GUI is fully functional. System hangs on rom load – reboot needed. Need mudlord’s help.

MacOs port: GUI itself works. Can’t load ini file. Hangs on rom load. Crash on exit.

[h4tred]

Thanks for the heads up Gonetz.

I'll see what I can arrange. I know the issue with getVRAMSize for Unix:
http://www.libsdl.org/faq.php?action=listentries&category=2#20

We must set it by hand for Unix systems D:.

[Slougi]

It seems that crashes are caused by bugs in g++ compiler. Current version is 4:4.3.3. I switched to 4.2 – the result became much more expected. Now I met the problem, which is outside Glide64. Details:
main_gtk.c, 83

void gui_init(int* argc, char*** argv)
{
/* Initialize multi-threading support. */
g_thread_init(NULL);

This call causes “GThread-ERROR **: GThread system may only be initialized once.
aborting...”

gui_init is called after plugins load. Glide64 calls wxWidgets initialization on load. wxWidgets use GTK. I guess, threads are already initialized by wxWidgets, which caused this error. How it can be resolved?

Edit:
Solution:
void gui_init(int* argc, char*** argv)
{
/* Initialize multi-threading support. */
if (!g_thread_get_initialized())
g_thread_init(NULL);

Please fix it in official Mupen64Plus sources too.

Seems like a simple work-around. Does the same thing happen with the qt4 gui?

[Slougi]

Thanks for the heads up Gonetz.

I'll see what I can arrange. I know the issue with getVRAMSize for Unix:
http://www.libsdl.org/faq.php?action=listentries&category=2#20

We must set it by hand for Unix systems D:.

Can you elaborate on the issue? The FAQ you linked to does not talk about VRAM.

[Slougi]

It seems that crashes are caused by bugs in g++ compiler. Current version is 4:4.3.3. I switched to 4.2 – the result became much more expected.

That seems unlikely. What kind of code was causing the problems?

[h4tred]

The issue is very simple: a means to detect VRAM size via SDL.

The info from those methods currently return 0 under linux. It should however output the VRAM size. That could account for the crash, as the wrapper needs that information for memory allocation purposes.

Or, as I was suggesting, make the user select how much RAM thier video card has. According to the page I linked, the VRAM detection methods are very specific in how they operate and certain conditions must be fufilled for SDL VRAM detection not to return 0. Hence why I brought it up.

[Slougi]

The issue is very simple: a means to detect VRAM size via SDL.

The info from those methods currently return 0 under linux. It should however output the VRAM size. That could account for the crash, as the wrapper needs that information for memory allocation purposes.
Hmm, what exactly do you do with the vram info? You never get to use the full amount anyway on modern desktops. Maybe the easiest way is to assume a certain amount, and let the user increase it if there is an advantage to this.

Or, as I was suggesting, make the user select how much RAM thier video card has. According to the page I linked, the VRAM detection methods are very specific in how they operate and certain conditions must be fufilled for SDL VRAM detection not to return 0. Hence why I brought it up.

The link was talking about 2D surfaces. Because X is fundamentally a network protocol, direct access to VRAM cannot be presumed. There is a deprecated extension to X called DGA that provides direct access to the framebuffer for applications that run on the same machine as the X server. As I said though, the extension is deprecated and will soon be removed. AFAIK DGA never worked in conjunction with 3D graphics anyway.

[h4tred]

Hmm, what exactly do you do with the vram info? You never get to use the full amount anyway on modern desktops. Maybe the easiest way is to assume a certain amount, and let the user increase it if there is an advantage to this.

Basically, the wrapper tries to emulate a Voodoo 5. This includes emulating how the texture units work. The VRAM size is used along with other things to calculate the size of a emulated TMU. So, its part of the wrapper's basic design.

The idea behind the automatic VRAM detection was to allow the end user not to select the VRAM usage themselves for conveniance. I guess now we can just get them to set a personal buffer size, since the wrapper works well on cards with 64MB VRAM and up.

The link was talking about 2D surfaces. Because X is fundamentally a network protocol, direct access to VRAM cannot be presumed. There is a deprecated extension to X called DGA that provides direct access to the framebuffer for applications that run on the same machine as the X server. As I said though, the extension is deprecated and will soon be removed. AFAIK DGA never worked in conjunction with 3D graphics anyway.

Ah thanks, no wonder the function's returning null. :(

[Slougi]

Basically, the wrapper tries to emulate a Voodoo 5. This includes emulating how the texture units work. The VRAM size is used along with other things to calculate the size of a emulated TMU. So, its part of the wrapper's basic design.

The idea behind the automatic VRAM detection was to allow the end user not to select the VRAM usage themselves for conveniance. I guess now we can just get them to set a personal buffer size, since the wrapper works well on cards with 64MB VRAM and up.

Right. If I may, I'd suggest just defaulting to 64MB and let the user raise it if there is a need.

Keep in mind that on composited desktops with 3D effects, a large chunk of the VRAM is in use anyway to hold window contents for compositing. This is probably true on Windows >= Vista and OS X as well.

[Gonetz]

Seems like a simple work-around. Does the same thing happen with the qt4 gui?
Work-around? It is common practice to check, is something already initialized before initialize it. Did not try qt4 gui.

[Gonetz]

That seems unlikely. What kind of code was causing the problems?
Who knows? When I compile my sources with current version, it works weird. When I switch to 4.2 it works as expected. The same sources, the same compiler options in the same makefile.

[h4tred]

Verified.

From what I seen, GCC 4.3 in Ubuntu is buggy, period.Like, I seen other projects run into problems with the newest GCC.

[h4tred]

http://www.emuxhaven.net/forums/showpost.php?p=80801&postcount=239

:).

[Surkow]

Great news! Are there still any unresolved issues? I'm looking forward to its release.

[h4tred]

Well, tonight I added fullscreen support to the wrapper. And it seems to work great so far.

So, I think the major issues are now fixed. :)

[Pyromanik]

Great stuff!

[h4tred]

All thats left now it seems is the GlideHQ issues. Can't say much about them, other then they are just plain weird o.o

[KoolSmoky]

All thats left now it seems is the GlideHQ issues. Can't say much about them, other then they are just plain weird o.o

Hi :) I'll try to find some time to look into the issue. My bet is that there is something wrong with the newer libpng's. Last time I checked, GlideHQ worked under Linux without a glitch, but that was over half a year ago. Meanwhile, if you have some time, please check bmp texture loading and see if we can isolate this as a png issue? Thanks.

-KoolSmoky

[h4tred]

Coolness. Gonetz is interested in contacting you about the GlideHQ issue, as it seems to be the last issue we have with the current Linux portage (I already ported the fullscreen resolution stuff to Linux using SDL).

At the moment, Gonetz and I are stumped, so any help you can give would be great with this port.

[h4tred]

Nope, BMP textures won't load. Textures won't dump. Only thing that works is the filters/texture caching.

[KoolSmoky]

Nope, BMP textures won't load. Textures won't dump. Only thing that works is the filters/texture caching.

Thanks for the info. It turns out that this is a case sensitivity issue. The file names' letter case must be used as is dumped by the gfx plugin. It must be one of the following; *_a, *_rgb, *_all, *_allciByRGBA, *_ciByRGBA, *_ci and file extensions must be in lower case letters. I've committed a quick fix to the SVN. No one should screw with the letter case, period. Note that some texture packs completely ignore this, so those packs will not load.

-KoolSmoky

[h4tred]

Excellent, now the Glide64 Napalm Linux port works perfectly.