I don't know much about fonts. That looks like a complicated topic...

heyo!

Hello!

how ya been, Vail?

Okay!

How about you?

noice. i have been pretty good, school is going pretty good. Learning about sets, dictionaries, and tuples

Nice!

Python is weird lol

Oh, yeah

having 4 separate data types that do near-identical things. sets and dictionaries are understandable, but tuples are... weird

Tuples are its notion of a fixed-size array, no?

from what i understand, Tuples are like lists but nonmutable

meaning it is like an array, but is "set in stone"

They're used to return multiple values from functions, aren't they?

Hello!

ho!

👋🏻

This Google Local Guide thing where you earn points, it's nice, and all, but the help does not state why you'd want to earn points..

I guess it's like those with the XBOX achievements?

Oh, there is this:

> Remain an active contributor on Google Maps to be eligible for perks and early access to new features.

Sooo im back with a new question :) if a player clicks on a structure a popup appears. The structure has a "OnClickPopUp{ popupType, strings}" component, once a click appears a system constructs the popup and pass in the informations. The problem : Once we load in a structure, we "clone" the structure type, its some sort of prefab... that means "OnClickPopUp{popupType, strings}" is already defined and filled in with data.

After that prefab was created, we load stuff out from the database and attach it to the entity as a component. "OnClickPopUp" should deliver the owners name, which is obtained after we fill in the prefab data... so we cant insert it that easily. Any idea how we could solve this issue ?

So you want to have the user info who clicks on the structure passed to the structure that is created?

That sounds like you're doing too much again :/

I'm personally not comfortable with the idea of putting the UI into the ECS, but maybe that works for you.

That being said, most UI Event driven patterns I've seen include the "originator" with the event.

@Vaillancourt Hmm... probably my describtion is bad. Structure was cloned and filled with data "OnClickPopUp"-> component gets loaded from database and attached -> User clicks on Structure, OnClickPopUp was triggered... spawns an PopUp which does not show the loaded data, only the stuff that was filled

@Tyyppi_77 Ah i see... my entities actually dont have a nametag... but thats probably a good idea. I actually try to decouple components from each other, thats why i thought its a bad idea to make "OnClickPopUp" interact with other ones.

@Tyyppi_77 Currently its stored in the "Structure" component as an int which references to the players id, that one contains the name. The problem here is that "OnClickPopUp" only requires a name for one single situation... for structures. There dozends of other entity types using that component without any names :/

how is the name used?

e.g. can it not simply be included in the message that is displayed on popup?

@Tyyppi_77 That would work... just not sure if its clean :/ Or probably two systems ? One iterating over clicked entities to create popups and one iterating over structures to pass in the players name into "OnClickPopUp", but thats not that clean either

and could that message then not be provided, as @Tyyppi_77 brought up, by the owner of the popup

@dot_Sp0T In the popups title... "onClickPopUp" simply stores a popuptype and a list of things to insert into the popup title... like "name":"player1" ^^

your popup system seems to cause more torubles than solve stuff :/

@dot_Sp0T tbh... all ecs flows that are not intended to run every frame are a pain, especially if they are involved in larger features. The popup system works great... its an own entity minding its own business... The "OnClickPopUp" also works great if we already have all informations we need... but the real issue here is to insert informations later on, after they arrived from the database

why not have the stuff that runs irregularly be event based then?

Structure cloned -> OnClickPopUp filled -> Database loads in "Structure" component -> How do we modify OnClickPopUp in a nice way ?

at step 3 obviously. the modified popup data is dependent on the modified structure(?)

at least that's how i understand your flow from your descriptions :/

Depends on which events you mean. Well thats right, but theres no way we can hook in an callback or similar. The component gets loaded and attached. Thats it. No event, no callback :/

Its some sort of generic system taking care of this, not unique for each component

that callback is then called on the system processing the entity

now the system can stay generic, while there's the possibility of hooking in additional logic where needed

no you do not. you can define a standard usecase which is a callback that does not do anything; empty

you don't even need to handle having a callback stored or not. bc you can simply call it and if it's the empty one it returns instantly

at the same time all the other data is initialized i'd say

but it can happen whenever you want fairly

why? it's data after all

if you have a place where you init data, then just init there

problem solved

every single piece of code is specific one-off. whenever you write something generic, at another point in your codebase you have one-off code that makes use of the generic bit because it's needed. the whole point of software is to have thousands upon thousands of one-off bits of code connected together to form something bigger

no, it's literally a single line of code if you do it like that

and if instead you have the reference to the callback in your xml, it's 3 more lines of XML bc you need to enclose it in tags

@dot_Sp0T The callback idea is good... but i really try to use pure ecs as much as possible... nevertheless the popup requires data from many entities, not only its owner : "Select action on {building} by {owner}" is just one example.

you need to have specialized logic somewhere in the whole process. my proposal of a callback is the simplest way i see to solve it. there's tons of others

@Tyyppi_77 no, spaghetti is born from not taking the time to plan out how something should work; not taking the time to reengineer something that is not usable as it is anymore

you can't make a perfect-generic-handles-everything solution for every little problem. It's worth abstracting if you run into the same/similar requirement multiple times

I don't think there is a single answer to "how spaghetti code is born"

I think the goal here is to inject the players name from "Structure" into "OnClickPopUp" on the same entity "once"... everyframe we could simply do "(structure s, onclickpopup o) => // write name into onclickpopup"

I'm just a bit unclear why you'd use ECS - which is optimized for batches of items at a time every frame - on something that by definition you only need to do one at a time, on a few rare frames.

the nice thing about the callback: Say next time you have the issue that you need popups on, say, a tree. and you want to include the current height of the tree into that popup: just write a new callback that is stored on the popup instead of the default one doing nothing. the system processing the callback still is the same code, everything still is the same code everywhere

@DMGregory i assume it's bc ECS gives a nice flow and perceived order to things. Also helps getting rid of huge game-logic-loops in single methods

I'm still not clear on what the issue is, but if sometimes you need more data to an entity, then adding a component with that data is a way to go.

@Vaillancourt as far as i understand it it's about the interaction between components

ECS is also about ease of adding features too, yes.

@DMGregory ECS in general due to its structure, flexibility and performance... but yeah, such one time things really suck :/

Why would components interact with each other?

@Vaillancourt the simplest use-case i have is a Position and a Velocity component. their data is strongly related in many use-cases

@dot_Sp0T Sure, but components do not care about each other.

@Vaillancourt The issue here is basically that i need to insert some piece of data from one component into another one, but only "once"

A sound emitter entity will rely on the component's position, not on the velocity.

yes, it's the systems that then combine component-data into something happening

@genaray Yes? Do that in a system?

I have a function in a system that takes the matrix computed by the physics engine, and copies it over to the matrix used by the graphics engine.

the idea of the callback is, that the system does not need to have a bunch of if-statements or behold a switch

@Vaillancourt And how do we prevent it from doing that every single frame ? It actually needs to happen once :/

@genaray mark it somehow

@genaray Add a dirty flag?

or as also suggested, remove that process from the ECS and instead run it using events

I see... another marker. Kinda get the feeling that its some sort of holy grail ^^

an ECS is all about processing data. Markers are a way to organize and manage processing

you could also have two different components: one for the unprocessed popup, and one for the processed popup

@genaray I don't know how you handle your components, your entities or your systems, but if you go for the "pure approach", your "dirty flag" would be a component. Add the component to the entity, so that when your system handles ComponentSource, ComponentDirty, ComponentTarget, it will copy the value. Then it removes the ComponentDirty from the entity.

That way, those ComponentSource and ComponentTarget will not even come up again when you need to "check for a dirty flag".

And your components remain "clean with their own useful data".

that sounds right to me

@Vaillancourt Thanks, than thats the way i choose... Its also usefull for updating those values... Like when the owner of a structure changed, attach the dirty component and update the whole entity.

Good luck ;)

That ternary ended up like this:

  const int widthInPx = TheImage->s();
  const int lineSizeInBytes = ( 3 * widthInPx );
  // Lines must be "multiple of LONG" for windows Bitmaps:
  const int widthForBufferPaddingInBytes = [&]() {
    const int sizeOfLong = static_cast<int>( sizeof( LONG ) );
    if ( ( lineSizeInBytes % sizeOfLong ) > 0 )
      return sizeOfLong - ( lineSizeInBytes % sizeOfLong );
    return 0;
  }();
  const int lineWidthWithPaddingInBytes = lineSizeInBytes + widthForBufferPaddingInBytes;
  const int heightInPx = TheImage->t();

@Vaillancourt Thanks, i basically added the following : Created, Dirty, Destroy. Once an entity is created, it gets marked as dirty soon after. Every of those components stays one single frame. So when we wanna update the "Tower" entity once, we simply iterate over "(structure, dirty, onClickPopUp" and pass in the data we need from structure to onclickPopUp ^^

@Tyyppi_77 /shrug

I'll take a look

@genaray +1!

@Tyyppi_77 I had the feeling that there was that kind of "simpler" line to get the same value; however, since we don't use that kind of math in a lot of places, I'll use it the way I wrote it for the ease of reading. If we get to use it at more places, I'll transfer it to our math library.

Cool!

Our architecture works like a deterrent to improve "outside" libraries. So I'll want to not touch the math library as much as possible.

Is drawing to framebufferobject supposed to be slow?

no..?

Okay; I'm experiencing "slowness" but it may be related to me needing to copy the data back to the client memory..?!

/shrug

yeah

more likely

I guess I'll not get my free lunch today!

that's why opengl shared contexts were invented if i am right in what you're trying to do

I don't know. If we share the context, we need to double the amount of VRAM used, which would require us to reduce the quality of our textures.

textures should be shared

Yes, that's what we want to avoid.

Hmm,

Well that's not what we get.

weird

basically: khronos.org/opengl/wiki/….

We use a thirdparty rendering engine (OSG). If we use a shared context, the amount of VRAM used is doubled.

ah ok, i don't know if OSG does not set flags properly under the hood. or maybe it's written on older compatibility standards

It is written on older compatibility standards ;)

maybe it's worth rendering at a lower resolution and then using some shader-magic..?

if your fbo is only half the monitor size it's also only half the data that need to be written back/forth

Yes, that's what I though of doing if we're stuck. I'll dig a bit more and see how OSG does its thing and if I missed a setting.

goodluck

Thank you :D