I wish I could shut up for a day or two but sometimes you find something and then just want to write it down. Or it finds you and crashes your debugger and leaves you no other choice:
https://blog.s-schoener.com/2024-12-17-unity-blobs/
=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place
@sschoener I wonder if you could address this by reflecting the members and doing a manual pointer patch at load time, without changing the data.
=> More informations about this toot | More toots from dotstdy@mastodon.social
@dotstdy Not sure I understand what you mean :) - The goal of the blob asset design was to avoid having to do any pointer patchup during streaming, so that solution was explicitly ruled out (but it would work). Or are you suggesting something else?
=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place
@sschoener right I get that, but you might want to ignore that when debugging for example. But it really depends on how games feed data in I suppose. If it's controlled by the engine it's probably possible, if not, perhaps a struggle.
=> More informations about this toot | More toots from dotstdy@mastodon.social
@dotstdy The crux is that blob assets can still be copied after loading them. A redesign that explicitly forbids this and reserves memcpy just for loading in optimized builds would likely allow to implement your solution, yeah. -- Even without that redesign, I'd wager that your suggestion would at least reduce the error rate, so it's maybe worth consdering for Unity.
=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place
@sschoener yeah copying would kinda suck, and destruction generally too. There'd invariably be some users for whom it'd be difficult to salvage.
=> More informations about this toot | More toots from dotstdy@mastodon.social
@sschoener basically in debugging friendly mode, when you load a blob, allocate it from / copy it into a known (or just highly aligned) base address, and patch the offsets to be base relative, switching the deref code to do the appropriate lookup. It's kinda awful, but maybe kinda awful is better than debugger crashing. Relies on reflection being able to find the refs though, so idk how feasible it would be in practice.
=> More informations about this toot | More toots from dotstdy@mastodon.social
@dotstdy "kinda awful" definitely beats crashing :)
=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place
@sschoener I suspect the only good solution would be ref-only types / pinning somehow, which I guess is especially unlikely with the ancient mono :')
=> More informations about this toot | More toots from dotstdy@mastodon.social
@dotstdy Even C#'s newer ref-structs don't disallow copying, so that wouldn't help. My solution to this problem so far is "rewrite it in native code."
=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place
@sschoener Up to this day I don't quite understand why the push back then was "everything must be in C# only". A concept of a blob asset? Sure, yes please. Why it has to be implemented in pure C# though?
=> More informations about this toot | More toots from aras@mastodon.gamedev.place
@aras mumble mumble packages mumble separate runtime mumble
=> More informations about this toot | More toots from sschoener@mastodon.gamedev.place
@sschoener right right right right
=> More informations about this toot | More toots from aras@mastodon.gamedev.place This content has been proxied by September (3851b).Proxy Information
text/gemini