cocos2d 场景转换时加载的大小和总大小

发布于 2024-12-11 18:41:01 字数 105 浏览 0 评论 0原文

我正在做一个进度条来显示场景 1 -> 的过渡时间内的当前进度。场景2 只是我的进度条值将基于当前加载的资源大小和加载场景 2 所需的总资源大小 但我不知道如何获得这两个值。请帮我。多谢。

I'm doing a progress bar to show the current progress during transition time from scene 1 -> scene 2
simply my progress bar value will base on current loaded resource size and total resource size needed to load scene 2
But I don't know how to get these 2 values. Please help me. Thanks a lot.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

橙味迷妹 2024-12-18 18:41:01

对您来说,“资源规模”是多少?

如果您考虑一个图像文件,那么该图像文件在磁盘上的大小可能会或可能不会被压缩,压缩程度取决于文件内容。图像文件被加载到具有内存大小的纹理中。这也可能被压缩(PVR)或不被压缩。最后,磁盘上图像的大小、压缩和内存表示(位深度等)都会影响加载该图像所需的时间。

如果将其扩展到其他资源类型,例如声音文件、属性列表、数据库,则基于某些任意的、难以定义的“资源大小”来控制进度条将变得极其困难。

长话短说:您可以获得文件的大小。您可以以此为基础设置加载栏,但它根本不会反映实际的加载时间。

您还可以估计或计算资源占用的内存量,即 2048x2048x32 位纹理为 16 MB - 除非它甚至在内存中也被压缩(PVR 纹理)。但这需要对每个资产的数据结构有深入的了解。另外,例如,如果您只加载其中四个纹理,则进度条将在每个纹理后跳至 25%、50%、75% 和 100% - 您无法知道设备“加载纹理的进度”在这种情况下使进度条顺利进行。

长话短说:

大多数进度条只考虑正在加载有多少资源。您可以从放入场景的代码中知道这一点,即。您加载哪些图像、音频文件等。除非您从数据文件加载整个场景,例如使用某种设计工具,否则在加载资源之前您不会知道运行时的资源数量。

另一种方法是在每个资源块之后更新进度条,以便您可以将进度条进度分为几个具体步骤。如果很少的资源需要花费大部分时间来加载,并且它们是原子块(即 2048x2048 纹理图集),需要几分之一秒的时间来加载,而没有任何更新进度条的机会,那么这特别有用。

最后,除非您实际看到加载时间超过 3 秒,否则进度条毫无意义。在这种情况下,您最好花时间优化加载时间。例如,通过选择理想的纹理格式、使用纹理图集、避免冗余资源加载、推迟某些资源的加载或在单独的线程中加载它们,可以完成很多工作。

What is a "resource size" to you?

If you consider an image file, then that image file has a size on disk which may or may not be compressed, with compression depending on file content. The image file gets loaded into a texture, which has an in-memory size. That too may be compressed (PVR) or not. Finally, the size of an image on disk, the compression, and the memory representation (bit depth etc) all factor into how long it takes to load that image.

If you extend that to other resource types like sound files, property lists, databases it gets extremely difficult to control a progress bar based on some arbitrary, hard to define "resource size".

Long story short: you can get a file's size. You can base your loading bar on that but it won't reflect the actual loading time at all.

You can also estimate or calculate the amount of memory a resource takes up, ie a 2048x2048x32bit texture is 16 MB - unless it is compressed even in memory (PVR textures). But this requires intimate knowledge of each asset's data structure. Plus, for example if you only load four of these textures your progress bar will jump to 25%, 50%, 75% and 100% after each texture - you have no way of knowing "how far into loading the texture" the device is to make the progressbar progress smoothly in such cases.

Long story short:

Most progress bars simply consider how many resources are being loaded. This you know from the code you put into the scene, ie. which images, audio files, etc. you load. Unless you load your entire scene from a data file, for example if you use some kind of design tool, you won't know the number of resources at runtime until after they're loaded.

An alternative is to update your progress bar after each block of resources, so that you can divide the progressbar progress into few, concrete steps. This is particularly helpful if few resources take most of the time to load, and they are atomic chunks (ie 2048x2048 texture atlas) which take several fractions of a second to load without any chance of updating the progress bar.

Finally, unless you actually see a loading time of 3+ seconds a progressbar makes little sense. In that case you may better spend your time on optimizing loading times. For example a lot can be done by choosing the ideal texture format, by using texture atlases, by avoiding redundant asset loads, by deferring loading of certain assets or loading them in a separate thread.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文