HUD

Introduce your project and write about your work.

Moderator: PPS-Leaders

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Thu Feb 07, 2008 2:14 pm

btw. I just looked at the few examples, Starlance has a quite large cockpit, so does Aquanox.
A large cockpit yes, but does it contain any information? no, it does not - it is purely for the feeling.
I think the criticism of the first HUD should be more specific, guys. Not good is way not good enough constructive criticism. Also be more specific what each example does right, and what could be better in each example.
True... I try to be a bit more specific.

In general, most HUD in games are symmetric. I'll elaborate for Freelancer.
In the lower corners, there are 2 lists; the left one is for all objects in the area (or at the players choice, only important ones, waypoints, loot, or just fighters or (dockable) stations.) the right one is for the players ship, it displays loaded and activated weapons, amount of shield batteries and repairbots. The energy system is rather simple, and displayed in the 3 bars at the lower edge are for shields, armor and afterburner. The upper center bar describes normal actions: free flight, auto pilot, docking maneouvre and formation flight. Top right corner is the games menu.

About the steering itself: it was optimised for mouse use, thus you were able to click on any menuitem/list if you wanted, but I always used the keyboard which is was much faster.

The more i think about it, the more I see the need to do a meeting and discuss what we want in the game. otherwise it is rather difficult to design a HUD which only displays what we need, and not to many irrelevant information.

cheers
nico
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
superegg
Human Space Navy Major
Posts: 41
Joined: Mon Oct 08, 2007 2:41 pm

Post by superegg » Thu Feb 07, 2008 5:46 pm

Okay, thanks for all of your answers :D

Last semester, I just wanted the HUD to work, but didnt care whether the HUD looks smart. (Something that doesnt work is useless, it doesnt matter how cute it looks) Actually, in the last version, all attributes (like position, color) of every single element were variable. And few elements were put into a container, which was variable as well.
In the C files, I wrote several functions for variation.

Well, now I want TWO things.:

1. try to vary the attributes while the game is running
2. a new HUD design, which is cute enough for all

For further programming and designing I have to know which attributes actually have a value (like energy value, or shild value) so I can start with these ones.
A large cockpit yes, but does it contain any information? no, it does not - it is purely for the feeling.
my cockpit was also just for the feeling and I prefer thing that doesnt look symmetric

Anyway, I think making it semitransparent is a good idea. I am going to paint modules semitransparent, sofar you tell me which ones are necessary at the moment. How we put them together, we can discuss when I have them finished.
Image

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Thu Feb 07, 2008 6:09 pm

For further programming and designing I have to know which attributes actually have a value (like energy value, or shild value) so I can start with these ones.
sure... {could somebody correct me if I write BS}

And keep in mind, that most "values" are should be represented in an abstract way - think bars.
  • Weapons energy (one or more is not fix yet.)
  • shields - I'd like to have multiple shield sections later on - but we'll start probably with 1 value.
  • armor
  • electronics - like armor, but for your systems
  • missiles - think highly limited big ouch weapon ;)
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Thu Feb 07, 2008 11:15 pm

What IS important is, what patrick wrote earlier:
The HUD should be modular so changes can be applied a lot easier. For instance: Don't create a health bar, a energy bar, a shield bar etc. but one single bar, which can be used at different positions, for many values and behaves like we like to.
This is of course only a example. Modularity has to be driven farther than just that. Think what parts of the HUD are similar and can be grouped.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
superegg
Human Space Navy Major
Posts: 41
Joined: Mon Oct 08, 2007 2:41 pm

Post by superegg » Sat Feb 09, 2008 12:55 am

You mean I should write a class for, for example, "bar", which contains things like length, width, color and functions like show(), setFOO(args)?

It's a nice idea. I can do it, but since orxonox doesn't run on my computer, I cannot debug my code. Anyway, I will write a construct at first.
Image

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Sat Feb 09, 2008 10:49 am

Exactly. Of course you should keep in mind, where it DOES make sense and when not. The bar for instance can be used for several things. Also think about vertical and horizontal bars and ask you the question if the bar should be rectangular or dashed or rounded or curved or whatever and if the style of the bar can be set as well.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
superegg
Human Space Navy Major
Posts: 41
Joined: Mon Oct 08, 2007 2:41 pm

Post by superegg » Sat Mar 22, 2008 12:53 pm

I just found out that it will not be possible to write a class such as Class Bar, because no constructor can be made. Bar's "motherclass" Ogre::OverlayElement does not have a constructor as well, it is created by a factory named Ogre::OverlayManager.

Anyway, I dont see any possibility to create a Bar unless I can write an inheritance class from Ogre::OverlayManager, which seems to be quite complicated.

Hope has not gone yet, there is another way to create modules. Namely, templates can be written in the script. Lets see, what I can find out about this way.
Image

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Sat Mar 22, 2008 5:33 pm

Good thing you found that out. In this case you will have to do more programming on those scripts. Just try to keep it as modular as possible.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Sat Mar 22, 2008 6:32 pm

Or you make a class that creates a bar with the OverlayManager and that has functions (setSize, setPosition or something like that) to access it.

User avatar
superegg
Human Space Navy Major
Posts: 41
Joined: Mon Oct 08, 2007 2:41 pm

Post by superegg » Sat Mar 22, 2008 11:57 pm

Now I just tried another possibility: I put this overlayElement as a public variable of the Bar class, so that it can be used by "Bar b->element".

Anyway, I still got this error message "Undefined Reference to <any function of Bar>". This error message comes out, after codes have been compiled and are waiting for being linked to each other.

Why can I declare an object of that class, but cannot use its functions?
Image

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Post by x3n » Sun Mar 23, 2008 3:02 am

Maybe you've forgotten to write Bar:: before the functionname in the .cc file?

User avatar
superegg
Human Space Navy Major
Posts: 41
Joined: Mon Oct 08, 2007 2:41 pm

Post by superegg » Sun Mar 23, 2008 12:14 pm

No it's not the problem. This will cause an error while the program is being compiled, but the compilation ran very well. The error just occured by linking codes to each other.
Image

User avatar
superegg
Human Space Navy Major
Posts: 41
Joined: Mon Oct 08, 2007 2:41 pm

Post by superegg » Mon Mar 24, 2008 9:01 pm

Well, the problem is surely LINKING.

In the last version of orxonox, the class HUD worked. So I copied this class to a class named HUD2 and also changed several things in orxonox.cc . Anyway, HUD2 doesn't work anymore, although it exactly has the same code as the original one.

Do I have to change anything in any file when I add a new file to project? What is "svn add" and does it have an influence on this problem?
Image

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Mon Mar 24, 2008 9:21 pm

Anyway, HUD2 doesnt work anymore, although it exactly has the same code as the original one.
I really doubt that it has. Different class name means different implementations, so the code cannot be exactly the same - though I start splitting hairs here.
have I to change anything in any file when I add a new file to project? what is actually about "svn add", does it have an influence to this problem?
svn add has, as the name implies, only to do with svn. it add the file to the repo, which means it is under version control fro now on.

short answer yes, long answer, it depends on what file it is... I assume you are talking about a source file, then yes you have to add it to an appropriate CMakeLists.txt, that way the source gets built, and it can be linked at link time...

I hope this answers your question.

cheers
nico
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
superegg
Human Space Navy Major
Posts: 41
Joined: Mon Oct 08, 2007 2:41 pm

Post by superegg » Tue Mar 25, 2008 9:55 pm

fabian told me on irc that I have to add the file name to CMakeList.txt or something like this. And now it works :D
Image

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests