InsideQC Forums

reckless wrote:

MinGW headers don't exactly match the MSVC ones

If you use the standard mingw distro thats unfortunatly right, its also the reason i changed to the mingw64 compiler since there runtime match msvc headers much closer
(but it also creates a few incompatibilities at times with sources built for the standard mingw distro, just to warn you not to take for given that everything made for mingw will compile out of the box on mingw64).

I can offer my help converting your sources to my version of C::B if you like ?.

and dont let the mingw64 name scare you my compiler can also make 32 bit executables

I'd love to have the source converted. I'm using 64bit, too.

a 64 bit build should be possible but there are a few quirks. int's etc dont have the same size so we use intptr_t etc.

i converted most of bsp allready to C::B + mingw64 but theres one item im having a bit of trouble with ->

this part in utils.h throws an error

inline ~list() {
reset<T>();
};


error: no matching function for call to 'list<setinfo_value*>::reset()'

also it rears its head later on in the compilation. Starting to wonder if gcc's headers declare reset as something else ?.

ok i nailed why the C++ headers bark on mingw. recent mingw (gcc4) uses a much stricter checking than old version (gcc3) so a lot and i mean a lot needs to be changed. the good thing though is that it will most likely make it a whole heap more stable.
you could also get the old gcc based mingw compiler and it would probably work allmost out of the box if you have the missing items like the directx sdk for mingw.

example of things that barf on mingw gcc4

template <typename T> you cannot use that inside a class instead use template<T> its ok outside a class though.

or this

class somename {
somename::somefunction;
}

is also bad, it needs to be

class somename {
somefunction;
}

or you get extra qualification errors.

besides that gcc4 really doesnt like anonymous types all class calls must have matching function types.

you can get around some of the nasties by using -fpermissive in the compiler flags but you will most likely run in to problems later on.

I know about these errors. The class templates need to be renamed as T1, T2. That's what I did in my source to get rid of the errors. Also, documentation says that you cannot declare a class with name T (for example) inside another class with the same name (T). That file, util.h has some ugly code inside.

very very ugly indeed im fixing as much as i can also but a few places i might need a hand from the gcc guys. lets see how it goes down.

ok first working version finished do you have somewhere i can mail it to you ? or is it ok to make public.

reckless wrote:ok first working version finished do you have somewhere i can mail it to you ? or is it ok to make public.

Sent you a PM. Not going public yet. This should be golden_boy's decision. I'm only using it for my personal project.

Oki uploaded.
Lets hope GB likes this

If he approves theres loads to be done still
a lot of the c++ code uses deprecated functions and while i am able to compile a 64 bit executable it refuses to run (beforementioned types that dont fit a 64 bit arch).
so if it where open to the community the work would be done in a snap im sure .

Next build cleaned a bit more and libpng\zlib now linked static. Libpng and zlib was updated to a later version. Changed build version to 0.96e.

It is Yahn's editor, in the end.

My last email might have gotten caught in Valve's spam filter. I just mailed Yahn again and asked if it was OK to host the code somewhere and what the license would be.

Last time he replied pretty quickly...

I see you have made good progress. Do you have a repo set up?

If not, icculus would probably host it.

If we hear nothing from Yahn until Sunday, I'd say go on and upload what you have to Quaketastic or whatever.

What source is your new stuff based on? The Paintball one? ViciouZ' one? Or version 96d by Sort?

goldenboy wrote:What source is your new stuff based on? The Paintball one? ViciouZ' one? Or version 96d by Sort?

Allow me to answer that, it's ViciouZ' one. It's the same one you already have.

Good.

no repo yet, i wanted to wait untill everything was clear with yahn.
code is now fully mingw compatible, took me most night but it compiles without -fpermissive now and i fixed all the warnings.
it runs and seems to work ok besides one little bugger. the optimized builds cannot open pak files still investigating.

heh the pak problem is actually not a bug but a glitch it seems. if the game dir is where it should be it works but if selecting a pak that is not in the path in its ini then it fails. funny thing though the debug version disregards that.
I skimmed the code and it might be of interrest for mh. here i think of a built in quake editor. the code is in C++ and should be adaptable to his directq source theres a ton of unfinshed code though which im cleaning up atm (mostly related to lua scripting).
also a few places with disabled code that didnt work or didnt work well question is should i leave it so someone can fix those or would it be better to start fresh on those `?

I'm not personally interested in an integrated Quake editor (I don't view DirectQ as either a mappers or a modders engine) but it would be a neat project for someone who is.