pouët.net

Eclipse is neat apart from the slow auto-complete stuff. I use it with SCons though so probably only touch a fraction of the functionality. The debugger is not as immediately intuitive as Visual Studio's but it's fine once you're used to it.

j: yep, it does, call stack and other stuff too, like valgrind mem checker and a profiler by default.

you can watch the whole filetree if you press, hey, filetree in the very left instead of "file selector" which you probably used.

ahh, that's good.

make+vim, how need anymore?

another tip:
do this before running a program:

export LD_DEBUG=bindings

then linux dumps all symbols and bindings to shared objects..
I'm guessing that Including such a nice function in windows wouldn't be wanted by M$ since then the function calls of their hackish espionage API's would easily be exposed.

as for drivers, from personal experience it's the windows one that are less stable, possibly rushed for game market (every time new AAA game title is out, nvidia puts out new drivers, fixing problems) - sure, you can wait for WHQL drivers before using them, but then you lose much of the ' are released before linux drivers'

for editor i'm using komodo edit, it has nice code completion, but it's aimed more on scripting, and being based on Mozilla means it's quite slow and memory heavy (although still much better than netbeans)

Pera, are you a troll or are you just fishing for a discount ticket to clueshoppe?

Ooh, the clue shoppe is well stocked as always!

so, let's talk about nvscene here. which compo will be cooler, nvscene's or assembly's?

I vote for nvscene.

assembly's. :)

demoboxes can't beat assembly :p

I'm with the ass too.

Icons.

I'll answer all the answers from the "NVScene08!" thread:

I compared final binary size, simply "wc -c binary" and gcc's binaries were smaller then windows binaries by usually more then 15%. I can't believe the PE header is _THAT_ big (more than 2k bytes?!)

...So you managed to get the GNU linker to produce smaller executables thank msvc's linker without hacking it to death?! Somehow I don't believe your measurings before I see them, seeing how we went through hell (hacking binutils etc) to get the linux-version of Nemesis down to 64k, when the windows version is 48k pretty much on first attempt.

And why didn't you just take look inside ?

I'd love to see some data about this too since in my experience the MS compiler kicks gcc's ass when it comes to size.

so would I. but knowing that gcc defaults to linking to the shared C lib whereas cl.exe defaults to static, and also knowing that most people haven't even heard of gccs "-static" option, i have a pretty clear idea what happened :)

hellfire: since I don't have much knowledge of PE binary.

This is a part of a discussion between me and gencha comparing executable sizes of the same code:

And this is only a single example.
Again, if you guys use MinGW's GCC to compare size/speed, you're in no place for argument, since MinGW's GCC is old.

"linux is invalid today" --> "link is invalid today"

Linux's ELF format is by default and to the smallest compatible form much bigger and with worse compression ratio than PE. Also the GNU linker produces more mangled shit in between that can be taken away(like for example many kilobytes worth of info sections that aren't used in the execution, only in the linking).

About code optimization of GCC and VC when it comes to size or speed: both are quite equal nowadays. So basically it's more of the matter of executable formats than the compiler optimization.

Intro size comparision is already pointless for the following facts: crinkler, kkrunchy
...why need better than UPX if there's no one(except RGBA, kudos for you guys!) in need of a better packer anyway? :)

LiraNuna: why do you compare the size if you admit that you don't have much knowledge of PE? Do you have much knowledge of VC optimization? Is comparing the same code even useful when lowlevel optimization is compiler specific always? I just can't believe the 15% at all even if I'd want to, sorry. :)

LiraNuna: An IRC log is in no way proof of gcc outperforming msvc :)

I did compare some code fragments, but I don't ave examples ready atm, but most of my 'lazy' code fragments in GCC turn to be some 'nasty' bit-twiddling operations done in 3 ops:
(Following code segments are represented in C though their assembler output was output in a much similar asm)

take the following code in C:

and compare both GCC's -O2 output and MSVC's /O2 output:
GCC gets:

MSVC gets the usual branching version


If you're going to try those yourself, make sure to test it on both MSVC's latest version and GCC's latest version (And no, MinGW doesn't count).

There are more examples I can share with you such as GCC's "templates" for min/max/log2/sign. GCC uses SSA trees for optimizing your code, which examines your code more throughoutly searching for pattern (such as the ones mentioned above) and replaces them with it's own better version, usually faster than yours.

I programmed on GCC for a nice amount of time on the GBA and the DS (kusma, you should know that, unless you're a real GNU hater and don't use devkitArm), and had fun time investigating how GCC works to 'optimize' my human written C. When I switched from GCC 3 to GCC 4, it turned out no matter what method I use, the same asm output is given. Though this is ARM, I believe GCC's GENERIC is similar on all archs.