Mundane C tricks ...

Discuss programming topics for the various GPL'd game engine sources.
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Mundane C tricks ...

Post by taniwha »

Ah, do take a look at QF's alloc.h (recent git; there is no C file for it: it's just two macros). Both are documented, though I'm not sure "high-tide" is the right description).
Leave others their otherness.
http://quakeforge.net/
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Mundane C tricks ...

Post by Baker »

taniwha wrote:Ah, do take a look at QF's alloc.h (recent git; there is no C file for it: it's just two macros). Both are documented, though I'm not sure "high-tide" is the right description).
Directly using malloc, calloc and free -- which is braver than what I do. I put everything through a very light memory manager (pointer address, size, short text description) and when I shutdown normally and anything is left it complains and pops up a messagebox saying # of un-freed allocations and a description of the first one.

Is there some tool that people use to inspect memory allocations that they do not need such a thing?

/I mean this is such an old issue, I'd have a hard time believing there isn't something I don't know with that issue ...
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Mundane C tricks ...

Post by Spike »

valgrind. its awesome. tracks uninitialised memory access, tracks things written after freeing, tracks everything which is not freed, etc. its great. until you try using direct rendering, of course... then all the warnings all come out at once and it gives up trying to report errors because 'your program is too buggy'.
indirect rendering is the way forward. :P

But yeah, valgrind rocks.
mh
Posts: 2292
Joined: Sat Jan 12, 2008 1:38 am

Re: Mundane C tricks ...

Post by mh »

On any civilized modern OS leaving memory allocated at shutdown time is OK - memory allocations are per-process and they will be automatically freed by the OS when the process exits.

On Windows you can use the awesome Heap* APIs:

Code: Select all

HANDLE heap1;
HANDLE heap2;

HeapAlloc (heap1, ...);
HeapAlloc (heap1, ...);
HeapAlloc (heap1, ...);

HeapAlloc (heap2, ...);
HeapAlloc (heap2, ...);
HeapAlloc (heap2, ...);

// automatically frees all memory allocated to heap1 without needing to track individual allocations
HeapDestroy (heap1);
Yes, you can do the same with malloc and free and some code of your own, but you need to be suffering from a major case of the Not-Invented-Heres. It's still astonishing that memory management under POSIX is so primitive by comparison.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Mundane C tricks ...

Post by taniwha »

There were all sorts of crazy libraries and hacked up mallocs for posix systems, but since valgrind came along many of them have fallen into disuse (partly because valgrind showed many of them to be just as buggy :P).

While valgrind has been unusable with DRI in the past, it seems to be improving (if nothing else, suitable suppressions are being added to valgrind). Of course, it varies by driver, so YMMV.

For me, well, once again, I just simply learned where to look for weird bugs in my code, though that doesn't always help and thus why I love valgrind. What's really fun is when I get a segfault on the command line, but everything works just fine in gdb (had that last night). valgrind found uninitialized memory :). Not so much due to an error in the code, but rather invalid input data (unreachable nodes in my flow graph). With that, I figured out how to actually use the problem and implement unreachable node removal using the same code :).
Leave others their otherness.
http://quakeforge.net/
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Mundane C tricks ...

Post by Baker »

Re: Links

One reason I wanted to do a child/parent relationships was to be able to add a viewport and then have that viewport have "children" including the possibility for another viewport to be one the children.

That idea ended up being a headache. At first I was thinking I wouldn't need to translate/rotate/scale coordinates into a child viewport, then a realized that glViewPort only takes *real* hardware pixels coordinates, so have to recursively translate/rotate/scale into each viewport [Obviously only allowing rotations of 0, 90, 180, 270 since glViewPort has to be a rectangle ... workarounds like glCopyTexImage2D or framebuffer trickery would be a bit much to handle].

Once I get this hammered out, I need to post a screenshot of the kind of craziness makes possible ... [one example is draggable viewports]. On a size change, have to go "up the ladder" parent/child-wise and aggregate all the positioning to refresh it.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Mundane C tricks ...

Post by Spike »

recursive viewports are useless tbh. there's nothing but needless overdraw if you actually do anything with it.
that said, additional viewports that obscure previous ones (non-recursive) are nice for sentry-gun cameras or whatever, or split screen, but these are simplest as merely ordered peers.
what's more useful is being able to render-to-texture from different directions/vantage points, or simply to the same view but with the view directions transformed by a mirror matrix (and with an extra clip plane), because its stuff like that which allow mirrors and pretty water effects.

if you want to make your viewports render as you would a 2d image, go for it. that's almost how csqc is designed, just csqc has a lot more setup - to configure what is shown, the angles, sizes, etc.
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Mundane C tricks ...

Post by Baker »

Spike wrote:recursive viewports are useless tbh. there's nothing but needless overdraw if you actually do anything with it.
That's a good point (overdraw) ... something to keep in the back of my head in the draworder and maybe to Z-fail. I intend to mostly use recursive viewports for 2D, btw. My need for the viewports goes like this:

I mostly need the viewports to ensure clipping, although other methods could probably be done to achieve this (glScissor, stencil or what not). I could re-evaluate that later, though.

Either way, I still need to be able to translate a point in a viewport regardless of recursion back to the "real screen" for things like a mouse click.

/i.e. I'm not planning to have excessive 3D viewports or anything like that. I've looked thorough FTE's mirror code enough times, if I decided to do that. I actually almost added mirror's to FitzQuake Mark V. I had trouble with FitzQuake's sky drawing (which draw's first before the rest of the world) being the one little tiny thing that wasn't right about it, but didn't want to release a "yeah it basically works except ..." so I didn't [then after some MH talk about how the skybox should be drawn last to Z-fail for performance ... that left my immediate to-do list].
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Mundane C tricks ...

Post by taniwha »

While overdraw can be a problem with recursive viewports, it doesn't have to be. QF uses recursive viewports its HUD with minimal overdraw: most viewports are just for relative positioning of their children and are otherwise empty. QF's viewports don't support rotation, but that's mostly because I didn't think of it.

Yeah, having to maintain absolute coords along with the relative coords can be a pain, but if you use a recursive update function, it's not too bad.
Leave others their otherness.
http://quakeforge.net/
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Mundane C tricks ...

Post by Baker »

@ taniwha

You seem to mention Objective-C a lot and seem to be somewhat fond it. Are you using this on Linux somehow or are you doing Appley stuffs some of the time?

I'm interested in hearing your opinion on the language if you use it with any frequency.

I think Objective-C is really a dead-on successor to C in some respects.
1) The naming of the functions provides clarity.
2) The object-oriented design seems brilliant. It does take some getting used to.
3) They appear to have XCode ironed out on the Mac, making it a very delightful experience maybe 95/100 times. In paritcular, the auto-complete.
4) ARC is pretty neat.

While the IDE shouldn't matter, it does since Objective-C tends to produce a zillion similarly named functions and without auto-complete it is impossible to code (auto-complete used to often fail in XCode 4.3 and prior +/-, something like indexing couldn't figure out things half the time.).

Yet ... despite this, for some reason I would say I view the language with minor distrust. And I really couldn't say why. Maybe because it allows things like "nil" objects? Maybe because it ends up taking a lot of time to be comfortable with known objects? Or could be I think Apple's documentation somewhat sucks and associate the language with that?

Or maybe I am distrustful that the speed might not be there ultimately [like I suspect it is nowhere on the C++ or C speed scale?]? (Although I have no evidence of that ... either for or against ...)
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Mundane C tricks ...

Post by taniwha »

Actually, Apples usage of Objective-C sucks according to Deek (an ornery fellow in #quakeforge (founder, actually) that I can't say I've ever seen be wrong). He seems to reckon that most of Apple's Objective-C coders are ex-C++ coders and thus produce a lot of deep hierarchies.

I like Objective-C: it's pretty nifty, however, 95% of my experience with it is bolting it onto QuakeC and then doing some Objective-QuakeC coding (qf's menus, adapted frikbot, a game of my own). There is no "nil" object, nil is just ((id)0) (void * for objects), and the language is designed such that sending a message to nil is a no-op that returns nil. IMHO, Objective-C has C++ beat hands-down, except for two things: funciton/operator overloading and non-virtual member functions. Objective-C's message passing beats the pants off C++'s virtual functions. And then there are protocols (an interesting way to combine abstract classes and multiple inheritance, which Objective-C does not have) and categories (let's see you do that in C++ :)).

Objective-C's real power comes not so much from its syntax (which is pathetically simple for what it does), but rather that almost every decision has been deferred until runtime. Sure, naive usage will result in slower code than C++, but there are ways to speed it up. Anyway, even with fairly naive code (I don't know enough of the ins and outs), I haven't noticed any performance issues in QF's implementation (though a p166 might struggle with a QF qw server running 16+ frikbots).

Anyway, if you want to see what QF+qfcc are capable of, take a look at ruamoko/cl_menu (though Deek says my code is a little class heavy, but then, I'm an ex-C++ coder :P). Also, fbxa in the game-source module (just change quakeforge to game-source for the git clone line) has some examples of categories (I used them to split the implementations across several files). There's also snax's scheme implementation in the ruamoko directory.

A word of warning: qfcc's optimizations are a little buggy at the moment (struct copy into a 3rd (or later) param gets dead-vared: oops).
Leave others their otherness.
http://quakeforge.net/
Spike
Posts: 2914
Joined: Fri Nov 05, 2004 3:12 am
Location: UK
Contact:

Re: Mundane C tricks ...

Post by Spike »

there's always objective-c++ as an option...
taniwha
Posts: 401
Joined: Thu Jan 14, 2010 7:11 am
Contact:

Re: Mundane C tricks ...

Post by taniwha »

Heh, you know your design is right when a fix that you expect to be messy* takes 2 new lines and 1 changed line of actual code (doesn't count a param name in a declaration, extra {}s, and two variable declarations (and one of them was purely for convenience)). That bug I mentioned in my previous post is fixed already :).

* "great, I have to somehow fish out the daglabel for .param_N. Oh, look, def_visit_all's data pointer param isn't being used. I can get it to pass back the label via the pointer while passing back the node via the return value." For the curious
Leave others their otherness.
http://quakeforge.net/
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Mundane C tricks ...

Post by Baker »

taniwha wrote:Objective-C has C++ beat hands-down, except for two things: funciton/operator overloading and non-virtual member functions. Objective-C's message passing beats the pants off C++'s virtual functions. And then there are protocols (an interesting way to combine abstract classes and multiple inheritance, which Objective-C does not have) and categories (let's see you do that in C++ :)).
I can't say I understand enough about any of the 4 to draw a conclusion. I've used protocols in Objective-C, and half-way understand them as a way to accept messages/events and respond to them even if the class normally wouldn't. Categories ... I've heard of them, but I'm murky on what they are for and/or do.

Initially, Objective-C came across as intimidating just due to seeing new "operators" ("@") and a different syntax (-(void), but most of it is quite easy.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Baker
Posts: 3666
Joined: Tue Mar 14, 2006 5:15 am

Re: Mundane C tricks ...

Post by Baker »

Spike wrote:there's always objective-c++ as an option...
Haha ... yeah ... :D

A weakness I see in object-oriented programming goes like this ...

It is event-oriented. In theory, this is awesome. In reality, no programming language is real-time. Object events can trigger huge cascades of unnecessary recalculations/refreshes.

Code: Select all

fbool System_New_Frame(float* timeslice)
	{
		static double last_frame_time;
		double _current_time = System_DoubleTime ();
		double _current_time_slice = _current_time - last_frame_time;
		
		last_frame_time = time_clock.elapsed_time = _current_time;
		*timeslice = (float)( time_clock.time_slice =  _current_time_slice );
		time_clock.framecount ++;
		return True;
	}
I'm going to try to see if I can use something similar to a framecount to limit recalculations to its own step in a frame.

I.e.
System_New_Frame (&timeslice);
Run_Every_Object (); // If object changes, send a message up the parent chain like "render_change"; if a viewport, send position_change message down the chain ..

Pre_Render_Refresh (); // Look for position changes and rendering changes. If not visible, ignore it --- else clear the change and add it to draw linked list.
I guess I fear runway hordes of redundant events.
The night is young. How else can I annoy the world before sunsrise? 8) Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Post Reply