TeamSweepy / Greywater

Repo for Greywater Isometric RPG
2 stars 0 forks source link

HUD and Menu Conversion #7

Closed Jeremy-Barnes closed 10 years ago

Jeremy-Barnes commented 10 years ago

Transfer HUD and Menu Screens from old repo (https://github.com/BattleBarnes/Greywater-Alpha) to new. Make use of the "Screens" feature of LibGDX because its pretty rad.

In the old repo see HUDge.java (Heads-Up-Display), StartMenu.java, InventoryMenu.java, Slot.java, and OverlayManager.java in the old repo.

The code in the startmenu is some of the worst code ever written, its all hardcoded just to get shit working. Please throw out any bad code, and replace it with better, equally functional stuff.

ZigaByte commented 10 years ago

I will have a look into it and try will try to transfer it. Also could you put all of the assigned sprites and GUI images in the dropbox assest folder we have ? thanks

Jeremy-Barnes commented 10 years ago

I will do that, yeah. It will be tomorrow for you when you get those assets, though, because I am at work for another 2 hours.

ZigaByte commented 10 years ago

Hello ! I have implemented a basic hud rendering. But I seem to have a problem. The HUD is renderd according to the world coordinate system, not the screens. I would love to see some insight on help. I will commit the code, so you can see that too.

Jeremy-Barnes commented 10 years ago

I think the issue lies in your render method for guicomponent - Camera movement doesn't alter rendering coordinates, so you have to add to your render however much the camera has moved. The camera class has two variables - xOffsetAggregate, yOffsetAggregate - that make that super easy.

Jeremy-Barnes commented 10 years ago

I went ahead and fixed that issue of the HUD not following the camera.

2 Notes:

The Level tick and render method are intended to tick and render things that inhabit the level (Mobs). Since the GUI isn't really "in" the world, it goes in the GameScreen render and tick methods. I went ahead and moved those.

Also, I don't know if you noticed that you "changed" the whole repo because your autoformatter is slightly different. That makes merging a bit of a pain. Can you import the TeamSweepy formatters? See here - https://github.com/TeamSweepy/Greywater/wiki/Using-SweepyFormatters

Edit: Neither of these are big deals, but they make life a bit easier.

Jeremy-Barnes commented 10 years ago

Ziga, see this comment at the bottom of your commit -

https://github.com/TeamSweepy/Greywater/commit/4e92c63edf1be508dabd2a4534a05fbba1a2d3cb

You should be able to use ints. If yours were screwing up somewhere, its not the ints that are the problem, something else somewhere is.

Jeremy-Barnes commented 10 years ago

Ziga - if you get time today please do whatever you were planning to do but also:

Items will probably need to be subclasses of Entity since they will be laying on the map and interactible via physics. They have a graphics components and a hitbox.

Entities will need two hit-checking methods, one for when they are tiny on the floor and one for when they are in the inventory. The following two aspects of entities should make that pretty simple:

Entities have a method to see if a given point intersected the image, not the hitbox called

public boolean didPointHitImage(Point2F point) 

That would probably be perfect for when they are in the inventory, and then set the hitbox to be a little tiny square for when they are on the floor.

Jeremy-Barnes commented 10 years ago

So, I apologize if I'm getting annoying, but my work is about to depend on some of this, so here are some notes:

Items are going to be a little weird since they have two separate contexts where we need to click on their image and not their "tile position".

So, when the player clicks it checks to see if the click on screen hits any of the "interactive" elements of the game (mobs, items, doors, etc). It checks to see if the point on screen overlaps with their image. I'm sure you can figure out why thats necessary, if not, ask me on Skype. I'll be awake in 6 hours from right now.

Anyways, the click calls a method in Level.java called getClickedEntity and that checks all the interactive stuff to see if the mouse pointer is on top of its image.

Here's the important part:

It checks that by calling an Entity method called checkClickedInteraction(clickLocation) That method works by comparing the location with the image bounding box. (You can look at the function in Entity, it isn't complicated).

The reason this is tricky with items is that we need to track their tile position (for depth sorting against walls and mobs), we also need to track an image hitbox for when they are in the inventory, and an image hitbox for when they are tiny on the floor.

The Entity method checkClickedInteraction exists specifically so you can override it as needed for items.

Please feel free to contact me and discuss this tomorrow if you work on it.