Textfile or 2D array

Started by
1 comment, last by SeanMiddleditch 10 years, 2 months ago

Which method is the most efficient when it comes to tile maps. Or does it depend on the situation at hand.

Advertisement
Neither is necessarily an issue. Much more important is how you read the data.

If you read the data as a single byte or word, then load another byte, then load another byte, calling the functions many million times, loading the data will be fairly slow.

If you read the data as a large block, or perhaps as two or three or ten large blocks, calling the functions only once or twice or ten times, loading the data will be fairly quick.

While the disk is generally read in large blocks and data cached many places by both the OS and by your compiler's implementation, each function call has a cost. Testing caches, setting up and tearing down function call information, and other work can quickly become a problem. When you have a few kilobytes or a small number of calls, neither method is likely to be a performance concern. For larger number of calls the overhead can very quickly become a significant amount of time.

"Most efficient" cannot be qualified. Test both and see which is faster for your game in your specific setup.

Note that with text it does help to use zlib or the like to compress it. In some cases, text will compress better than binary equivalents.

I would not even remotely worry about efficiency until you're closer to shipping your game. During development and testing a few milliseconds of load time is not going to matter. Being able to easily add your levels to Subversion/Mercurial/Perforce/git however and merge or review changes _is_ going to be very handy, however.

Game engines typically should support both a convenient source format for data (text in many cases where it makes sense) and a highly compressed/efficient packed form. The version of the game you ship only supports reading the packed form and you only ship the packed resources. The developers use builds that support both forms. Tools are created that convert from the convenient format to the efficient format for making releases. The development versions of the engine have a variety of other niceties like allowing content creators to drag-n-drop files onto the game add new assets, hot-keys to reload all in-game content, or automatic detection of modified source assets and automatic reloading. None of those things are _efficient_ in terms of CPU costs, but they are extremely efficient in terms of getting work done.

Don't optimize for the CPU too early. Optimize for your time.

Sean Middleditch – Game Systems Engineer – Join my team!

This topic is closed to new replies.

Advertisement