HUD showing teammates alive.

[wrtlprnft]

Yes, I kinda managed to update everything. Man, this CVS thing is *really* complicated. How do i get it to merge my changes and the changes in the repository together? I only get it to print a stupid "M filename" or to replace the entire file

After I spent half an hour trying to get meritons camera code back to work again (I wanted to replace eCamera.* in engine/, instead I added it to tron/...) I finally have a working version. Currently I'm going through your code and trying to understand it

Edit: I'm gonna make a gColorGradient class which can store a number of colors and their positions on the gradient and then return color values for one point on it.
Could someone move this thread to development? Its a bit misplaced like that.

[Lucifer]

OK, looked at the xml file. Looks pretty good. There's a few things I'd add, though.

Um, shapes for gauges. I was thinking we should give a shape for the gauge, and two textures. One will be rendered behind the gauge, and one rendered in front of the gauge, both on the shape declared at the size declared (alpha blending will be required in the front texture). Then we have, for bars, the ability to specify the bar's dimensions, and if it fills up, down, left, or right. For needles, we add the ability to fill it from the left or from the right, or not at all (just show the needle). For both, we need an offset as well to place them within the shape. For bars, the offset would be to the left-bottom corner, for needles it would be to the center of the circle. I figure these primitives should set it up so people can make just about any custom gauge they can dream up. (I think it'll satisfy all the proposed huds that have come up on these forums, too)

I'd also like to be able to bank any hud object back or forward, you know, rotate it around the Z axis. This makes more sense when:

I was thinking it would be nice to have two possibilities in the cockpit file. Maybe generalize it enough to allow a different cockpit for each camera, but I was thinking specifically of having a cockpit for incam and another one for all outside cams. So, in your example file, maybe we could have an attribute for <screen> that looks like this:

Code: Select all

<screen camera="internal">

Add models that can be added to the background and we can make an incam view that looks like you're actually inside the light cycle instead of floating in space a meter in front of it. I'd worry about the models later, for now just building in support for different cameras and banking the gauges.

[wrtlprnft]

(/me points to his edit in the post above)

Uff, lotsa work

Where would the textures get stored? As seperate files? And would they be as real textures or as black/white/alpha and then get colored by the gradient? or both?

Z-Axis is the one that sticks right into your eyes in this case? Well, the font would have to support that.

I'm gonna make the gradient class now and use it for the gauges, then I'll see what else I can do.

Oh, what are the special things about REAL? When should I use that and when float/double?

[Lucifer]

Saw the edit.

Um, I'd say let's worry about being able to parse for textures right now, and blow off where they're stored until we've got the stuff we can do easily right now done. We're kinda ignoring where any of this will be stored right now, but we may as well start beating that around.

We'll have to store everything under the resource directory. Bundled cockpits will have to be in resource/included, and cockpits retrieved by the resource manager will go in resource/automatic. So we'll need to be able to scan all of those locations to find the cockpit that'll be in COCKPIT_CUSTOM (or whatever we decide to call that config item). That config item will probably just be a placeholder, but it'll be around for awhile in the development series, that's for sure. So where do the textures go, then? I'm inclined to put textures with the cockpit file, maybe make a subdirectory for each cockpit that's named the same as the cockpit but without the xml extension, and scan that for textures. Whatever, the resource manager should do this all for us transparently, so that's where we're looking to put code. Other parts of the game will use the same code, so where and how we store the textures for cockpits is going to be at least partly defined by where and how we store textures in general.

In the meantime, I say we put the cockpits in resource/included, hardcode the ability to get a cockpit from moviepack (code which will be removed when the resource manager handles it for us), and put textures in some new directory that exists temporarily until the resource manager does it all for us.

We can ignore the fact that the font doesn't support rotating around the z axis right now, but you're right, ideally it would support it, too. Also, ideally it would support printing the text vertically, breaking it up into horizontal letters but laying those out vertically, and so forth. But it doesn't, so we'll work with what it does. (maybe add some of the stuff it doesn't do)

REAL is just typedefed to float. I should probably have used that instead of float wherever I put floats in gHud.

Also, I'm more interested in parsing the infromatiion from the cockpit file, we can add support for the stuff we parse for over time, so I'm just throwing out what we should be shooting for in the parser, mostly. You know, since the parser has to be written just to get started on this.

@tank: yeah, can we get this moved to development?

[wrtlprnft]

Well, we would at least need some pretty extensible data structures to hold the stuff we parse, so I'd say we try the gHudObject stuff right now, maybe even drop the support for gauges right now and readd it later so we can get started with parsing - what do you think?

Wait, actually gHudWidget already exits... never mind

[wrtlprnft]

looking at gParser, maybe we should create a base class that just has the generic functions to parse an XML file and then two derived ones which can work with maps/huds? Makes most sense to me....

[Lucifer]

You're right about gParser. We should factor it into a generic class and the specific gMapParser class. That would be best. Um, maybe we can poke/prod Luke or Phillippe to help there? Or at least to give some pointers and watch over us.

About cvs: If you're running KDE, install the cervisia plugin to konqueror, and it will make your life quite a bit easier. It'll make the patches for you, for one. Also, it'll show you diffs against the repository and stuff.

I'm actually happy you suggested a gHudObject, now that I tink about it. I thought I was smoking crack when I made gHudWidget and only stuck one single virtual method and nothing else in it. Now I'm thinking it should support the control points for a widget, and teh derived class will use them however it needs to.

[wrtlprnft]

Poke whoever you want, this can need any help

Currently compiling cervisia, so it might take a while. Back to GUI again... definitely gotta get a mouse then, I lost my old one and figured that I could live without it, but well. Graphics editing isnt fun, either.

to the derive stuff: Shouldn't we make the textboxes a widget then, too? Why do we need extra functions for each? I think it's a better solution to get the values in just one function, that stuff will get renewed with the XML parsing anyways. So we just end up having objects for every element, assigning them their values and rendering them all for every frame...

[Lucifer]

Yes, the textboxes should be widgets too. I won't lie, it was late into the morning and I hadn't done any paying work yet, so I did quick and dirty for those. I was focused on getting it to where an xml parser could be plugged in.

But yes, everything should be factored out into its own special widgets, and gHud will just manage them and update them. ON the data separation, I'm torn. On the one hand, we should have gSpeedGauge and gEnemiesBox and gFriendsBox, because OOP says they should manage themselves and the data they depend on. On the other hand, we should have just one gHudGauge that we instantiate multiple times and inject the data it needs on each frame, so that gHud can manage the data itself and optimize data collection. This also makes the xml file you made more closely match what happens internally, which is nice because then the results of the xml file are more easy to predict by just reading the file, without needing an understanding of some fancy specification.

For that, just do whatever you think is best. I'm not going to complain either way.

Either way, there's a few functions in gHud that I made knowing they'd disappear soon or sometime, but did to glue into the current rendering system.

[Lucifer]

Ok, in the branch, there is no localized hud. The stuff is still hardcoded. So if you don't like what it says, speak now or forever hold your peace. It will hopefully be in rc3.

I just changed it to say "Enemies: Friends:". We can color the text if you guys really insist, I suppose. Friends, of course, means teammates but is a much shorter word.

Meanwhile, the hud changes in the trunk are intended to provide for complete localized huds.

[wrtlprnft]

I don't really care, I don't need colors and I can change the text myself As long as the numbers are there somehow on the display its fine for me.

Another problem I have:
I'm using tArray in my code.
Basically the following won't work:

Code: Select all

tArray<*someclass> myarray;
someclass *myref;
myref = new someclass;
myarray.Insert(myref);

What am I doing wrong there?

[Lucifer]

Try this:

tArray<someclass*> myarray;
someclass *myref;
myref = new someclass(parameters to pass for the constructor, or blank);
myarray.Insert(myref);

Also, come into the irc channel at irc.freenode.net, channel #armagetron.

[wrtlprnft]

Oh well, I've almost rewritten the code to use deque, this one seems to be a lot easier Just got some weird errors, currently recompiling after make clean to see if they go away.

[Phytotron]

I just changed it to say "Enemies: Friends:". We can color the text if you guys really insist, I suppose. Friends, of course, means teammates but is a much shorter word.

How about Friends and Foes?

[Lucifer]

Ok, I started factoring gParser into a tXmlParser class in tools. I was wanting to make it support both a sax-based interface and the dom interface already used in gParser.

So, there needs to be some global c-type functions to pass as callbacks to libxml2. A pointer to the tXmlParser (or its child) will be passed as the userData parameter, and the global c-type function will use that to call a method in the class. So the class will have some virtual functions that should be overridden by subclasses for parsing, and it should have wrappers for those. So the global function will call the wrapper, which will convert any needed data to data structures internal to armagetron, and do any additional work that all xml parsers need to do, then call the virtual callback so the subclass can deal with it.

I don't see a way to simplify it beyond this that will be worthwhile. If a way is dreamed up, then you can derive from tXmlParser to make it.

It's building, but that's because I commented out the definition. Otherwise it doesn't build, needs lots of work. But it's basically "take all the stuff out of gParser that is general, finish the sax stuff, make gParser inherit it, test it, then write gCockpitParser".

On a side note, dookatee got cvs head running and he says he likes the new gauges.