pouët.net

Linux C++ Democoding

category: code [glöplog]
Those of you who got something released on Linux. Respect.
I'd love to hear some hints concerning development/build environment, codebase, libraries, general productivity etc.
I feel a bit stupid about how I fail to get started. I think I got most of the language basics quite well.
added on the 2011-11-04 17:18:50 by joooo joooo
how about using SDL? Would make for an easy windows port as well
added on the 2011-11-04 17:25:16 by wysiwtf wysiwtf
Aright, that's what I mainly played around with myself. But I find it kinda hard to find a nice coding style with such an oldschool C-Library.
Any good exaples/tutorials with a nice C++ coding style?
Also, so far I've been using gedit and plain makefiles. I'm looking for a simple IDE that gives me autocomplete and integration of an easy-to-use build system.
added on the 2011-11-04 17:43:32 by joooo joooo
ide: qt creator (you can use it for non qt-projects as well)
libs: you can either choose qt for bigger projects, or custom/stl-stuff for <=64k
music: minifmod (though syncing does not work properly)
sound: openal for example
code examples: nehe's tutorials, probably ports of iq's win32 code
added on the 2011-11-04 17:45:49 by mueslee mueslee
apt-get install mingw32
apt-get install wine
plonk

mueslee: I'll have a look. Thanks.

I know the nehe tutorials. Don't like the code.
added on the 2011-11-04 18:03:08 by joooo joooo
SDL is a way to go. And it doesn't break your style, as there are only 4 functions that you need to call to get started (and a couple more for sound if you intend to use SDL for audio ouput as well), and all of them are pretty much must be in your main().
Also, as a bonus you get an instant portability to Windows and OSX.

As for IDE, go for Qt Creator, it's the best IDE I've ever used on Linux. Don't be scared of its name, it doesn't actually require your program to use Qt. Although it does require you to stick with either qmake or cmake as a build system.
Other alternatives: vim (:D; +clang_completion), emacs, Code::Blocks

And as a general advice: be very careful about using C++ in performance-critical code. For example, be ready to completely turn off support for exceptions (-fno-exceptions) and RTTI (-fno-rtti).
added on the 2011-11-04 18:12:29 by provod provod
there is glfw, sfml or glut to name a few alternatives to sdl. sdl is good when you need input, but i heard its kinda bloated, too. then i read it's best to use "raw" opengl, how's that done, what libs are needed?
added on the 2011-11-04 18:31:33 by vectory vectory
vectory

To create "raw" OpenGL context on Linux one needs to use ~10 (afair) libX11 calls, which don't look that pretty. It's like three times uglier than creating "raw" gl context on windows using bare WinAPI and wgl.
added on the 2011-11-04 18:48:02 by provod provod
w23: and it gets even uglier when you try finding documentation and end up reading that libX11 is not suposed to be used! o_O
added on the 2011-11-04 18:52:32 by xernobyl xernobyl
Yeah, there's a reason why size-constrained demo on Linux is not so popular :)
added on the 2011-11-04 19:00:35 by Tarmil Tarmil
w23 yep, I experimented with size coding a bit and came to not linking libstdc++ at all (which required to disabled exceptions and some more stuff).

Sorry, might sound stupid but how do I create an empty cmake project in qtcreator. I only see qt stuff and when I import a cmake project doesn't recognize it
added on the 2011-11-04 19:06:54 by joooo joooo
btw... another related thread that might be interesting
http://www.pouet.net/topic.php?which=7014&page=1
added on the 2011-11-04 19:44:53 by mueslee mueslee
For demos, try (if you can of course) to link all used libraries statically (libc,libsdl,etc.), that'll fix countless problems from all different distributions.
For 1/4/8/16k, there are some interesting tricks, see at BBS
For 32/64k, just avoid to link the libc, the stdlib, the standard system startup files and use SDL.
You can also compress your elf with lzma/gzip and make it self-extractable (http://www.int21.de/linux4k/).
added on the 2011-11-04 20:00:59 by stfsux stfsux
Here's how to create an empty cmake project:

Code: xxx@yyyyyy:~/work/empty_project$ touch CMakeLists.txt xxx@yyyyyy:~/work/empty_project$


Don't know about qcreator, I'm pretty sure I'll stay away from that one.
added on the 2011-11-04 20:03:24 by Moerder Moerder
As for size coding, SDL is THE way to go :D. It's much more simple and space-efficient. And it's virtually everywhere, so there are no compatibility issues, like "install this 500k library to run my 4k", with it.

Also, the worst problem with 4ks for linux is the gcc+ld chain that has habit of generating lots of unnecessary bloat (go check what does main(){} generate). I managed to fight it by switching to pure assembly and writing all my precious elf headers by hand :D. That gave me around 600 compressed bytes for OpenGL context using SDL, which made stuff like this possible: http://www.pouet.net/prod.php?which=57718
Can share sources if anyone is interested.
added on the 2011-11-04 20:04:49 by provod provod
added on the 2011-11-04 20:07:10 by provod provod
joooo
sorry, can't help with qtcreator+cmake, as i've never used a setup like that, only qmake and .pro-files.
added on the 2011-11-04 20:12:16 by provod provod
killer: That's about what I did, problem is QT Creator still tried to compile the project with gnu make.

Besides that QTCreator could really work for me. Playing around using plain Makefiles right now. I had tried it before but kinda thought it'd only be useful for QT stuff.

w23: Nice! LDD says "not a dynamic excecutable". Do you really do the linking in the header or using syscalls?
added on the 2011-11-04 20:25:28 by joooo joooo
Oh and how do you link your custom header?
added on the 2011-11-04 20:28:00 by joooo joooo
Without knowing much about qcreator, I'd say this is normal cmake behaviour:

1. You write CMakeLists.txt somehow.
2. You run cmake on it. Unless you specify the generator to use, cmake will use GNU make as build tool by default.
3. You run make.

The point about cmake is that it is a front end for a variety of build tools, it doesn't try to replace GNU make or anything else (besides possibly autotools).
added on the 2011-11-04 20:39:31 by Moerder Moerder
joooo
That's because you're trying to ldd the gzip-dropper-script :D. You need to extract the actual elf executable out of it, like this: tail -n+2 $NAME|zcat > $NAME.elf

For linking I use somewhat mixed scheme: 1) link libld.so and its dlopen+dlsym functions with proper elf headers, and then 2) use these dl* functions to load everything else (libSDL, libGL).
This scheme gives measurable advantage (several tens of bytes in my testcases) over using elf dynamic loading mechanism for everything.

The custom elf header is simply hardcoded in asm source using dd, db, and dw directives to allocate bytes with proper values :D. The source is compiled using nasm -f bin for raw output (nothing at all is added by compiler, just translates as-is).
added on the 2011-11-04 20:46:50 by provod provod
screw cmake. qmake ftw :)
added on the 2011-11-04 20:58:16 by mueslee mueslee
Spent the last hour finding out there's no c function that let's me measure time in milliseconds x(
I guess I'll need SDL_timer then
added on the 2011-11-04 22:48:17 by joooo joooo
joooo: here's a timer class - you're looking for gettimeofday.

https://github.com/vovoid/vsxu/blob/0.3.0/engine/include/vsx_timer.h

I personally like and use cmake. But perhaps qmake is good as well..

KDevelop is a pretty good editor IMHO and is what I use.
added on the 2011-11-04 23:31:48 by jaw jaw

login