« first day (3457 days earlier)      last day (31 days later) » 

6:41 AM
A distilled positive post without a single mentioning of existing problems. I think it's intentional.
 
 
3 hours later…
9:51 AM
Hey all
 
How's it going?
 
as always
 
How's Rust going?
 
I finally can write let c = &a + &b and not break everything
 
9:58 AM
Sounds exciting!
Is that meant to add 2 variables together, or is it doing something different?
 
it's for adding two variables and not corrupting them
 
Thats interesting .. so c = a + b wouldn't work?
 
simple a+b will move them and then you can't even read them
operator implementation function takes ownership and does not return it back
 
When is that useful as a default?
 
when your type is cheap to copy
 
10:02 AM
No I mean when is it useful to move instead of copy as a default? When do you want a op b to move a&b?
Why has Rust chosen to move here as a default?
 
no idea
why it takes ownership instead of borrowing
I had to implement T+U, T+&U, &T+U and &T+&U
because if you write &a+&b+&c it reduces to ab+&c where ab is a value we own
not reference
I'm not into &(&a+&b)+&c things so I implemented all four overloads
of course if your type is Copy'able you can write a+b+c
strange language
about git submodules: is there any way to deduce submodule branch where the commit belongs to?
they are in detached head state
 
Rust is weird
 
the goal is not to just checkout their master branch, parent repository decides which commit to take
 
@trollingchar Do you mean to be able to tell which commit a submodule is pointing to?
 
but how to deduce the submodule branch
ok I update repo with Jenkins, it updates it and submodules
 
10:14 AM
If you do git submodule, it will display all submodules in the current project, and their hash
is that what you meant?
 
then I go to a submodule dir
and type git symbolic-ref HEAD
and it says head is detached and it can not tell what branch it is
 
You can always do man git-submodule it has plenty of details about how to use them
 
what I want is not there
 
It says what branch I am on in my .gitmodules
 
I have path and url, but not branch
 
10:21 AM
I think that means you are on master?
 
Well, the intent is that parent repository commits define certain versions of submodules, and it's possible to revert it and it reverts all submodules to compatible versions
 
Yeah IIRC there's another location somewhere inside .git that defines that commit of the submodule the submodule is at
Hence you have to manually update the submodule to get a newer version
 
it should be somewhere
 
If I make an edit in a submodule, commit it, and then look at my parent repo, it shows a new commit hash as the submodule reference
The filepath modified is showed as just "CaveGame/imgui" though
 
given that the last tag is v_1.0.0, git describe gives v_1.0.0-32-ga95a7dc
 
 
3 hours later…
1:11 PM
problem solved by removing the need to solve it
 
1:53 PM
@trollingchar Wouldn't that work for any problem?
 
))))))
 
I recognise a fellow lisp developer when I see one
 
nwp
lol
 
2:14 PM
It seems that all access to global variables in Rust is unsafe
they say I have to inject that global state object
 
3:12 PM
Thanks for the question @MadScientist - We have ideas for how to better integrate technical content from across SE with the knowledge sharing that happens on SO, and vice versa. For the broader SE community discussing non-technical topics, we have no plans to change anything at the moment. — Pchandrasekar ♦ 22 hours ago
So, will they merge all the technical sites into SO and dump everything into the dump that SO already is?
 
Oh no ... why would anyone even mention merging communities to SO ?
 
I don't know. I think they have an issue with SO; they should redirect content to their more appropriate site, not make SO even more generic.
 
3:31 PM
I understand if SO has an issue, but I don't think the solution would be to create issues to other SE sites ..
 
Yeah; I don't know what their "ideas" are. We can only wait and see.
 
Would be a real shame if something happened to the Game Development SE :/
 
nwp
Sounds technical to me :D
I don't know why I find meta drama funny. It probably makes me a bad person.
 
I mean, humans have enjoyed drama for ages
Until it starts to affect us, and then it all goes downhill
 
nwp
I have distanced myself so far from Stackoverflow that I don't care anymore if it goes down. I haven't asked or answered a question in ages and there are enough scrapers around so you find the answers that it doesn't matter if the company dies.
 
3:46 PM
Yeah but isn't StackOverflow connected with all the rest SE sites ?
I thought StackOverflow started everything
 
nwp
Oh, when I say Stackoverflow I mean the company, so it would take everything with it.
I probably should care more about Gamedev.se as a site, but I don't even have an account there.
 
I doubt it'll go down. It could be having a hard time, it could need to reinvent itself and reborn in a new shape, but die and remove all the questions from the internet? I doubt it.
 
nwp
The questions won't disappear. Too many mirrors already. And sure it will be reborn. But the company Stackoverflow might not survive the rebirth process. Maybe it gets merged into a moderated reddit or something.
 
Yep.
But I doubt something like this will happen anytime soon.
Maybe we'll all have time to move on before it does :P
 
Hopefully it won't be sudden :P
 
nwp
3:53 PM
I already did about a year or so ago. I hope you do too before everything goes down. Or maybe a miracle happens and they make everything better. Who knows.
 
I used to be active on SO some years ago, but there was a point where I felt I couldn't answer a single question, because everyone started using web technologies, javascript, and all the countless packages of node and npm
 
I'll admit that I'm more addict to this site that I am to facebook. This could be beneficial for some of us hahaha :P
 
nwp
There seem to be lots of people still angry and invested in meta, so it's a good sign that people have not given up.
I don't have a Facebook account either :D
 
@Vaillancourt That's the same for me, I prefer the chat here as it is social, but its not about us, but about games
 
@nwp good :) Don't do drugs, m'kay?
@TomTsagk Yep :)
 
4:26 PM
Let's talk threaded content loading: It seems very attractive for me to on the loading thread to make a call to a wrapped function that makes a promise, adds it to a queue, then waits on the future and then returns a Texture*, and the main thread iterates over the promise queue (with one loading thread, just 1 item) once every frame and loads the textures
This would allow for very nice code on the loading thread, i.e. just Sprite s{ contentLoader.LoadTexture("...") } without having to consider the fact that the texture won't be available immediately
However, do you think I am shooting myself in the foot by always stopping the loading for a frame when some content needs to be loaded?
 
What language is this?
 
C++
 
I generally like to separate the loading and the actual game, so that when the user navigates to a screen where a specific texture is loaded, the game will automatically load it before an element is initialised with that texture
Are you suggesting to load textures dynamically when they are requested ?
 
That's what I currently do, main thread has to preload all needed textures and pass them as pointers to the loading thread
Indeed it would make sense to me to load textures dynamically when requested, since that's what my loading/world generation thread is for
 
Also ideally, a loading thread shouldn't be aware of what "frames" are, it is just meant to load everything, and then pass a message to the game (which is aware of "frames")
 
4:33 PM
True, and loading thread wouldn't know about frames, it would just pause until the main thread ticks over to the next frame & performs the loading
 
So you pass a pointer to the loading thread, and the loading thread is initialising it with the texture, and passes it back?
 
Hmm I think I've confused you with terminology, loading thread = world generation thread
 
Ok maybe I am confused :P
 
Current approach fills a struct of texture pointers on the main thread, and passes that to the world generation thread, which passes the textures to the tilemaps, entities etc.
But this is becoming unmanageable, annoying to pass around a lot of stuff as variables like that
 
Is this 3D?
 
4:34 PM
2D, why does that matter?
So I'd want the world generation thread to be able to request the textures by path, just like my main thread can, and then use them directly
 
It sounds like the world generation thread is doing more than it should, maybe that's why its, to use your words, "unmanageable"
Is it a static world, or procedural?
 
Procedural, and I don't feel like constructing entities on an asynchronously run thread is "more work than it should"
 
If I understand this currently, you pass pointers of data to the world generation thread, the thread fills them up, and passes it back to the main thread?
 
Why does your main thread loads the textures? Why not the content generation thread?
 
Can't do OpenGL calls from non-main thread
@TomTsagk No, the pointers are pre-filled on the main thread, as it's the only thread that can load textures
 
4:41 PM
Ah, I see
 
world generation thread uses said pointers as initializers to sprites what whatnot
 
Does the world generation thread return what it generated to the main thread when its done?
I'm just trying to understand how you've structured the game, as it feels quite unusual to me, sorry for the too many questions
 
@Tyyppi_77 Ah, makes sense.
 
@TomTsagk Yup, gameplay state holds a future to the generated world, and displays a loading screen while the future isn't completed
 
Ok, I re-read your first comment, when loading, losing 1 frame every time you load something is not really impacting the project
Assuming loading the world counts as "1-time loading" and not separate
 
4:47 PM
I would lose a frame for every non-threadable item of content I would load, i.e. spawning entities with 5 textures will take at least 5 frames to complete (off by one most likely, so 6). Probably not a big deal, but I can't come up with anything nicer without introducing a lot of complexity to my initialization
 
@Tyyppi_77 Why would you limit to 1 the amount of textures loaded per frame? To keep your framerate up?
 
To make the usage API nice as my ThreadedContentLoader::Load could essentially be implemented as return contentLoader.ProperlyMutexedPromiseVector.emplace(params).get_future().wait()
I.e. make promise, add to queue on main thread, wait on the future to complete, return pointer to loaded item & continue like all this was performed in sync
 
sounds like what I know about coroutines :P
 
I'm not sure how you have your futures set, but wouldn't it be better for the loading thread to notify the main thread only when all selected assets have completed loading?
Something like (pseudocode):
 
Again, the loading thread can't & won't load anything, it needs to request things to be handled on the main thread
 
4:56 PM
Load("texture 1", "texture 2");
etc
But it is loading the world
ah
you are right
I keep thinking the textures are also loaded there :P
 
@Tyyppi_77 The advantage in doing so, is only to have a nice flow in your content loader code?
 
It's to have a nice flow in my object initialization code
 
At the cost of only be able to load one texture per frame?
 
I can just create a sprite for my entity instead of requesting a texture, waiting for it & then finding out somehow what entity was missing a sprite
Yup, with the current architecture. I actually just realized that with the blocking approach, I could just parallelize stuff inside the world generation thread, and that would allow for more than 1 content load per frame
 
It would make sense to be able to load more than one content per frame; I think if it makes the code better, and doesn't destroy your framerate, then sure :)
 
5:02 PM
Framerate won't be affected obviously since it's the world generation thread that gets blocked
It's generation times that are affected
 
Hm, yeah; so the player could get to a point where they wait for the tiles to be generated if it's not fast enough?
 
It's a one time process before any gameplay happens, think something like Spelunky
 
Haven't played that.
But I get the idea.
 
Yeah idea is enough.
It's just a longer "Generating World..." screen between levels
 
Do you skip rendering frames when you display that loading screen, so that you get more time for other loading related activities?
 
5:07 PM
Currently there's no need to do anything special on the main thread when loading is happening, everything happens normally, gameplay state just renders a text instead of the world while the world isn't ready
 
Ok, then I guess if you realize that the process is taking too long, at some point, then you'll be able to revisit it and optimize it
 
Yeah, currently in release builds the loading screen just flashes for like a frame, but debug builds show it for a second or two due to iterator validation being super slow
 
Yeah, do you have a "full level" yet?
 
Not really, just a cave generation, spikes & an exit door that triggers another level to be made
Will need some kind of pathfinding at least to make sure a valid path to the exit exists
 
Ok, the real test will come with a full level then!
 
5:54 PM
Well that was pretty easy to implement, decided to just check the thread ID at the top of each loading function, and then call the same loading function again
if (std::this_thread::get_id() != MainThreadID)
{
    m_Mutex.lock();
    auto future = m_ThreadSafeLoadingTasks.emplace(key).Promise.get_future();
    m_Mutex.unlock();
    return future.get();
}
void TickMainThreadProcessing() override
{
    Assert(std::this_thread::get_id() == MainThreadID);

    std::lock_guard guard(m_Mutex);
    while (!m_ThreadSafeLoadingTasks.empty())
    {
        auto& item = m_ThreadSafeLoadingTasks.front();
        item.Promise.set_value(std::apply([this](auto... params) { return Load(params...); }, item.Parameters));
        m_ThreadSafeLoadingTasks.pop();
    }
}
std::apply is awesome
 
@Tyyppi_77 Helps make code more generic?
 
Yeah, I have a tuple of the parameters already ready for a cache map, so it's easy to just store that, and unpack to reuse the same function
 
Yeah, cool! not worth to use a struct for that?
 
Not really, it's easier to pass a tuple to my content loader base class, this is sort of a base class hell due to type erasure usage, but I have
class LoaderImpl<Texture> : public LoaderBase, public LoaderCacheBase<std::tuple<std::filesystem::path, TextureInterpolationMode, TextureWrapMode>, Texture>
Makes specifying that into a neat longish one liner :D
 
Ah ok!
 
6:39 PM
Hmm, entt's hashed_string works only on compile time character strings..
 
7:02 PM
Hmm I haven't found a use for that yet, what do you need to do?
 
Hash tags to stick on entities, for fast retrieval.
And use the same type of hashing everywhere in our software, ideally.
 
There's probably a reason why an enum won't work?
 
Yes, mainly because I don't want to have a registry of all the available possible tags.
entt's implementation shines because the hashing is done at compile time.
So I made a version of the class that takes a string instead... it compiles :P
 

« first day (3457 days earlier)      last day (31 days later) »