Entity 2.1.24

[OwnZ joO]

I recommend sharpziplib(which is the .net version of lzma compression(7zip)), or you could just used the Gzip compression that comes with .net framework to zip it up, and to unzip that package. 7zip can unzip rar files btw, just can't make them.

[Eaton]

I recommend sharpziplib(which is the .net version of lzma compression(7zip)), or you could just used the Gzip compression that comes with .net framework to zip it up, and to unzip that package. 7zip can unzip rar files btw, just can't make them.

Meh.. http://xceed.com/Zip_Net_Intro.html

Shade45's Engineer source has a good example of an updater using that library.

Or you can do what I do and create a custom package format. Using this http://xceed.com/Streaming_ActiveX_Intro.html and other metadata.

[OwnZ joO]

Or he could use free and open source software...

[Twinreaper]

Troy, along with bsp extraction to a single obj, (already works for some maps, not all) you may also want to figure out why Entity has problems outputting the instanced geometry properly. For an example, output Turf's bsp into a single or multi obj, and import it. You will see all sort's of fugged up shaped crap. Also, when the instanced geometry that is read properly is extracted, when you import those model sections into a 3d app, it does not place them properly.....they often tend to be far away from the bsp. It gets to be annoying if you have to constantly check bsp viewer, then move the geometry manually. Just thought I would chime in on that. That crap has bugged me for a while now...but not that any fixes will help me...just looking out for the rest of the community that is still active.

[Ogrish]

Theres an error/ or maybe just a new impliment in meta editor,(SCRN) obsticle placements.

When you try to change the pallet chunk, it pops up a new window, for editing the plugin, for the placement chunk.

Or something to that effect, it pretty interesting but i dont know how to use it properly.

Request: Bsp scenery objects, it would be nice if i could extract/inject these models, without extracting the whole bsp to models, also called permientaions or something like that.
Infact if we could just move em without losing collision, the world would be a better place.
Ofcoarse this will come when pigs fly, and the sbsp tag is fully mapped out.

Just had to get that out there.

[troymac1ure]

Not sure what window you are referring to. I added a popup window for StringIDs, but that's all I can think of. Maybe post a pic of it. I will look into it, but I'm disliking the Meta Editor. So many issues no matter how I approach it.

It's been nice working on the Mainmenu editor as it's all new code (all mine) so I can set it up easy to understand and use. Just need to get bitmap injection/extraction working. I have it auto-inject from the map when a map is added, but I'm having issues pulling it from a file and adding it for some stupid reason. I'm using some of Entity's routines, so I may just drop that and write my own new routines.

Also, as of right now the Campaign changes don't save. I'm making the editor almost completely automatic (no manual IDs or need to internalize spots for bitmaps, etc) but I'm not positive of the setup for campaign maps. I will look into these once the MP stuff is complete.

[JacksonCougar]

How are you adding info to the map? Because if you shift the raws then you break the maps.

[Ogrish]

If i try to change the pallet chunk, this happens.

[troymac1ure]

How are you adding info to the map? Because if you shift the raws then you break the maps.

Adding the data to the end of the raw section (index offset) and shifting the data past there over. I took the code from TunesRus90's (Java) Bitmap Internalizer. The same code I use in Entity for internalizing bitmaps.

If i try to change the pallet chunk, this happens.

Oh, that box... You weren't supposed to find THAT box.

Yeah, I'll fix that. Must be a different setup in the 'Index' values. It was the start of an instant control swapper. So you could change Int to Tag or whatever, but it was complicated, I was spending alot of time on it and it's not a major thing, so I left it for now and moved on to different code.

[troymac1ure]

Troy, along with bsp extraction to a single obj, (already works for some maps, not all) you may also want to figure out why Entity has problems outputting the instanced geometry properly. For an example, output Turf's bsp into a single or multi obj, and import it. You will see all sort's of fugged up shaped crap. Also, when the instanced geometry that is read properly is extracted, when you import those model sections into a 3d app, it does not place them properly.....they often tend to be far away from the bsp. It gets to be annoying if you have to constantly check bsp viewer, then move the geometry manually. Just thought I would chime in on that. That crap has bugged me for a while now...but not that any fixes will help me...just looking out for the rest of the community that is still active.

Thanks for the info. I checked into Turf and found the 'trails' all over the place. Took a quick look at the object file and realized that the faces near the end were listed as negative values. Looking at the code, apparently they decided to cast the faces to a SHORT value, so after 32767 faces, it would start listing them negative, which to no surprise really screwed up the 3D modeling programs. Changed them to an Int and now the tails are gone, but it's still not right. At least now you can actually recognise the level though. I'll keep working on this.

[neodos]

I doubt that's a short, 32767 * 2 = 65534 so close to 65535 which is the limit of a variable, what i mean is its probably not a short since that's its limit value,what is the value like as int?

[OwnZ joO]

Unsigned int is 4,294,967,295, signed int is 2,147,483,647

[troymac1ure]

I doubt that's a short, 32767 * 2 = 65534 so close to 65535 which is the limit of a variable, what i mean is its probably not a short since that's its limit value,what is the value like as int?

Actually short is -32,768 to 32,767, which is 0 to 65536 if it is a U<nsigned>Short. By converting it to an Integer value, it allows, like OwnzJoO said, 2,147,483,647 which I am fairly certain is enough to contain all the faces in the BSP. After changing the cast from short to int, 80% of the map was fixed. There are no longer tails joining unconnected walls, but there are holes in them, so I still need to find the other issue.

[troymac1ure]

Troy, along with bsp extraction to a single obj, (already works for some maps, not all) you may also want to figure out why Entity has problems outputting the instanced geometry properly. For an example, output Turf's bsp into a single or multi obj, and import it. You will see all sort's of fugged up shaped crap. Also, when the instanced geometry that is read properly is extracted, when you import those model sections into a 3d app, it does not place them properly.....they often tend to be far away from the bsp. It gets to be annoying if you have to constantly check bsp viewer, then move the geometry manually. Just thought I would chime in on that. That crap has bugged me for a while now...but not that any fixes will help me...just looking out for the rest of the community that is still active.

Here's what I got now:


The BSP permutations are output to a second .obj file, which are loaded on top of the bsp .obj file. The only issue I have now is that for some reason the BSP permutations are not loading textures. Maybe someone else can help me see what I'm doing wrong once this release is out.



As for the permutations being in the wrong spot, the BSP viewer had this line:
device.Transform.World = bsp.PermutationInfo[x].mat;
which was a listing of transforms for each Permutation. This was not being used on extraction, so they'd all end up in the middle of the map instead of being translated to their proper positions.

Also, I spent forever trying to figure out how to get all the objects to extract in the proper direction until I figured out you have to deselect "Unify (normals)" in 3ds max's import options. OMG.

EDIT:
Just realized that all textures are applied upside-down. Reversed the Y direction and now signs and storefronts show correctly on turf.

EDIT2:
Just fixed the box that was poppping up when clicking on an Index Block & fixed the issues with custom plugins. Here's a screenshot:

[troymac1ure]

First, i know i should be using a different app for this, but anyways, here goes.

I select SBSP, click parsed then hit SAVE, it asks me what name and i choose the sujested one, gemini.sbsp, it saves it.
now i open the .sbsp in Detox's weather tool and add weather, so far so good.
I cant inject back in with Entity because the size has grown, so i try to build, but sorry no .info file was created. Damn it!

So can you make Entity create the .info file for sbsp when saving it to file please.

Just looked into this and apparently you don't need an INFO file. All the info file contains is a listing of files to be imported. Change the selection type from (Info File *.info) to (All Files *.*) and select the bsp file without the .xml extension (don't select the raw as well as that is done automatically)
You should be able to do this with any version.

[Twinreaper]

When you get an update up, let me know about it. I wanna try a few things out.

[Prey]

Hey looks good so far. Shame about my meta editor lol!.. guess I didn't test it enough soz guiz :3

If you want to save some memory with the bsp viewer:

1. To load a texture, entity first puts it into a bitmap class, before converting it to a directx texture class. This means every texture is copied twice. Entity actually also copies the decoded buffer too for some reason, before putting it into a bitmap class. Thus the texture is copied 3 times.. You should be able to change decode->copy->bitmap->texture into just decode->texture.

2. Many subclusters reference the same shader, and each shader has it's own texture. A good example is relic which has one ground texture for the entire ground. The difference is each subcluster has different texture UV's so it all works out. The problem is entity doesn't check for shaders it's already made, thus it makes wayy to many duplicate textures equaling a lot of redundant memory. In the shader load code, keep a check on what shaders you already have, and just reference an existing shader if you already have it.

[troymac1ure]

Using is one thing (thanks for the advice), but it eats memory. I know exactly where, but not sure how to fix it.
When it loads bitmaps, it builds it from a stream without a bitmap header, so they use code like this: (could be wrong I don't have the code near me right now so it's from memory)

Code: Select all

IntPtr ptr = new IntrPtr();
ptr = Marshal.AllocHGlobal(bitmStream.Size);
public Bitmap(
	bitmStream.width,
	bitmStream.height,
        bitmStream.stride,
	bitmStream.pixelformat,
	ptr);
return b;

This isn't the exact code, but as you can see, it allocates memory for the bitmap stream, then creates the bitmap and returns. AKA the memory is lost in space.

I tried this:

Code: Select all

IntPtr ptr = new IntrPtr();
ptr = Marshal.AllocHGlobal(bitmStream.Size);
public Bitmap(
	bitmStream.width,
	bitmStream.height,
        bitmStream.stride,
	bitmStream.pixelformat,
	ptr);

Bitmap b2 = new Bitmap(b);
Marshal.FreeHGlobal(ptr);
return b;

and it released the memory almost completely eliminating the memory leak, but the large textures were screwed (coag flood texture was black at the top of the mounds, lockout ground around dish was black & ramps had black traces on them).

I have now passed a parameter to the FindChunkAndDecode() function (that the above code is in) with returns the IntPtr reference. I store these in an List and then on bsp Dispose I release them, but it doesn't seem to work. Not sure why.

Any ideas?

[Prey]

Try not to deal with pointers, it's unnecessary in this case. When you say bitmap header, what do you mean? because there is width/height etc information available for each bitmap raw in the map. Don't think you need it in a header+data .bmp format for it to work, instead once the function has decoded the image it has all the pixels in a byte array. Now instead of copying or putting this data in a Bitmap class, just put it straight in a directx texture class. If you already knew this then sorry but your post was hard to understand :S

[troymac1ure]

Taken from Entity's original code:
bitmBytes is a byte[] that contains the bitmap data with no header information. All the header information (height, width, bitsPerPixel, etc) is taken from the BITM tag.

Code: Select all

  IntPtr intPtr = new IntPtr();
  // ...
  stride = DecodeBitmap(ref bitmBytes, height, width, 1, bitsPerPixel, type, format, swizzle, mapnumber, visualchunkindex, ident);

  Marshal.FreeHGlobal(ptr);
  intPtr = Marshal.AllocHGlobal(bitmBytes.Length);
  RtlMoveMemory(intPtr, bitmBytes, bitmBytes.Length);
  Bitmap b = new System.Drawing.Bitmap(width, height, stride, PixelFormat.Format32bppArgb, intPtr);
  return b;

I always wondered why they Freed the pointer before using it as it is declared locally at the top of the function. I realized they couldn't do it after, because when creating a Bitmap using IntPtr, it expects IntPtr to be reserved until the bitmap is destroyed, but the code was just allocating the data, then letting the pointer disappear, leaving the allocated memory lost.

So I tried this:

Code: Select all

  IntPtr intPtr = new IntPtr();
  // ...
  stride = DecodeBitmap(ref bitmBytes, height, width, 1, bitsPerPixel, type, format, swizzle, mapnumber, visualchunkindex, ident);

  intPtr = Marshal.AllocHGlobal(bitmBytes.Length);
  RtlMoveMemory(intPtr, bitmBytes, bitmBytes.Length);
  Bitmap b = new System.Drawing.Bitmap(width, height, stride, PixelFormat.Format32bppArgb, intPtr);

  Bitmap final = new Bitmap(b);
  Marshal.FreeHGlobal(ptr);
  b.Dispose();

  return final;

And it mostly worked, except large areas (strecthed possibly) had black marks on the texture. Not sure why, but I noticed in the BSP viewer code it accesses the textures with pointers, so maybe not have the memory in managed memory screws it up?


I need to look at the texture stuff and see how to place the bitmByte[] straight into a texture instead like you are stating.

[JacksonCougar]

I thought entity used lockbits();

[Prey]

I don't remember the exact code but black patches sounds like corrupted memory yes. It should be easy enough to declare a dynamic texture and place the data straight in, you'll have to lock/unlock, but there will be samples on the net. Here's how I do it in XNA if it helps:

Code: Select all

	     public static Texture2D DecodeToTexture2D(...)
        {
            SurfaceFormat surfaceformat;

            switch (bitmapInfo.Format)
            {
               ... decode to 'imgBuffer' byte array
	            ... surfaceformat = (...)
            }

            Texture2D tex = new Texture2D(graphicsDevice, bitmapInfo.Width, 
                bitmapInfo.Height, 1, TextureUsage.None, SurfaceFormat.Color);

	         // Texture2D expects data in integer format not bytes
            uint[] intBuffer = new uint[bitmapInfo.Width * bitmapInfo.Height];
            for (int i = 0; i < intBuffer.Length; i++)
            {
                int j = i * 4;
                byte r = imgBuffer[j];
                byte g = imgBuffer[j + 1];
                byte b = imgBuffer[j + 2];
                byte a = imgBuffer[j + 3];
                intBuffer[i] = (uint)((a << 24) | (b << 16) | (g << 8) | r);
            }

            // copy our buffer to the texture
            tex.SetData<uint>(intBuffer);

            return tex;
        }

SurfaceFormat, SetData(), and converting to an int buffer are all XNA specific code; it'll be done differently in MDX.

[XZodia]

for all intents and purposes xna and entity are at opposite ends of a scale...so its code won't help...
as for the pointer business, i suspect the bitmap class doesn't copy the data from the pointer and frees it itself...you should check msdn

[Prey]

Not neccessarily; XNA is bassically the next level up from MDX: the concepts are the same, and the methods are similiar.. I did also note the differences

[troymac1ure]

New version! Too lazy to post updates right now, but it's in the Updater info screen.

Mainmenu editor has been tested.