Important information: this site is currently scheduled to go offline indefinitely by end of the year.
[X360] Star Wars Battlefront III pre-alpha (*.x2t)
-
- Moderator
- Posts: 1007
- Joined: Mon Mar 23, 2009 2:57 am
- Has thanked: 44 times
- Been thanked: 505 times
Re: [X360] Star Wars Battlefront III pre-alpha (*.x2t)
I don't have this game/data, and looking at the samples provided on page 1 the rip is clearly fucked. Thoughts:
- No runtime is going to be intuiting image format/size from file size, find the proper place to get reliable header data (possibly another archive/binary entirely) before running around in circles.
- Don't use the raw untile function on DXT data. The routines for each are very different. (the Noesis implementation isn't based on any existing code in the wild)
- Some of the "garbled pixels" shots provided in this thread are telltale signs of trying to interpret tiled DXT1 as tiled DXT5.
- You aren't limited to DXT1-5, a number block compression formats are also possible which don't even fall under moden BC*, including a DXT1 normal map compression. (Noesis supports these as well)
- Tiling/twiddling/etc. is of course lossless. If you think about the reason to use any form of micro/macro tiling mode, and what Morton coordinates give you, you can see that it's all about maximizing efficiency of the texture cache. It's just the same data, but sampling patterns are usually going to dictate that caching that texture block that lays out linearly in memory is going to be of much greater benefit than caching the rest of a linear-ordered row of pixels occupying the same memory.
- You need to be obeying expectations for implicit alignment between rows (or rows of blocks in the case of DXT), mipmaps, and cube faces as applicable. For example, a 30x30 DXT1 texture will contain block data for a 32x32 texture, as a single DXT block represents 4x4 texels. There are also different alignment/padding requirements depending on the format/tiling for mipmaps and cubemaps. Tiling may also dictate row alignment/padding beyond DXT block-alignment. If variable modes are employed then the correct header data for each texture no doubt specifies this.
Ok, have fun.
- No runtime is going to be intuiting image format/size from file size, find the proper place to get reliable header data (possibly another archive/binary entirely) before running around in circles.
- Don't use the raw untile function on DXT data. The routines for each are very different. (the Noesis implementation isn't based on any existing code in the wild)
- Some of the "garbled pixels" shots provided in this thread are telltale signs of trying to interpret tiled DXT1 as tiled DXT5.
- You aren't limited to DXT1-5, a number block compression formats are also possible which don't even fall under moden BC*, including a DXT1 normal map compression. (Noesis supports these as well)
- Tiling/twiddling/etc. is of course lossless. If you think about the reason to use any form of micro/macro tiling mode, and what Morton coordinates give you, you can see that it's all about maximizing efficiency of the texture cache. It's just the same data, but sampling patterns are usually going to dictate that caching that texture block that lays out linearly in memory is going to be of much greater benefit than caching the rest of a linear-ordered row of pixels occupying the same memory.
- You need to be obeying expectations for implicit alignment between rows (or rows of blocks in the case of DXT), mipmaps, and cube faces as applicable. For example, a 30x30 DXT1 texture will contain block data for a 32x32 texture, as a single DXT block represents 4x4 texels. There are also different alignment/padding requirements depending on the format/tiling for mipmaps and cubemaps. Tiling may also dictate row alignment/padding beyond DXT block-alignment. If variable modes are employed then the correct header data for each texture no doubt specifies this.
Ok, have fun.
-
- VIP member
- Posts: 1330
- Joined: Wed Nov 05, 2008 12:16 pm
- Has thanked: 2710 times
- Been thanked: 884 times
Re: [X360] Star Wars Battlefront III pre-alpha (*.x2t)
Indeed!gistech wrote:Some interesting progress is going on here.
*i removed the attached file and turned off logPopup, see the first post for this Noesis python plugin*
Thanks to chrrox for the base code from fmt_star_wars_kinect_tga.py.
This script is titled for SWBF3 but it is mostly universal for swizzled 360 textures.
You have to open the script and set the format type, width and height.
i have not tested on a lot of textures, its pretty much trial and error but it should get the job done.
Last edited by Acewell on Thu Feb 11, 2016 2:16 pm, edited 2 times in total.
-
- mega-veteran
- Posts: 164
- Joined: Sun Aug 22, 2010 10:14 pm
- Has thanked: 40 times
- Been thanked: 11 times
Re: [X360] Star Wars Battlefront III pre-alpha (*.x2t)
Alright so most of the characters are what 1024x1024? but what are the faces 512x512?AceWell wrote:Indeed!gistech wrote:Some interesting progress is going on here.
Thanks to chrrox for the base code from fmt_star_wars_kinect_tga.py.
This script is titled for SWBF3 but it is mostly universal for swizzled 360 textures.
You have to open the script and set the length of data in bytes, format type, width and height.
i have not tested on a lot of textures, its pretty much trial and error but it should get the job done.
-
- VIP member
- Posts: 1330
- Joined: Wed Nov 05, 2008 12:16 pm
- Has thanked: 2710 times
- Been thanked: 884 times
Re: [X360] Star Wars Battlefront III pre-alpha (*.x2t)
I don't know you'll have to play around with the settings.
I forgot to turn off the logPopup in the script, you comment line 7 out with this # so it won't appear.
maybe someday we can hook the script into a tool window.
I forgot to turn off the logPopup in the script, you comment line 7 out with this # so it won't appear.
maybe someday we can hook the script into a tool window.
-
- mega-veteran
- Posts: 164
- Joined: Sun Aug 22, 2010 10:14 pm
- Has thanked: 40 times
- Been thanked: 11 times
Re: [X360] Star Wars Battlefront III pre-alpha (*.x2t)
So i'm finding a lot of textures that aren't working mainly if you go by name in Noesis and go down to 7efb9702.x2t that's where i started cause i was looking for the DC15 carbine first person texture and i found that.Wobble wrote:Here is the fixed Noesis plugin.
Thanks all!
From what i'm seeing all the texture that are after 6fd20406m.x2t to the end of 7ffad30at.x2t are broken and that's just what i've viewed so far, but some of them are so small it doesn't even matter but the ones that aren't are broken.
There are way more i'm seeing now.
-
- mega-veteran
- Posts: 164
- Joined: Sun Aug 22, 2010 10:14 pm
- Has thanked: 40 times
- Been thanked: 11 times
Re: [X360] Star Wars Battlefront III pre-alpha (*.x2t)
Wobble wrote:There are still textures with zero headers. Nothing is going to fix that.JakeGreen wrote: So i'm finding a lot of textures that aren't working mainly if you go by name in Noesis and go down to 7efb9702.x2t that's where i started cause i was looking for the DC15 carbine first person texture and i found that.
From what i'm seeing all the texture that are after 6fd20406m.x2t to the end of 7ffad30at.x2t are broken and that's just what i've viewed so far, but some of them are so small it doesn't even matter but the ones that aren't are broken.
There are way more i'm seeing now.
If you need to see a particular texture, then you need to guess its header.
For example, if you want to see the storm trooper texture posted above, add this to the filename:
Always use spaces to separate parameters.Code: Select all
7f40ed02.x2t -> 7f40ed02 1024 1024 32 5.x2t
Alright, well i've noticed some of the vehicle textures you can view them but they look like this.
They mostly look like they are complete just wrong format.
-
- mega-veteran
- Posts: 164
- Joined: Sun Aug 22, 2010 10:14 pm
- Has thanked: 40 times
- Been thanked: 11 times
Re: [X360] Star Wars Battlefront III pre-alpha (*.x2t)
Ah that works great i kept having problems with it even after i seen your updated post and i realized i had Acewell's plugin in there and once i removed it that did the trick.Wobble wrote:You got it right, just the wrong size. When you see a texture with "bands" like that, it means you need to increase the texture size by a power of 2. If you picked 512x512, go up to 1024x1024.JakeGreen wrote: They mostly look like they are complete just wrong format.
Try:Code: Select all
0350b882 2048 2048 32 5.x2t
-
- mega-veteran
- Posts: 164
- Joined: Sun Aug 22, 2010 10:14 pm
- Has thanked: 40 times
- Been thanked: 11 times
Re: [X360] Star Wars Battlefront III pre-alpha (*.x2t)
Well so far i've found textures that have been so messed up with pixels and used your method and it worked perfectly.Wobble wrote:If you want a texture loader that uses a "fixed" size, all the time, then using his Python script is a good idea.
You can scan for all 1024x1024 textures, and nothing else.