QMB Engine goes crossplatform via SDL

Source available at: https://github.com/DrLabman/QMB

Using the SDLQuake source (http://www.libsdl.org/projects/quake/) I managed to get QMB working on Linux using the SDL libraries. SDLQuake originally only supported SDL for software rendering but I created an OpenGL version of the SDL video code for QMB.

Important information:

• I've only tested building this on Linux (Fedora 16)
• Networking isn't working yet
• Compiling (before porting to SDL) was tested on windows using MinGW + MSYS (not Visual Studio)
• Compiling (after porting to SDL) has not been tested on windows
• Expect issues?

If you give it a go let me know if it works. If you have issues post here or on github, whichever you feel like.

Nice to see you back working on your engine!

regarding networking... don't use sdlnet - it doesn't work for protocols which are not inherantly nat-safe (ie: might work for QW, but for NQ you'd have to entirely rewrite at least net_dgram.c). you're probably better off using #ifdefs to hide the bsd/win sockets api differences, or retain specific platform versions of sockets code, and depend upon net_null.c or whatever it is for weird systems.
FTE uses a single .c file for all platforms (win+lin+bsd+mac+droid). The only platform which doesn't really work for that is google's nativeclient stuff, where there's no udp support at all anyway. Yes, winsock does have some differences, but an #ifdef _WIN32 covers those, mostly with just #defines in a header file. Disclaimer: I've not made an ios port, which doesn't seem to be legally possible anyway, nor a wii/psp/etc, all of which generally require jailbreaking.

Thanks for the advice on the networking, hopefully I'll get around to that once I fix all the bugs that seem to have turned up after I thought things were working...

At first I was thinking the "QMB particle engine" and kind of confused that isn't platform locked.

Now it sunk in and I understand that you mean the QMB engine like as "Flying something pan" where something is something I can't quite remember. Sauce?

I guess is should have been more specific that it's the QMB Quake Engine that has gone crossplatform

Current site is still at: http://qmb.gluonporridge.net/

Welcome back looking forward to a new QMB loved your old one.

I guess is should have been more specific that it's the QMB Quake Engine that has gone crossplatform

I can't see crosss-platform character in this: you can't even link because the makefile doesn't know about case sensitivity for -lglee, which makes me wonder how it was compiled without issues on a fedora linux setup. Not to mention the mingw, msys and dxsdk funnies still being passed to gcc when not compiling for win32. Needs some _serious_ work, for sure.

I could compile it on Archlinux with only minor code changes (paths and one function).

I could compile it on Archlinux with only minor code changes (paths and one function).

Well, of course you can: after wrestling with the makefile which is one major incompatible element in that git repo (didn't bother looking for further.) Upon seeing something labeled as "cross platform", one would (possibly naively) expect something that really is, at least something that really compiles as advertised. Well, whatever.

I never touched the makefile, maybe I should have, no idea. Here is all I did https://github.com/DrLabman/QMB/issues/1

if you want i have a version of your 1.19 source converted to use codeblocks should make the porting easier on linux (you still need to apply your sdl code).
it also has other fixes like fix for unsafe printf buffers (bsd version of vsnprintf) infintite view matrix and underwater warping (mh's) and i cleaned up the texture code a bit + added a much later version of the tga code which handles flipped tga's correctly and supports more formats.
With codeblocks you can avoid the makefile stuff alltogether as it also works on linux and you get a quite good editor also.

Let me know if you want it ?

http://code.google.com/p/realm/download ... z&can=2&q=

uploaded the source here in case you want a look.

I'd prefer to stick with a makefile because it means, less dependencies for building. Builds are working for me, that's why I announced it, also I've only built it on one platform hence why I said 'expect issues'. There does seem to be a problem with GLee headers being in different places in different linux distributions. It's still a work in progress, but it should be minor things that need fixing not any major code changes to get a build working.

Thats ok allthough the only dependency you would need is codeblocks and packages exist for nearly every linux distro out there anyway. You can also make it spit out makefiles instead of doing them by hand, helps a great deal and when done you dont need codeblocks to build it. As for fixes the only one absolutely needed is the print buffer one as all newer gfx cards will crash unless this ones in (atleast on windows).
rest are just additions or updates.