HUD

[ghost]

Started working on the HUD.

[ghost]

Just a comment, the HUD elements don't really need to be elements. Just making a HUD system is the easiest I think.

Something like:

void update(Environment* env)
{
        unsigned tank1 = env->getID("tank1");
        if(tank1 != 0)
        {
                // get tank's health
                // render tank's health bar

                // get tank's ammo count
                // render tank's ammo count

                // etc...
        }
}

It's like a rendering system. Maybe the current implementation is better but I can't find HUD_System.cpp so I can't comment on that.

[ghost]

Weird that you can't find HUD_System.cpp, I'll check that out. Other than that, I decided to take a different approach towards how to structure the systems. While systems like the Render System are applied to various entities, systems like HUD and UI are applied to their specific entities. Therefore, as a supplement to those kinds of systems there will be a manager that initializes and stores the IDs of the entities it initializes. I was able to increase the frame rate by 10 fps by cutting down the number of entities the update loops go through in a couple systems that way.

On Tue, Jan 6, 2015 at 3:14 AM, Sherushe notifications@github.com wrote:

Just a comment, the HUD elements don't really need to be elements. Just making a HUD system is the easiest I think.

Something like:

void update(Environment* env) { unsigned tank1 = env->getID("tank1"); if(tank1 != 0) { // get tank's health // render tank's health bar

            // get tank's ammo count
            // render tank's ammo count

            // etc...
    }

}

It's like a rendering system. Maybe the current implementation is better but I can't find HUD_System.cpp so I can't comment on that.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/47#issuecomment-68837568.

[ghost]

I intentionally didn't make the environment a singleton for that purpose. You can create a second environment for UI entities and pass that environment to the systems.

[ghost]

In that case, I will split the environments into the following: UI Environment, HUD Environment, and Game Environment. This might break your wrapper function, though.

On Tue, Jan 6, 2015 at 5:35 PM, Sherushe notifications@github.com wrote:

I intentionally didn't make the environment a singleton for that purpose. You can create a second environment for UI entities and pass that environment to the systems.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/47#issuecomment-68947217.

[ghost]

It should not. You just need to get the "cpuData" from three environment instead of one.

[ghost]

Creating multiple environments will create a mess out of the update structures. I started programming and was uncomfortable with how it was turning out. Keeping track of what system has which components of what entity and passing a bunch more stuff through parameters is a bit too messy. I know you are strongly against the idea and it was not meant to be, but since every system is using the environment, why not make it a singleton? I'd rather have a central location of reference for all entities rather than having references spread in different environments. The managers would init entities belonging to system(s), and be used like a lookup table for the entities it initialized in the environment. Of course such thing won't exactly work in systems the Render System, but for systems that don't mix entities this seems like a good solution.

To summarize my proposal: The environment becomes a singleton and managers are tied to their respective systems to interface with the environment.

On Tue, Jan 6, 2015 at 6:33 PM, Sherushe notifications@github.com wrote:

It should not. You just need to get the "cpuData" from three environment instead of one.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/47#issuecomment-68954491.

[ghost]

Can you give me an example of what you call uncomfortable? I don't really understand because systems doesn't have components.

Like I said before, you can do whatever you want during this time. i'm only intervening when the situation is critical or when they are bugs.

I just want to know what's causing so much trouble with using a second environment.

[ghost]

Ok, I made just the UI environment for now as a test. I guess there isn't much difference between managers and environments code-wise. Both need to be passed through parameters and both need to be iterated based on the number of entities they reference. Now here is are the down sides: I took me about 10 min to locate the event that was passing through the UI Env instead of the Main Env. That caused the Menu and Game entities to be unresponsive to key input. I fixed that, so no problem for now. But that is the tedious part of it I mentioned. Now for the strange part: I expected the framerate to be the same since it is iterating over the same number of components. To my surprise, the framerate went back to how it was before my optimizations, at least just for the render system. Through my optimizations I cut down the runtime from >2000 us to 1500 us. Now it's back to 2100 us for some reason. I will push this commit, but before you pull, take note of the framerate and tell me what you think.

On Wed, Jan 7, 2015 at 4:13 AM, Sherushe notifications@github.com wrote:

Can you give me an example of what you call uncomfortable? I don't really understand because systems doesn't have components.

Like I said before, you can do whatever you want during this time. i'm only intervening when the situation is critical or when they are bugs.

I just want to know what's causing so much trouble with using a second environment.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/47#issuecomment-68995869.

[ghost]

It's hard to see the elapsed times because it's oscillating a lot but I didn't see a significant change before and after the commit. If it's a 1500-2100 difference, you should not worry.

I see, so the events were causing problems. Inter-environemnts events would cause a problem, the entities' id are just valid for one environment. So passing those IDs around would mean nothing. But I think we don't really need inter-environments events, everytime we want to send an event, we can emit it from the environement we want.

[ghost]

I decided to put all events in one main environment. The main environment will also contain the "other" entities, which core code isnt updated mainly by one system.

On Wed, Jan 7, 2015 at 4:42 PM, Sherushe notifications@github.com wrote:

It's hard to see the elapsed times because it's oscillating a lot but I didn't see a significant change before and after the commit. If it's a 1500-2100 difference, you should not worry.

I see, so the events were causing problems. Inter-environemnts events would cause a problem, the entities' id are just valid for one environment. So passing those IDs around would mean nothing. But I think we don't really need inter-environments events, everytime we want to send an event, we can emit it from the environement we want.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/47#issuecomment-69097385.

[ghost]

It's interestingly weird how this issue got derailed into a environment vs managers topic. Anyway, to get this issue back on track, I've made a mockup of the HUD in paint. It's simple in the way it doesn't need sprites (so no manager needed) so it can be done as in the way you described in that comment suggesting how to implement the HUD.

The tanks are differently colored, a feature we agreed we should also include. The left bar is the ammo cool down, the other is health. I'm thinking we should include the ability to name the players which will be shown if the tanks are standing still or the cursor hovers over the tank. The "W: 1 L: 1" described the amount of wins and losses a player has. One thing bothers me though is that I want the bars to be always visible, but then it would look weird if a tank faces the bars and shoots. Auto rotation of those bars would be weird too. Maybe you have some ideas or a different design in mind.

[ghost]

It looks great. Maybe if you make the bars further away from the tank, it will look less weird when the tank is facing the bars.

I've done 1 exam this morning, 3 remains.

[ghost]

Oh! Do your best, and don't do what I did by staying up until 3 at night before the exams. XD

[ghost]

Thank you. Yep, I agree, sleep is very important. Hopefullly, I get good grades so that I can do an exchange to the US or asia.

[ghost]

I have problems with layering when rendering the HUD system. Put it before the render system, and everything gets drawn on top of it. Put it after the render system, and then it will be rendered on top of the menu. Is it ok if I make it a subsystem of the render system?

edit: never mind about the layering. Boolean states on whether to draw the layer of not just flew by me. But does it still make sense to make it a subsystem?

edit2: interdependency, nvm everything.

[ghost]

Ok, the get ID function is VERY costly, it lowers my FPS from 150 to 50. It should go into the constructor.

[ghost]

Systems calling other systems is not really good. If the HUD is a subsystem of the rendering system, it should be in the rendering system. The best would be to make a function with everything related to the HUD in a member function of RenderSystem and call it in the update function.

Also, the code in the updates functions should more into sub-functions for clarity. It's getting a bit out of control.

[ghost]

Another comment. Take a look at the viewsystem to see how the tank's id are handled.

[ghost]

Can't find anything related to tanks in the View system. What lines should I be looking at?

On Tue, Jan 13, 2015 at 6:27 AM, Sherushe notifications@github.com wrote:

Another comment. Take a look at the viewsystem to see how the tank's id are handled.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/47#issuecomment-69730917.

[ghost]

Just the Wins and Losses label left, and the HUD is complete. The Game Over screen/message should come first before I do that, though. Then player names, tank colors, sound effects, and it's Alpha 1.0 complete. Anything else amiss?

[ghost]

Maybe something like a start screen/message.

Can't find anything related to tanks in the View system. What lines should I be looking at?

I think you didn't really read the code if you don't find anything related to tanks.

[ghost]

So I made a Score system and a score component, and gave every tank a score component. I ran into a problem where the score component would be unreachable when the Tank gets destroyed. I'm exploring other solutions, but it's hard to give up this clean design.

[ghost]

HUD is complete. Ready to close this issue unless you have any last comments.

[ghost]

When tank gets destroyed, an event is sent. Maybe you can use that like the view system.

[ghost]

I did that at first, but in the message I sent earlier, I mentioned that I ran into problems getting the component of a destroyed entity. So what I did was made a score entity for each respective tank entity. Then when the tank gets destroyed, a score event is emitted as well which contains the IDs of the score respective to the tank that got destroyed and the tank that shot the bullet.

[ghost]

I see. Actually instead of removing the tank players from the memory we should just put them in a 'dead' state and revive them when the game restarts.

But if the solution with the score event works, it's okay for now.

[ghost]

Alright, and concerning about the temporary reference, if you are referring to the &auto, I'm sure you suggested it doing that way in a messages from a day or 2 ago. Here:

https://github.com/Sherushe/tanks/commit/16e6282f507383e50b102ed0a385ee5fdcc56d35#commitcomment-9256407

On Thu, Jan 15, 2015 at 11:58 AM, Sherushe notifications@github.com wrote:

I see. Actually instead of removing the tank players from the memory we should just put them in a 'dead' state and revive them when the game restarts.

But if the solution with the score event works, it's okay for now.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/47#issuecomment-70118972.

[ghost]

It's different. When something is returned from getComponent a reference is needed, but for get, it's not meaniful to take a reference of it.

The return type usually tells what to do. get returns a reference to an object but getComponent returns an object.