There are some behaviors I prefer about mingw, but MH very recently (4-5 weeks ago) made a very awesome DX9 wrapper for Mark V and the Direct X 9 build have some advantages over the Open GL build (1: compatibility, 2: vid_vsync works on Intel video cards where it won't in Open GL).

However, in my experience mingw/gcc isn't going to like that code and possibly for Direct X 9, not even have any headers available for it?

/End random question.

The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..

The wrapper code does use some D3DX calls but it dynamically links (using LoadLibrary/GetProcAddress) to the highest numbered D3DX DLL on the client system so that it should be reasonably well immune to Microsoft's versioning game of musical chairs. Likewise with D3DCompiler.

I've no idea how any of the code I wrote would behave under gcc/mingw. Fundamentally I'm unwilling to provie assistance with bringing it up under this environment because I think gdb is a crock of shit and a good debugging environment is a non-negotiable requirement for me.

We had the power, we had the space, we had a sense of time and placeWe knew the words, we knew the score, we knew what we were fighting for

mh wrote:Fundamentally I'm unwilling to provie assistance with bringing it up under this environment because I think gdb is a crock of shit and a good debugging environment is a non-negotiable requirement for me.

No worries, since you should know I'd never ask for such assistance. I just don't roll that way.

Usually just a small hint is about as much as I ever ask for, and Spike provided the tip to unlock that door.

I try to plan ahead well in advance, even if I won't use the information in the near future.

gdb sucks for sure. But when you have stuff release-ready, the compiler is fine. Plus I love the warning messages when compiling with gcc (or clang). gcc can detect all kinds of minor problems, it is quite dreamy in that regard -- no kidding!

The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..

Ha, ha, yes, it's just that good tools are important and a really good debugger is the most important of all so far as I'm concerned. I can't even begin to tell you the number of times Visual Studio's debugger has been genuinely helpful to me. Not just in debugging, but also in design - single-stepping code with the ability to have immediate visibility over variable contents can be the most useful thing in the world. Sure you can do all this with gdb too, but it's a damn sight less productive. Visual Studio saves me time and that's time that's better spent on doing actual real work (or playing Quake).

We had the power, we had the space, we had a sense of time and placeWe knew the words, we knew the score, we knew what we were fighting for

mh wrote:Ha, ha, yes, it's just that good tools are important and a really good debugger is the most important of all so far as I'm concerned. I can't even begin to tell you the number of times Visual Studio's debugger has been genuinely helpful to me. Not just in debugging, but also in design - single-stepping code with the ability to have immediate visibility over variable contents can be the most useful thing in the world. Sure you can do all this with gdb too, but it's a damn sight less productive. Visual Studio saves me time and that's time that's better spent on doing actual real work (or playing Quake).

My non-Windows programming strategy:

1) Visual Studio first.

Try to make all code that it is humanly possible work in Visual Studio. Try to have as few dependencies as possible.

Have *ALL* project files for every platform loaded in it for search and replace convenience.

2) CodeBlocks/GCC second. Codeblocks can have Windows and Linux builds in the same file!

Because at least you are debugging on Windows. Windows is easily the most efficient operating system. You have all kinds of killer tools available while you are on Windows including Visual Studio.

Because GCC is what you will be using on Linux and Clang (Mac) is a lot like GCC in many ways, this step will catch a lot of the compile issues that non-Microsoft compilers will catch --- and they will catch quite a bit.

3) XCode on the Mac 3rd.

XCode is more friendly to debug than gdb by a wide margin. It's no Visual Studio, but if Visual Studio is a palace and gdb is sleeping bag in the middle of frozen Alaska, XCode is heated log cabin with a stove and pot to boil water.

The Clang compile will give you a million obscure warnings even gcc doesn't won't do. You may wish to ignore most of them. But some of them will be interesting gems.

4) Now debug with gdb on Linux. It's like debugging with a rock. It's not time efficient. But there is little left to do now, right?

The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..

Old mingw as in mingw.org can build D3D engines though not easily, as you pointed out it only has the bare bones api for D3D so you need to get the dx9sdk from allegro that was made specifically for mingw. mingw64 can build D3D engines from directx7 and up to directx11 with little to no trouble.

gdb while not as easy to handle as the debugger in msvc does an ok job for a console debugger, but i can understand why it might be hard on a windows programmer to use it. Sadly the only somewhat useable free gui version for windows is insight which is getting mighty long in the teeth due to not being maintained anymore.You can also use QT's gdb frontend, but its a bit irritating that you have to download several GB's of tools just to get that. Beaverdebugger was somewhat smallerand based on the QT frontend, but is no longer maintained either, also it had a few problems that made it a bit hard to use.

uploaded the fteqw port to my own site, i could not log in on quaketastic with the given password :/

Urgh, just noticed that something broke rather spectacularily, i had run clang-format on the source to try it out but i failed to see if it would still build afterwards Yeah you guessed it nope. Had to copy over an unmodified version to fix it, but gave me some time to tinker further with the new workspace atleast.

revelator wrote:...does an ok job for a console debugger, but i can understand why it might be hard on a windows programmer to use it...

It's not a matter of GUI vs console. It's a matter of functionality, integration into the code/build/test workflow, and whether or not the tool helps me to be productive.

Regarding ease of use, as one John Carmack once said on another topic:

Ease of use is damn important. If you can program something in half the time, you can ship earlier or explore more aproaches. A clean, readable coding interface also makes it easier to find / prevent bugs.

We had the power, we had the space, we had a sense of time and placeWe knew the words, we knew the score, we knew what we were fighting for

yeah it was geared towards linux use and the lack of JIT integration makes it hard to use, the unfortunate thing is that we are stuck with it if we use gcc .

One could hope that someone takes up creating something similar to msvc's debugger for gcc / clang. Xcode on windows would be a nice start, but i dont see that in the foreseeable future.SEH exceptions on 32 bit gcc are comming though

A few hours ago some random iPad happened to install Rapture from Quaddicted. Also connected to a DarkPlaces server, so the server browser works. It also downloaded the map off the QuakeOne maps depot in the process

It's the WinQuake version (haven't summoned the stamina to deal with GL yet ... combine and other stuff and I think lack of clamp_to_edge (?) will be annoyoing.). I wrote Bluetooth keyboard support so I could use the console more easily.

Unwanted challenge: Apparently, ESC on the BlueTooth keyboard exits out to the home screen on an iPad. Trying to figure out if CTRL + tilde or something should open the console, although I plan on making a hotspot on the screen.

Don't plan on requiring the BlueTooth keyboard, I'm more than happy to imitate Minecraft's very functional control layout.

Other challenges I discovered ...

1) Modal messages like the pop-up that asks "Do you want to start a new game?" Haven't decided course of action.2) ESC key annoyance.3) Whether or not to use the iPhone's on-screen keyboard or do what PSP Quake did and roll my own. I suspect I may have both be available, but have the latter as the default -- I doubt an iPhone on-screen keyboard is going to autocomplete Quake commands and allow pressing up to repeat a previous command in the history.4) I guess I'll need to hotspot up the menu items like, say, Spike does in FTE.

Fun discovery ... Quake share doesn't honor the command line. So you can't do "+map e1m1" in the command line, for instance.

Ironically, something that I would be difficult --- sound --- was completely trivial. OpenAL for sound is extremely easy. Trivially easy, really.

The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..