Mundane C tricks ...

[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).

[Baker]

[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.

But yeah, valgrind rocks.

[mh]

[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 ).

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 .

[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.

[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]

[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.

[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 ...)

[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 ). 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).

[Spike]

there's always objective-c++ as an option...

[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."

[Baker]

[Baker]