Why when building a project with cmake i have to choose generator?

@0x00004 Because cmake is a meta-build-system that generates project files. Maybe some day they'll do it directly, but from what I understood that's not a goal.

There are also build systems that generate cmake files. The fun never ends.

Turtles all the way down.

@Charanor While you're probably right I don't want to accept that. You're essentially saying that the amount in your bank account defines your standing in court and that all are supposed to be equal before it means nothing. Even if that is the case my ideals say I should not give into it and fight it in any way I can.

I heard a story a while back of someone who was mounting a stage production of a book that happened to be getting a big-studio feature film out soon. They got a cease-and-desist notice from the film studio, and the studio lawyer told them over the phone more or less that they knew their case wouldn't hold up in court, but they also knew they had the legal muscle to keep it tied up in litigation for years through the movie's release, so the theatre producer might as well give up now. :(

Apparently they are calls SLAPP suits and there are some countermeasures to them. Some laws protect against them and I think there are organizations dedicated to financially support people in such cases.

Yep. They still happen though, and fighting them still takes time and resources that a lot of folks don't have, even with extra support. In the instance of the theatre, you could have your legal costs paid, and still have no show to put on for a year while it works through court. The legal support doesn't pay the performers, stage hands, venue, etc.

Hmm. Maybe make a media campaign. "Disney starves artists with SLAPP suit". I want to believe that you're not completely helpless in that situation.

that would probably delay the one that sues too, though, "can't release the show due to legal issues".

The one that sues typically has far more resources to wait things out.

It's attrition.

Yes, aslo.

If they even have to wait it out. The lawsuit might be one-sided. Just not sure what would prevent a countersuit. (Other than, once again, resources.)

Yeah. Isn't there a rule where if the one that sue pays the legal fees of the one that was sued if the one that was sued "wins"?

Not that I know of...

Not if you go bankrupt before then and can't see the lawsuit to the end. Also it still ruins you because instead of games you fight lawsuits.

What? I thought that was standard.

You can't just make everyone pay lawyers until they do what you want or run out of money.

I mean... maybe... Not very knowledgeable about this.

I mean in the US, burying people by making them pay for lawyers is half the legal system.

😥

Has to refrain from making a comment about civilized countries

money == power

Not before a court. They are specifically designed to break that equation.

And yet...

I think a lot of our systems need a design update. We're due for a patch. ;)

Then again in context I would be quick to make concessions. "Dear Microsoft, you are apparently unhappy with me displaying your controller in my game which is meant to show the ideal usage of my game with your controller. If you want your controller to be displayed differently I'm willing to change it accordingly." I have no clue if that would work.

@nwp woa... definitely not true in the US

watch "The Innocence Project" on Netflix

Rip

I suspect that it is the case as long as you are in court. You need money to get there and stay there, and it is where the money == power comes from.

But yeah, coming back to the original controller question, I don't honestly anticipate it would cause problems. I think it's in MS's interest to be friendly to developers making games for their hardware/OS. It's a bit different from SONY if you're using the gamepad plugged into a PC - they don't have quite the same stake there.

not even that: if you have no money, you get assigned a public defender, and they are not always good

Apparently Disney executives manage just fine not spending all day every day in court.

often because they're too busy, but yeah it's a mess

I just don't have solid legal evidence to say "this is definitely safe"

grr. Trying to pick up on a project I haven't touched for months is mentally draining...

I should have left notes on what to work on next when I picked it up...

Did you leave the project in a state where there were things that did not work?

The worst I find is leaving a project in a state where things work but I cannot fathom why they work.

So most of it is unimplemented.

I just need to pick something and run with it.

Yet...

@DMGregory I feel like I never know why anything works. I just thank god for black magic voodoo.

How do games?

🤷‍♀️

@brug Write each feature on its piece of paper, put them in a hat and pick one piece of paper from the hat and implement the feature :P

I am at once horrified and delighted by this elegant algorithm.

So is there a word for the crippling anxiety you face when there is an abundance of options to choose from? But the paper in hat solution might help...

i bet German has a word for it

"Analysis paralysis" is the term. Not sure if there is a single word for it.

they have a word for "that feeling that your life will end soon (because you're 60 or whatever) and you haven't gotten enough done": torschlusspanik

literally "gate closing panic"

:thinking:

You got some details wrong there :D

not suyrprising

wenbt from memroy

:)

Or maybe I got some details wrong. Now I have to check.

No, looks like you got it right.

std::promise + std::future

I don't really know what you want to do. Is the core issue that you can only get the value from the future once but need to be able to read it multiple times?

Oh hey, I found that one other person in the world that uses std::async.

@Tyyppi_77 Sounds racy.

@Tyyppi_77 I'm pretty sure it is. It's not racy with promise.set_value, but multiple threads doing future.valid seems like a race condition to me.

Though ... hmmm. Just caling valid should be fine since it's const. You just can't call anything that is not const such as future.get.

@Tyyppi_77 That's the definition of a data race which is UB.

No. You have a promise for setting and a future got getting. Those are separate objects, so you can access them from different threads. They have to share some state, but that is done in a way that doesn't produce a data race.

std::async takes the promise and sets a value eventually (void and exceptions count as values in this context). And you can do future.valid and future.get without more synchronization. But if you have one thread doing future.valid and another future.get you have a data race on the future.

If you have a single thread doing the periodic checking it's fine.

If you actually do need the feature of being able to get the future result multiple times then I guess a wrapper is the best way.

Are you using an intermediate mode GUI?

Normally I would expect the lambda to send a message including the result to the GUI thread which then makes a single change, so the need to read the result more than once, or from a future ever actually, wouldn't exist.

Hmm. I'd probably have the game world data for the GUI thread and the world generator lambda that sends the generated world to the GUI thread which integrates the result with the game world data. In other words I'd try to put it into the message passing form and not poll a bazillion futures every frame.

But ... take it with a mountain of salt. You made games before, I didn't.

The state switch happens when the lambda sends the world generation data to the GUI thread. I don't think you need that future.

Assuming you have a message queue in your GUI thread. Otherwise all of what I said you cannot do (unless you add some form of message queue).

I'd say so. You must lock to synchronize with your other threads anyways in some form. This allows you to lock once per frame and is as efficient as I can imagine it. It should definitely be better than polling that future for the duration of game play, assuming you have more things you load which adds up eventually.

And I would advice against a lock-free queue. You are trading performance for a forward progress guarantee. You don't have issues with life-locks I think so the benefit doesn't apply, but still pay for the performance cost.

That is if the things I heard from cppcon are still accurate. I never actually dabbled in lock-free stuff since I just don't have the problem that it solves.

Then again I don't care about performance either.

You end up with a global GUI message queue, yes. All your worker threads get to throw their results into it. I don't see how that breaks decoupling. There is some sort of push_event function that all threads have access to but which doesn't expose much (the parameter type exposes a little, but you can keep that somewhat generic still). The workers don't know anything about each other.

The GUI thread has to be able to understand the results of each worker thread, but if your parameter is something like a function that applies a change to the game world it doesn't actually need to know anything about the result.

The benefit is that you get through it with minimal locking. A single lock per frame doesn't cost anything and arguably it isn't even overhead since some form of synchronization is required.

You do get into issues when your workers spam you with more messages than you can process, but that shouldn't happen in practice.

Do you actually have multiple worlds in flight where the first thread that finishes decides what the world look like? That seems weird.

And I would avoid using different message types. It doesn't matter where the world comes from. Make a function that applies changes to the one game world. That's it.

GameplayState and AutomatedTestState don't get to participate. They don't have a message queue and you can't send them messages. There are gui_thread, network_thread, loader_thread and some more, and those each have a message queue. At the start some threads get some start work, like the loader_thread gets the message to load the start screen and when it's done it sends a message to the gui_thread to display it.

Then the user clicks something which triggers displaying a loading screen and the loader gets a message to load a level, after which it sends a message to the gui_thread to display it.

I feel like your actors are way too granular.

Most threads only ever interact with the gui_thread, so it's not really all to all. Also you don't need to process anything. You just write each thread reading its own messages and sending messages to other threads.

The processing looks like while (not message_queue.is_empty()) { message_queue.pop()(game_state); }.

It doesn't look like a lot of work to me.

And yeah, technically there are all sorts of threads that communicated with you, but you have no clue which one or what they did.

Since we talked about locking once, this normal approach locks on every pop(). If you're worried about locking too often then you can lock at the start and make pop() not lock. Though ... I wouldn't expect that to make a performance difference. Locking mutexes is cheap. Contention is expensive.

@Tyyppi_77 Right. So your gui_thread and game_thread are only very loosely coupled.

Yup. You have to do the same with other objects like sockets too. Only the network_thread is allowed to handle sockets for example.

In practice you will probably slip up and write socket.send(data); in your gui_thread when you should have written network_thread_send([data](Socket &s) { s.send(data); });. Also issues with data vs &data arise. It gets tricky in the details and there is no tooling help to get this correct.

I can't tell if this architecture works for a game, but it's the architecture I use for GUI programs and it's the only reasonable architecture I know of.

cool

Very nice! Is this playing back recorded human play, or AI-driven solving?

neato!

You might be able to digest the recordings down from exact button presses to semantic steps. "Jump from current position to position X,Y" etc. Then compute the needed input that accomplishes that same semantic move outcome given the updated jump/gravity/friction mechanics.

Wouldn't fix everything, but it might save you from having to re-record for every single 3Cs tweak. ;)