Thanks to the developers (+small bug report)

[Poplicola]

Thanks to the developers (+small bug report)

As a side project, I'm working on a UO client, written in XNA. Using Ultima SDK, I was able to get the landscape up and drawing in less than a week, and I doubt that statics will prove too difficult.

This library is very clearly written and easy to modify. To get it working All I had to do was change the bitmaps to Texture2D. Thanks to the developers for putting in the work to make this library so usable.

I've run across one small bug: landscape texmaps 0x3ff8 through 0x3ffb return null. Is it possible that these texmaps are in the patch files, not the original texture muls?

 

[Jeff]

As a side project, I'm working on a UO client, written in XNA. Using Ultima SDK, I was able to get the landscape up and drawing in less than a week, and I doubt that statics will prove too difficult.

This library is very clearly written and easy to modify. To get it working All I had to do was change the bitmaps to Texture2D. Thanks to the developers for putting in the work to make this library so usable.

I've run across one small bug: landscape texmaps 0x3ff8 through 0x3ffb return null. Is it possible that these texmaps are in the patch files, not the original texture muls?

I doubt it, what does the idx data say for those ids?

 

[Poplicola]

I doubt it, what does the idx data say for those ids?

I hadn't thought to look there.

The FileIndex referenced by UltimaSDK.Textures has a limit of 0x1000 texmaps:

private static FileIndex m_FileIndex = new FileIndex("Texidx.mul", "Texmaps.mul", 0x1000, 10);

Increasing the upper limit to 0x4000 in the Textures.cs constructor fixed the problem, at the cost of about 13000 extra unused Entry3D structures.

Thanks!

 

[Jeff]

I hadn't thought to look there.

The FileIndex referenced by UltimaSDK.Textures has a limit of 0x1000 texmaps:

private static FileIndex m_FileIndex = new FileIndex("Texidx.mul", "Texmaps.mul", 0x1000, 10);

Increasing the upper limit to 0x4000 in the Textures.cs constructor fixed the problem, at the cost of about 13000 extra unused Entry3D structures.

Thanks!

Yup, those extra 13000 extras probably don't take up much memory