You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, everytime the linker runs it builds every asset entirely new from its source material.
This can include parsing source files, processing them and converting the data to the target game.
This process can be shorted for some assets by caching the resulting asset and only processing the input again, if itself or one of its included files was changed (e.g. for menus).
This process however is only worth doing on assets that take a considerable amount of effort to build.
For example caching something like stringtables would probably not grant any noticable performance increase.
Depending on how the assets are parsed this cannot happen on an "per asset" basis though.
For example menus must be cached on a per file basis, since one file can include a menulist or 0,1,* menus.
For file based sources the caching can check for changes by just considering the filesystem's last modified timestamp (This is also how MSVC seems to do it).
For gdt based sources it will probably be necessary to use a checksum like CRC.
It is important to consider all source files for an asset instead of just the entry file.
For example a menu can be located inside file X which included file Y however, which defines a macro.
In this case, the cache must be considered dirty, even when only file Y changes.
The text was updated successfully, but these errors were encountered:
Currently, everytime the linker runs it builds every asset entirely new from its source material.
This can include parsing source files, processing them and converting the data to the target game.
This process can be shorted for some assets by caching the resulting asset and only processing the input again, if itself or one of its included files was changed (e.g. for menus).
This process however is only worth doing on assets that take a considerable amount of effort to build.
For example caching something like stringtables would probably not grant any noticable performance increase.
Depending on how the assets are parsed this cannot happen on an "per asset" basis though.
For example menus must be cached on a per file basis, since one file can include a menulist or 0,1,* menus.
For file based sources the caching can check for changes by just considering the filesystem's last modified timestamp (This is also how MSVC seems to do it).
For gdt based sources it will probably be necessary to use a checksum like CRC.
It is important to consider all source files for an asset instead of just the entry file.
For example a menu can be located inside file X which included file Y however, which defines a macro.
In this case, the cache must be considered dirty, even when only file Y changes.
The text was updated successfully, but these errors were encountered: