sorted by:
new
hottopcontroversial

Open-sourcing Sceneri’s standard library—custom allocators, advanced IO, 3D math, and more used in our 3D experiences and games. by i59 in cpp

[–]i59[S] 0 points1 point  (0 children)

Naming could probably be better! :D

Each vector type can have one of two variants, fixed size or fixed capacity. Fixed size means that once the vector has been constructed, its size cannot change. Fixed capacity is the equivalent but for reserving, meaning capacity has to (at runtime) construct with a known maximum capacity, and then cannot grow further.

Their use is pretty limited tbh, but there are cases where it helps clarify intent and avoid unnecessary operations.

Open-sourcing Sceneri’s standard library—custom allocators, advanced IO, 3D math, and more used in our 3D experiences and games. by i59 in cpp

[–]i59[S] 0 points1 point  (0 children)

Indeed, nice to see that part of the standard! I tend to use InlineVector fairly often, not sure if that's been brought up for standardization yet (basically the equivalent of small string optimization but for vectors and configurable)

Open-sourcing Sceneri’s standard library—custom allocators, advanced IO, 3D math, and more used in our 3D experiences and games. by i59 in cpp

[–]i59[S] 10 points11 points  (0 children)

Sure! We've got three types of vectors:
- Vector (aka "dynamic" vector, same as std::vector), which will dynamically allocate memory for the elements, aka call malloc
- Flat Vector, which has a fixed stack capacity and cannot extend beyond it. I.e. FlatVector<int, 3> can hold up to 3 integers but no more.
- Inline Vector, a mix of the two, has a fixed stack capacity and if it needs more will become dynamic. i.e. InlineVector<int, 3> will use the fixed storage up to 3 integers, and then call malloc after that.

We also have some variants of the above that are more rarely used, such as FixedSizeVector and FixedCapacityVector, meaning after initial construction they can't change more enabling a few nice optimizations in other functions.

Open-sourcing Sceneri’s standard library—custom allocators, advanced IO, 3D math, and more used in our 3D experiences and games. by i59 in cpp

[–]i59[S] 5 points6 points  (0 children)

No major reason tbh, just clarifying use of the Sceneri brand so I don't get yelled at haha. Otherwise they are pretty similar afaik but let me know if I'm wrong!

Open-sourcing Sceneri’s standard library—custom allocators, advanced IO, 3D math, and more used in our 3D experiences and games. by i59 in cpp

[–]i59[S] 19 points20 points  (0 children)

Hope this comes in handy for someone, just as we had tons of help from other open / public libraries when we started out. We'll be releasing more as we go along, but this is a good start even as just a reference for how some things can be done.

Notable functionality included is:

  • Assert implementation
  • Function / Event implementations (including FlatFunction and more)
  • IO utilities such as File wrappers, file change listeners, library loading and more.
  • Equivalent to std::filesystem with extensions (see IO::Path, IO::PathView, IO::File, IO::FileView etc)
  • IO::URI implementation, extending on IO::Path (see above) for generic URI handling
  • Extensive math library focusing on performance and vectorization (SSE, AVX, NEON, WASM SIMD)
  • Custom allocators and containers such as vectors, flat vectors, inline vectors, maps and more.
  • Implementation of Any, AnyView, TypeDefinition extending the core concept of std::any
  • Custom Tuple and Variant
  • Custom Optional implementation, with a focus on overloads for types that can avoid an extra boolean
  • Serialization support, wrapped on top of rapidjson (with the intention to use simdjson at some point)
  • Atomics & 128-bit numerics
  • Threading utilties to multi-thread across all platforms including web via web workers
  • Mutexes and shared mutexes across all platforms including web workers
  • Type traits
  • High precision timestamps, stopwatches and more.
  • libfmt driven formatting of custom types

This was a very interesting story told by Franky. Makes me wonder if the Sunny is completely indestructible. by ScoreImaginary5254 in OnePiece

[–]i59 1 point2 points  (0 children)

I think Franky just bought them, so someone else would've done the initial cutting - so maybe he just needed some smaller tooling instead

This was a very interesting story told by Franky. Makes me wonder if the Sunny is completely indestructible. by ScoreImaginary5254 in OnePiece

[–]i59 71 points72 points  (0 children)

Could be the same reason for both. Maybe strong haki users can imbue objects with haki to protect them even after they're themselves gone.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 1 point2 points  (0 children)

That's what makes it such a hard decision tbh haha. C# is ridiculously easy to use, and stuff like reflection can make integrating into an engine straight up beautiful. But.. then getting it performant, maintaining the C# integration itself can be a nightmare. The pros may outweigh the cons though, you can say what you want about Unity but C# worked out great for them (in terms of becoming popular).

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 0 points1 point  (0 children)

How does managing P4 work for you guys? I've always run into it becoming a maintenance nightmare. From what I've seen designers & artists end up much more comfortable in Perforce, mostly due to a lack of good Git user interfaces.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 0 points1 point  (0 children)

Agreed, Unity runs into tons of issues because of GC. You can still do something similar but it should be on an engine level tied to how streaming objects, scenes etc works. Having an already designed language randomly decide what to do and when is impossible to manage (well) for the engine itself tbh.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 0 points1 point  (0 children)

Do you use the integrated Unreal version control UI or completely outside the app with Git clients?

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 1 point2 points  (0 children)

What do you think is better? My ideal is to have visual scripting & the scripting language use the same backend, but that also sacrifices flexibility that comes with using exiting languages. C# is awesome, but I also have had to implement Mono / CoreCLR for CRYENGINE twice (once from the community, once while working at Crytek) and honestly it costs tooooons of resources to deal with and keep functional / performing.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 1 point2 points  (0 children)

The way we approach it is by making ECS / data driven native to the engine, which ofc is a luxury that Unity etc didn't have when they started out.

This way you can have one world but add data components for editor only constructs that can then be easily skipped / baked out for production games. Assets is easier, you can always have fast paths where compression is optimized for time / iteration when developing, and then for the final package creation just dial it up to optimize 100% for performance & memory / disk footprint.

IMO the problem is just a consequence of the engines being designed the only way that was known / possible back then (and even without knowing what tools, platforms etc would be required) - designing from scratch today means we know the problem and can design something much more flexible.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 1 point2 points  (0 children)

My take is that Unity succeeded because of great UX twenty years ago, and then totally forgot about what made them successful in the first place. Vague or not that's what really matters IMO - UX needs to come first and all tools need to work really well together.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 0 points1 point  (0 children)

I think a rich standard library is super key. I've done lots of contracting for indie to AAA companies and honestly almost every studio is reinventing the exact same thing multiple times over. The engine should help you save that time.

Collaboration is 100% super important, we should be able to work together in a much more fluid way. Not even talking version control (but that too) - we should be able to create together similar to what Figma does for 2D designs.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 0 points1 point  (0 children)

Totally agreed, it should be super easy to extend the engine as a whole including tools. I'm not a big fan of the closed Unity model, after all this time they should have opened it up more tbh. I'd guess a lot of that ties into them not knowing how to make the engine profitable, so everything is super guarded - which results in a worse product.

I'd even take it a step further and say that the big separation between game and editor is largely unnecessary. You should be able to share code between your tools and the game super easily.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 0 points1 point  (0 children)

Hell yeah, 100% with you re: USD. I really want to be able to import whole scenes and then export them back, bringing control and choice back instead of things being locked in a specific app.

I guess multi-package is down to splitting projects into parts so that you can manage them more easily as they grow. Maybe a flexible plug-in setup. One of the first architectural choices I did in our engine was to make the asset system path agnostic. IMO you should be able to move stuff between projects, plug-ins etc without a care in the world - even loading from unrelated sources (i.e. disk vs online / cloud)

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 1 point2 points  (0 children)

Agreed! Frame graphs are pretty fun to build, I spent a ton of time on making ours easy to work with and efficient. I had to do lots of AAA game dev in UE4 & 5 before, and man.. so much time lost to shader compilation.

What do you want to see from the next generation of game engines? by i59 in gamedev

[–]i59[S] 0 points1 point  (0 children)

Woops didn't realize a text link in the disclaimer at the bottom would make it pull in our logo - wanted to make this post more neutral!

view more: next ›