When I work on the engine some more (likely the spring), I'll see what I can do, SpiritSpirit wrote:Huge thanks for the Linux port, Baker!
I get some sound noise/cackle when sounds are played, already tried the usual sndspeed options (11025 upto 48000) with no luck. I guess it uses ALSA, tried setting SDL_AUDIODRIVER to pulse and pulseaudio as well, no sound at all then.
Could you add -stdout to make it print all console stuff (and potentially more) to stdout/stderr? That would rule!
FitzQuake Mark V - Easy to compile and ...
Re: FitzQuake Mark V - Easy to compile and ...
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 ...
Got some of the way porting the solutions to codeblocks mingw64 but there where a few pitfalls, such as gcc not liking links to enumerators in headers.
Also the vulkan renderer crashes my PC (AMD card sigh). Atm i can build fteqw fteglqw fted3dqw fteminglqw fteqwsrv ftewkqw and the npfte.dll.
Still TODO: plugins, SDL or SDL2 renderers, and some of the tools.
MSVC 2015 is a bitch porting to, so im holding of on that one atm.
P.s i can build fteglqw with clang now
Also the vulkan renderer crashes my PC (AMD card sigh). Atm i can build fteqw fteglqw fted3dqw fteminglqw fteqwsrv ftewkqw and the npfte.dll.
Still TODO: plugins, SDL or SDL2 renderers, and some of the tools.
MSVC 2015 is a bitch porting to, so im holding of on that one atm.
P.s i can build fteglqw with clang now
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
Ok the codeblocks solution can compile all the engine types now and some of the plugins, a few of the plugins require external library support "emscripten" so to build those the user must know his way around setting up external library chains in the IDE. Also managed to get fteqtv to build and the npfte.dll. I had to mangle a few things in the sources which where plain wrong like checking for __MINGW64__ mingw64 does not and "newer" had this macro the correct way to check specifically for mingw64 is to check for __MINGW64_VERSION_MAJOR. Also gcc does not accept prototyping enumerators the way its done.
edit: seems it actually did at some point, but it was deprecated due to some problems with both types being defined no matter the arch (the grep check spike provided actually points it out nicely).
The reason it seems to work on linux and cygwin as opposed to the windows version might be that the wine sdk has it defined for backwards compatibility, ill investigate that at some point since info is a bit sketchy.
Or maybe not ? this is from a discussion with one of the mingw64 devs
https://sourceforge.net/p/mingw-w64/mai ... /24478006/
argh macro madness Oo
edit: seems it actually did at some point, but it was deprecated due to some problems with both types being defined no matter the arch (the grep check spike provided actually points it out nicely).
The reason it seems to work on linux and cygwin as opposed to the windows version might be that the wine sdk has it defined for backwards compatibility, ill investigate that at some point since info is a bit sketchy.
Or maybe not ? this is from a discussion with one of the mingw64 devs
https://sourceforge.net/p/mingw-w64/mai ... /24478006/
argh macro madness Oo
Last edited by revelator on Sun Feb 05, 2017 9:36 pm, edited 3 times in total.
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
$ x86_64-w64-mingw32-gcc -dM -E - < /dev/null |grep MINGW
#define __MINGW32__ 1
#define __MINGW64__ 1
(with both cygwin and debian's mingw64 packages)
__MINGW64_VERSION_MAJOR is probably just a header thing - note that fte checks what the toolchain is before including headers, so stuff in random system headers isn't very useful.
#define __MINGW32__ 1
#define __MINGW64__ 1
(with both cygwin and debian's mingw64 packages)
__MINGW64_VERSION_MAJOR is probably just a header thing - note that fte checks what the toolchain is before including headers, so stuff in random system headers isn't very useful.
Re: FitzQuake Mark V - Easy to compile and ...
Actually the __MINGW64_VERSION_MAJOR check is from the mingw64 devs, so its directly from the horses mouth so to say
Cant say if debian uses another approach but __MINGW64__ does not work on the windows version atleast, so i thought it better to point it out.
Cant say if debian uses another approach but __MINGW64__ does not work on the windows version atleast, so i thought it better to point it out.
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
the grep check also returns this on my windows box, but its rejected by the preprocessor if i use it, big fat error.
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
https://pcem-emulator.co.uk/phpBB3/view ... ?f=3&t=456
explains it, that macro was deprecated after gcc-4.7 but a few linux archs still use it because of compatibility with older sources, its recommended to shift to the newer version though.
more info https://sourceforge.net/p/mingw-w64/mai ... /28503245/
crist what a mess atleast theres talk about dropping these all together and just use the system _WIN32 or _WIN64 identifiers on windows, not sure what will happen with the linux versions though i suspect something similar __GNUC__ ?!?
explains it, that macro was deprecated after gcc-4.7 but a few linux archs still use it because of compatibility with older sources, its recommended to shift to the newer version though.
more info https://sourceforge.net/p/mingw-w64/mai ... /28503245/
crist what a mess atleast theres talk about dropping these all together and just use the system _WIN32 or _WIN64 identifiers on windows, not sure what will happen with the linux versions though i suspect something similar __GNUC__ ?!?
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
Like the watershader in the latest fteqw looks freaking nice.
And to the large list of comments, it was not ment as critisism i just wanted to point out that it does not work on windows and that it probably would be better to change it on linux/cygwin to when cross building.
So where do i upload the codeblocks projects to ?.
And to the large list of comments, it was not ment as critisism i just wanted to point out that it does not work on windows and that it probably would be better to change it on linux/cygwin to when cross building.
So where do i upload the codeblocks projects to ?.
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
Quaketastic?
Username and password found on first post on this page:
http://celephais.net/board/view_thread.php?id=3
Username and password found on first post on this page:
http://celephais.net/board/view_thread.php?id=3
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 ...
Does the quaddicted download thing support HTTPS? I switched to a different reverse proxy and did not add exclusions for non-encrypted connections yet. I would like to avoid that at all because everything should be encrypted.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Re: FitzQuake Mark V - Easy to compile and ...
I do a libraryless http just like, say, FTEQW! I don't even use libcurl. Which is why Mark V has no dependencies to run, just like FTE --- FTE and Mark V are the only 2 zero dependency engines in existence.Spirit wrote:Does the quaddicted download thing support HTTPS? I switched to a different reverse proxy and did not add exclusions for non-encrypted connections yet. I would like to avoid that at all because everything should be encrypted.
It is possible in the future that I do HTTPS, but it doesn't seem like a soon thing --- only an outside chance it would be this year.
I have very little time as it is.
My preference would be a different "backdoor exclusion user-agent" in the meantime -- mostly for Johhny Law who I believe is making something fancy using Mark V as an install in script files (i.e. c:\quake\mark_v.exe +install travail +quit or something like that).
Sometime in the future, I'd like to HTTPS but I'm not in a position to do it soon and maybe not even this year.
(* I'm assuming by invalidating the existing user-agent one it makes the old Quake Injector fail faster, which is probably useful to get people to upgrade to the new one.)
Thanks for the headsup!
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 ...
FTE's QI plugin etc supports+uses https in windows, so don't blame me...
however linux/other depends upon gnutls which doesn't have a very stable ABI so tends to fail to load (which then blocks all tls/https stuff, unfortunately, especially when I didn't add any fallbacks to insecure http...).
however linux/other depends upon gnutls which doesn't have a very stable ABI so tends to fail to load (which then blocks all tls/https stuff, unfortunately, especially when I didn't add any fallbacks to insecure http...).
Re: FitzQuake Mark V - Easy to compile and ...
Meh... The "Quakeinjector" user-agent will be allowed insecure connections again then.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
Re: FitzQuake Mark V - Easy to compile and ...
Okely dokeley ill upload it as soon as im back home.
Productivity is a state of mind.
Re: FitzQuake Mark V - Easy to compile and ...
I started using mint as a cross building environment, still a few hurdles setting up MXE but ill have those ironed out sometime soon.
The plan is to setup workspaces for linux / android building, so doing that on linux seemed to be the easiest way to get things right. Still going to keep the windows workspaces as well, but they are probably only going to support windows builds unless i can get around setting up the arm cross compiler on my Msys2 build chain.
The plan is to setup workspaces for linux / android building, so doing that on linux seemed to be the easiest way to get things right. Still going to keep the windows workspaces as well, but they are probably only going to support windows builds unless i can get around setting up the arm cross compiler on my Msys2 build chain.
Productivity is a state of mind.