FitzQuake Mark V - Easy to compile and ...
Re: FitzQuake Mark V - Easy to compile and ...
Here's a random question ...
Can gcc/mingw be used to build a Direct X9 engine?
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.
Can gcc/mingw be used to build a Direct X9 engine?
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 ..
Re: FitzQuake Mark V - Easy to compile and ...
mingw64 provides both d3d9 and d3d11 headers. however, you may need to write out any d3dx library stuff (on the plus side, this also isolates you from most d3d sdk changes/dependancies).
Re: FitzQuake Mark V - Easy to compile and ...
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.
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 place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: FitzQuake Mark V - Easy to compile and ...
No worries, since you should know I'd never ask for such assistance. I just don't roll that way.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.
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 ..
Re: FitzQuake Mark V - Easy to compile and ...
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 place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: FitzQuake Mark V - Easy to compile and ...
My non-Windows programming strategy: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).
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 ..
Re: FitzQuake Mark V - Easy to compile and ...
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 smaller
and 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 :/
https://sourceforge.net/projects/cbadva ... q/download
7zip can open this archive type
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 smaller
and 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 :/
https://sourceforge.net/projects/cbadva ... q/download
7zip can open this archive type
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
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.
Ill upload the new version shortly.
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.
Ill upload the new version shortly.
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
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.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...
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 place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Re: FitzQuake Mark V - Easy to compile and ...
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
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
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
Btw bakers approach is pretty much what i use myself
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
https://sourceforge.net/projects/cbadva ... q/download
there we go included new builds of everything that does not need external library support, yes plugins to.
Now to fixing msvc 2015 solutions... which means i need to fix pretty much all the solutions since they dont seem to have been maintained for some time
Btw latest codeblocks ide is quite a marvel it saves me more time than even msvc's ide itself.
there we go included new builds of everything that does not need external library support, yes plugins to.
Now to fixing msvc 2015 solutions... which means i need to fix pretty much all the solutions since they dont seem to have been maintained for some time
Btw latest codeblocks ide is quite a marvel it saves me more time than even msvc's ide itself.
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
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.
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 ..
Re: FitzQuake Mark V - Easy to compile and ...
Hehe nice Baker quite scary to think that modern phones are actually capable of running pretty highend games nowadays.
Now where did ma youth go !!! scumbags
Now where did ma youth go !!! scumbags
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
Btw baker, how would i go about loading an image via texmgr with no data width heigth and only the texture name ?
im toying with adding tenebraes particel lexer and decals to quakespasm.
im toying with adding tenebraes particel lexer and decals to quakespasm.
Productivity is a state of mind.