Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Dincio

#1
Ok you were completely clear, thanks again for the attention you dedicated to solving my issue. I will think of a way to handle everything based on your statements  :)
#2
I need a system in which every instance of type entity in my game holds its own gui (I need to do this for multiple reasons: the gui is relative to the position of the entity; shown only when the entity is visible; clickable only when the entity is interactable, etc...). I also use a "model/clone" system in which I load entity models from a file and then clone them when they are spawned, ergo the need to copy their guis...
#3
Ok got it... it's just a shame that a Gui cannot be copied, but I'll have to make do :)
#4
Also, as a side note, I needed to set the load an external font myself to make the textbox work... I don't know if this is normal or if the textbox is suposed to have a default font active when no font was selected.
#5
Ok thanks for everything!  ;D

I'll rebuild it as soon as I can, for now I'll just use the workaround, which works perfectly.
#6
The bug seems to persist even when calculations are involved... I did as you said, writing the code:
Code (cpp) Select
dialogBox->setPosition("parent.width / 4", 0);
but the textbox was drawn at position (0, 0) (relative to the parent) instead of (parent.width / 4, 0) as I wanted.

and also, being the expression parent.top - without any calculation - evaluated as 0 relative to the parent and not parent.top relative to the parent (because of the bug), isn't setPosition("parent.width / 4", "parent.top") also correct?
#7
oh yes sorry I understand now  ;D I even read it but just didn't notice the 0... ok everything seems to work now, thanks again.

About the bug; is it fixable?
#8
Ok I understand the bug now, thanks for the quick reply :)

Yes I already resized the textbox that, but what I want to do is to keep the starting position of the text box (its top-left corner) exactly one fourth of the panel's length into the panel. I'll try to draw it to make myself clear. The expression I would iintuitively use to accomplish this would be:
Code (cpp) Select
dialogBox->setPosition("parent.width / 4", "parent.top");
or
Code (cpp) Select
dialogBox->setPosition(bindWidth(mDialogInterface) / 4.f, bindTop(mDialogInterface));
but neither seem to work... even though they should, even with the bug in place (or maybe I still haven't understood everything...)
#9
In this case (and pardon my double post) how would I be able to implement what I had in mind in the first place? That is: having the textbox's x coordinate be exactly one fourth of its parent's width.
#10
So the bug is that when I use parent.left alone it uses absolute position, while when I add some calculations in it uses relative position?
#11
I've been playing around with layouts and I've found a possible bug. First, I compiled this code (and it worked as expected, drawing both the panel and the text box on the window in the right positions):

Code (cpp) Select

/*! constructor inside a class that handles a text based interface */
mDialogInterface = std::make_shared<tgui::Panel>();
mDialogInterface->setPosition(0, mWindow->getSize().y / 4.f * 3.f);
mDialogInterface->setSize(mWindow->getSize().x, mWindow->getSize().y / 4.f);
mDialogInterface->setBackgroundColor(sf::Color::Red);
auto dialogBox = std::make_shared<tgui::TextBox>();
dialogBox->setText("hello there!");
dialogBox->setSize("parent.width / 4 * 3", "parent.height");
dialogBox->setPosition("parent.left", "parent.top");
mDialogInterface->add(dialogBox, "dialog");


Code (cpp) Select

/*! function that handles drawing (from the same class) */
void *::handleDrawing()
{
    ... //draw other stuff using views
    mWindow->setView(mWindow->getDefaultView());
    mWindow->draw(*mDialogInterface);
}


outcome shown in "right.png"


The problem is that when I change the eighth line of the first segment of code from this:
Code (cpp) Select
dialogBox->setPosition("parent.left", "parent.top");
to this:
Code (cpp) Select
dialogBox->setPosition("parent.width / 4", "parent.top");
which is what I want to do, but really I could change i 8)t to whatever inolves any type of calculation, like:
Code (cpp) Select
dialogBox->setPosition("parent.left + 1", "parent.top");
and still the problem will persist. The problem is that the text box becomes invisible (outcome shown in "wrong.png").

The only way I can seem to solve the issue is by drawing the textbox directly to the window, but this seems just some kind of workaround... so is this a bug or am I doing something wrong?

Also, as a side note, I've tryed receiving input from the panel via panel->handleInput(const sf::Event& event) but the compiler tells me that the function is protected. Is there any other way of doing this without relying on guis (aka, in my case, using panels)?
#12
Ok that's fantastic! Thanks again for your fast and clear answers.
#13
Very interesting... I never thought that the gui was optional. But then what about events? (I know I don't need them, but maybe in the future...) is it possible to pass an event directly to a widget? e.g. a Button?
#14
As a side note: I found out (not on purpose, but while editing the code) that it is valid to draw a widget directly to a window... this is perfect for my case (since I need no event handling - I'm showing only progress bars and icons - I could store a panel in each entity and draw it without any need of a gui), but I can't help but feeling bad for doing it without a gui XD any thoughts?
#15
My reasoning is that, in my particular case, each entity should hold its own gui (as is the Object Oriented fashion, I suppose...) without having to worry about the existence of a global gui to add and remove panels from on spawning and despawning each entity. So better encapsulation and better resource management. Then again, I'm kind of new to big projects in C++, so I might be just overthinking a bit... but since I am off topic and my problem is solved, I will not bother you any longer  ;D

Thanks a lot for the help.
#16
Sorry for the double post, but I just found out that you can remove widgets by using the pointer (probably shold pay more attention to tutorials...) which makes my job 1000 times easier (no need to generate unique keys at every spawn). I am still wandering why guis can't be copyed though  :P
#17
Ok I looked up the documentation for the Panel class and it's exactly what I need! Still there remains the problem of removing the panel from the gui when the entity despawns, but I will have to think of something I guess... Just as a curiosity, why are guis not meant to be copyed? If it was possible it would make things like this a lot easier to implement (or perhaps I'm still missing something  ;D).

Thanks for the quick reply by the way.
#18
Help requests / Alternative to copying Guis
05 March 2017, 17:10:15
Hello  :)

I'm in the process of making a little game and I decided to use tgui for managing the user interface. The game manages multiple entities, each with its own hp/att/def/(you get it) and moves the entities around in a board each turn. I was thinking of giving an interface to each entity holding multiple ProgressBars (possibly wrapped nicely in a VerticalLayout) to show their life parameters to the player. My first approach was storing a Gui object inside the entity class, so that each entity could manage its gui the right way (drawing it when it is visible, requesting input only if the entity can be analyzed, allocate/deallocate it, etc...) but to my great despair, I found out that the copy constructor for the Gui class had been deleted... and so storing a Gui inside an entity would make it uncopyable (which is very important for multiple game systems, such as spawning). The only solution I can come up with is using a global Gui (maybe a static variable in entity) and using it as a sort of helper for showing widgets inside entities. In other words: every entity would generate a unique id (even just using a static spawn counter) and hold a VirtualLayout containing the ProgressBars (or even an whole new object component dedicated to the widgets used by the entity's interface), which will be added/removed to this global Gui when the entity is spawned/despawned using the unique id of the widgets. This approach would solve my problem , but it seems to like some sort of workaround... So my question is, why are guis uncopyable objects? Is there some fundamental reason that I am missing, or am I just using the system wrong? And what should I do in a situation like this one (which appears to be very likely)?

I hope I've made myself clear :) have a good day.