Developers Corner

by Shockie on 10/19/2002 16:36, 279 messages, last message: 02/04/2006 13:50, 114204 views, last view: 12/09/2021 06:37

i would like to have this thread for development problems/ideas, and what people have done. i believe it could be quite useful!

   Board Index   

#180: .

by pushplay on 07/03/2003 02:02

Has anyone else noticed that the client built with mingw is about 7 or 8 times bigger than the official exe?

reply to this message

#181: Re: .

by Thalion on 07/03/2003 10:55, refers to #180

Yes. That's because GCC is not the best compiler in the world, not even better are it's run-time libraries. And also because it is optimized for speed (I think), which GCC enforces rather aggressively, wasting enormous amount of space on it.

The official binaries were built using VC.NET - this one I have. But I think it would do even better by using Intel compiler, anyone have that?

reply to this message

#182: Re: .

by D.plomat on 07/03/2003 15:31, refers to #181

We could maybe say that gcc is one of the bests, but the windoze "platform" has a very poor POSIX and Unix levels of compatibility, so when you want to use standard unix libraries, you have to ship them with or within the binary to use them instead m$'s exotic re-implementation of the wheel...
And, using VC under *nix would be way more awful than gcc under windoze, your binaries wouldn't be even native *nix, because you'd need wine ;)

reply to this message

#183: Re: .

by Thalion on 07/03/2003 21:58, refers to #182

AFAIK, there's an Intel C++ compiler available for both Windows and Linux. Furthermore, on Windows it integrates into Visual Studio, and can serve as a complete replacement for M$VC in 99% cases (it implements all those proprietary extensions). Not sure how it behaves on Linux, but I'm pretty sure that it compiles native ELFs. Generates the best code too, last I've heard.

reply to this message

#184: Re: .

by pushplay on 07/04/2003 00:41, refers to #183

Saying windoze didn't look clever when it first started, it sure isn't going to look that way now. Same goes for M$.

I don't know what Windows not supporting posix would have to do with anything.

I haven't heard of Intel having a C++ compiler, but I'll look into it. I know the Metroworks compiler could be set to optimize for size or speed or a balance between the two (and set the level of the agressiveness of optimization). Maybe gcc has some sort of switch to do the same.

reply to this message

#185: Re: .

by Thalion on 07/04/2003 11:58, refers to #184

Intel actually sells C++ and Fortran compilers, both said to be very good. But... they aren't cheap. A demo version is available on their web site, I've tried the thing once - impressing!

As for M$ - I think it depends on a POV. For me, it's just a reflex now, it's hard to type it the other way. =)

reply to this message

#186: ..

by D.plomat on 07/04/2003 17:14

Extract from: http://www.knosof.co.uk/poschk.html

"The POSIX and C standards define two types of conformance, 1) implementation conformance and 2) application (or source code) conformance. In this paper we are interested in the latter." So are we.

-the more "binary" compatible it is, the less it would be a bloated implementation to make it source compatible, this is the explanation for your added megs in mingw-generated binary, Cygwin team did a very good job, but you can't avoid additional layers and several hacks to provide a nearly-full *nix compatible system environment on W32 <- feels better now? ;) -

Still, there's PSXSS.exe in standard, but its not very used.

You can go to:
http://msdn.microsoft.com/archive/default.asp?url=
/archive/en-us/dnarwbgen/html/msdn_posix.asp
(splitted not to enlarge the forum view witdh)
to make your totally objective opinion on wether or not it's compatible with something. OK, that's not the point.
But compatibility is to be taken as a whole. You can code an app that uses only str*() functions (even some nonstandard ones), it would compile and run on any system, but it's lot harder when it comes to larger app, interfaces with network, system, databases... if your system only have the standard C library that's really standard, you won't go very far in your portable project -or loose a bunch of time-. Apache2 for windows is way cleaner than 1.3, because it's a native binary, but it needed some code modifications. (try to call a fork() in Windows ;)
Or you can use only functions in some higher level libraries, and let them deal with platform differences but when it comes with a system call... (another exemple: PostgreSQL on redmond's OS: runs very fine, but with a full bloat of adaptation layers, IPC-daemon etc...), you can probably find many others. BTW, a compiler should be able to compile anything, be it a game, a DBMS or a system tool which is coded with POSIX+ANSI C+various libraries that are portable. Wou don't want to have a specific compiler for DBMS, another for games, another for web browser or wordprocessor ;)

I apologize Microsoft for badly spelling Windows, i won't do it again, and i'll never forget the capital on any word of a Direct* or Active* Technology.

As gcc man page says:
http://bama.ua.edu/cgi-bin/man-cgi?gcc

gcc -O0 => no speed optimisation
gcc -O3 => the most speed optimised
gcc -Os => for size (O2 except optimisations that would enlarge binary, like inlining functions)

reply to this message

#187: ...a better future for win32 users of free software?

by D.plomat on 07/04/2003 17:34

http://sources.redhat.com/ml/cygwin/2001-03/msg01875.html

reply to this message

#188: Re: ...wayyyyyyy up on the page

by Rman77 on 07/12/2003 16:24, refers to #187

This is prolly a dumb question but I’m getting an error when trying to compile the patched source by Thalion.
"In file included from cube.h:20,
from client.cpp:3:
tools.h:22:15: new: No such file or directory
<internal>: In member function `T& vector<T>::add() [with T = ivector]':
client.cpp:184: instantiated from here
<internal>:170: too many arguments to function `void* operator new(unsigned
int)'
tools.h:170: at this point in file
<internal>: In member function `T& vector<T>::add(const T&) [with T = int]':
client.cpp:185: instantiated from here
<internal>:163: too many arguments to function `void* operator new(unsigned
int)'
tools.h:163: at this point in file
<internal>: In member function `T& vector<T>::add() [with T = entity]':
client.cpp:586: instantiated from here
<internal>:170: too many arguments to function `void* operator new(unsigned
int)'
tools.h:170: at this point in file
make: *** [client.o] Error 1

This is what I did step by step because I think I forgot something
1.I installed both mingw and msys
2.edited autoexc.bat or whatever
3. Extracted thepatchedcode.zip to c:cube3d\
4.and then started up mysis and went to the src and typed make, and got the error

reply to this message

#189: Re: ...wayyyyyyy up on the page

by Thalion on 07/12/2003 17:34, refers to #188

First of all, you don't have to be in the shell (I think that's what you mean by "starting msys") to run make. Your usual command-prompt will work just as well. FAR manager users will get an additional bonus =)

As for the error - sounds like you have an old version of Mingw compiler, based on 2.95 GCC series. gcc -v?

reply to this message

#190: re way up the page

by Rman77 on 07/12/2003 18:49

I'm useing the Candidate: MinGW-3.0.0-rc-1.exe should I thought this was what was needed or am I missing something :/

reply to this message

#191: Re: re way up the page

by Thalion on 07/12/2003 19:22, refers to #190

I used version 2.0.0-31, but as long as it's GCC3 (which it is in your case), it shouldn't matter. "new" is an ANSI C++ standard header, which should be available (it's C:\MinGW\include\c++\3.2\new on my system). Most likely, your Mingw installation is not properly configured. At least, check if you have the header; if it is there, some paths are probably wrong.

reply to this message

#192: hrm

by Rman77 on 07/12/2003 19:56

looks like problem is its looking for all the include files to be in the main include directory ex: C:\mingw\include\new
instead of:
C:\mingw\include\3.2.3\new
can this be changed or should I move them to the main include directory???

reply to this message

#193: Re: hrm

by Thalion on 07/12/2003 21:06, refers to #192

Well, you can use the -I switch to tell it where to look for includes... but it should definitely search the path with C++ headers by default; and it does for me, with no additional efforts from my side. I just ran the setup program, and it configured everything. Maybe version 3 is different?

reply to this message

#194: WAHOO

by Rman77 on 07/12/2003 22:02

Finally got it to work (thanks Thalion)
Used version 2.0.0-3 instead and had no problems :)!

reply to this message

#195: Re: WAHOO

by Thalion on 07/12/2003 23:46, refers to #194

Seems like those "release candidates" aren't 100% ready for release =) Oh well.

reply to this message

#196: stupid question 2

by Rman77 on 07/14/2003 01:04

I just noticed that nothing is printed to the msdos prompt (console) with the compiled source, yet I did not see any reason this would happen looking at the source =/ help?

reply to this message

#197: Re: stupid question 2

by pushplay on 07/14/2003 02:38, refers to #196

It goes to stdout.txt. I dunno why either. There don't seem to be any references to such a file name in the source.

reply to this message

#198: Re: stupid question 2

by Thalion on 07/14/2003 11:46, refers to #197

I think it's Mingw doing that.

reply to this message

#199: Re: stupid question 2

by D.plomat on 07/14/2003 12:07, refers to #198

probably for debugging purposes... it's strange that output from mingw compiled binary goes into stdout.txt instead of STDOUT. this might be an option in mingw.
For output to the console, i see 2 uses: for development, to track some values/events/assertions, and for play, Insight's cubewrapper uses those outputs to keep track of your game's statistics.

reply to this message

   Board Index