> You load assets on game start and forget. The entirety of them?
You load assets on game start and forget.The entirety of them?
ZWouldn't it like, take quite a lot of RAM?
ZThan loading them runtime
FYou need only current level which is limited by size of GPU RAM.
Loading something bigger than 4GB on user device with 8Gb / 4 Gb RAM not really productive. It will swap as hell.
Loading something bigger than 4GB on user device with 8Gb / 4 Gb RAM not really productive. It will swap as hell.
ZSo the best strategy is to load resources required at the current level before it starts?
FUntil ALL user devices have fastest drives which really could load files without impact on overall system. Maybe in future we will have nice dirves and yes, load data at runtime without waiting.
FSoftware solutions in 1st order depend on user devices, and many users stil have old hardware, they use Windows 7 and install games on HDD.
LNo time to explain someone ping jvyden to patch me back in I know this is the wrong channel
LI am on my watch
Z@jvyden4
Jgot it
Jthey lost internet and have to talk through their watch, we have to communicate via them replying to discord messages
J
Z:0
N
RThat is not always a valid strategy
RAgain, open world games
ZHmm
PIf you can’t find it in Silk.NET.OpenAL.Extensions.Soft then the answer is probably no, but thankfully OpenAL extensions are super easy to add if you wanted to give it a go!
Ntime to become a contributor
Nhow would you guys implement openal buffers and sources? since the preferred method is streaming audio data I guess its to make a pool of buffers and sources?
Ause a circular set of buffers. write to them, queue them, then as one buffer finishes, write to it and queue it again
Noh so a pool?
Ain terms of sources i always just created all of the sources at once, but you can just create a source as and when you need it
Aessentially
Aone sec
Ahttps://github.com/piegfx/Easel/blob/master/Easel/Audio/VorbisPlayer.cs this vorbis player shows what i mean
Nohh I see
NI think I can also do chunked audio data streaming
Nprobably 32kb at a time
Nthough looping might be a disaster
Athis pretty much is chunked audio streaming. the buffer is just very short
Nstill trying to understand the relationship between buffers and sources
NI think every time you enqueue buffers it gets appended to the source?
Aa buffer is basically just a region of memory that stores PCM data.
a source plays back these buffers.
you can have multiple buffers queued in a source
a source plays back these buffers.
you can have multiple buffers queued in a source
Acorrect
Nah
Nhow would you "reuse" a source?
Nsince buffer data gets appended to a source
Awith openal i believe you have to manually remember to dequeue the buffers, which means you have to add it in your update loop.
that's ultimately the reason i replaced openal with my own library, because mine doesn't require an update loop at all to dequeue buffers, it just requires a callback
that's ultimately the reason i replaced openal with my own library, because mine doesn't require an update loop at all to dequeue buffers, it just requires a callback
Areuse a source? sources are inherently reusable. just tell it to play a buffer instead of queueing one and it will replace all the queued data and start playing whatever you tell it to
Nwhat I mean is if the source has finished playback and I want to replace the data that has been processed on that source
Aah
yeah this is what i mean by the fact that you have to manually dequeue the buffers in your update loop
yeah this is what i mean by the fact that you have to manually dequeue the buffers in your update loop
Ait's a complete PITA and i hate it
Awhich is the reason i wrote my own, since it does it all automatically unlike openal which doesn't for some unknown reason
Topenal feels like an audio cousin to opengl
Nit is from what I've read from its history
Nalso I think I'm slowly understanding it now
NI got confused because a lot of examples "unqueue" the buffers before playing the source
Ttldr: openal may explode on you depending on its mood
A