The First Video

[flash]

Done a little video for now as there is no download for testing as yet. The reason for no download is because I am ruminating about the level save format.

What I want is a single file for lots of levels (so all 20 manic miner levels could be a single game file) and also any extraneous files. Currently, each level can have an accompanying screenshot. But, what I want to add (users choice) is,
Level Overlay,
Level Underlay,
Level Custom Tiles,
Level Custom Actors.
This is really (well the last 2) for Manic Miner games so that they can be constructed in the same way as the original game was.

Anyway, here's a video, let me know what you think?

[Sokurah]

Excellent. I'm really impressed over how much and how many modes you've fitted into this. If I'd done it the code would be unmanageably bloated and horrible. I hope you're doing better.

[headkaze]

You know I still think you should consider using zip/7zip. Extract the level data into the folder structure you want when you need to. Have a special data file at the beginning of the archive that you can read without extracting the rest of the data. This can contain info such as name, author etc. (data you will need for a level selector etc.)

Back when we were developing for NDS we were using the EFS file system. It's pretty simple you could write a little utility to generate a similar thing. Basically you have a header struct and each file has an entry struct. Data doesn't have to be compressed and if your current data reading code supports streams (which it should since it's Mono) you should in theory be able to point your data readers to an offset in the stream to read the data directly.

Excellent. I'm really impressed over how much and how many modes you've fitted into this. If I'd done it the code would be unmanageably bloated and horrible. I hope you're doing better.

For a guy who started out as an asm coder and having little to no formal training in higher level languages / OOP he does pretty well

[flash]

Thanks for the kind words guys

Thankfully the code is not too bloated as a lot of the code is reused across the engines. That's not to say the code is overly tidy though I could do with a little tidy up at some point.

I will give some thoughts about zipping the level stuff up, my only thought on this is the screenshots that are used in the load dialog. They would have to be extracted to be shown, and even now with them alongside the levels (and sharing the same name) it is not instant by any means and they have to be populated on a thread.

[headkaze]

If your screenshots are in png format then they're already compressed using a zip-like compression routine so you won't get any benefit from zipping them.

There are a few things you can do to improve loading time:
- Save a smaller thumbnail image
- Save as png 8-bit palette format
- Save as jpg format

[flash]

Currently, the screenshots are resized to 640xscale and stored as png's. The real problem with the delay is converting them to a texture for use in the ui.

This involves this process (until I can think of something better)

Code: [Select]

if (System.IO.File.Exists(m_docPath + filename))
{
byte[] bytes = File.ReadAllBytes(m_docPath + filename);
Texture2D texture = new Texture2D(1, 1,TextureFormat.RGB24, true);
yield return 0;
texture.LoadImage(bytes);
texture.filterMode = FilterMode.Trilinear;
texture.Apply();
yield return 0;
m_levelSnapshot.enabled = true;
m_levelSnapshot.sprite = Sprite.Create(texture, new Rect(0,0,texture.width, texture.height), new Vector2(0.5f,0.0f), 1.0f);
// img.sprite.texture.filterMode = FilterMode.Trilinear;
yield return 0;
}

[headkaze]

Here is a method, although it's not much different to yours.

Code: [Select]

public static Texture2D LoadPNG(string filePath)
{
if (!File.Exists(filePath))
return null;

byte[] fileData = File.ReadAllBytes(filePath);
Texture2D texture = new Texture2D (2, 2, TextureFormat.BGRA32, false);
texture.LoadImage(fileData);

return texture;
}
I would try using a 32-bit texture format which more closely resembles what hardware these days uses internally. Unfortunately with Unity we don't have access to the lower level functionality of Texture2D so we can't do any further improvements on its performance other than giving it the closest format it needs. It would be interesting to have a look at the Texture2D class using Reflector to find out how it converts the byte array into the texture data.

So other than changing to 32-bit, using a smaller image size or moving to jpeg (which I'm not even sure if Unity supports?) I don't have much else to suggest. Jpeg could substantially improve load times if you're willing to suffer a slight degradation of image quality. If you experiment with image size and compression levels you might get a worthwhile improvement.