XBMC Skin Editor new release!
if you didn't download the older version a link will be posted at xbox-scene soon.
enjoy and please give me feedback!
i believe i've mentioned this in the past, but unsure if it was to you.
as i've said earlier, i'm very excited about this - others have tried to do skinning apps before, and have fallen short due to the complexity of the system. this is the first time anyone has got even close and i am very impressed. it seemed to work quite nicely when i played with it.
obviously it will have flaws at the moment (it's beta afterall, and xbmc is always adding new stuff) - i'm more than happy to help fix them, whether it mean by adding to the code directly (i assume you are going to opensource eventually?) or by helping out with how the xbmc side of it works.
about the preview stuff: any window, in any resolution folder can be used in any other resolution in xbmc - xbmc scales the coordinates to suit. this is so that skinners don't need to reproduce every skin file for every resolution - they only need to generally do two: one for a 4x3 resolution, and one for a 16x9 resolution - everything else can usually be scaled from there.
the scaling code for the preview window is simple: you know the resolution that the .xml file is written in terms of (as you know which folder it has come from), and you know which resolution the preview window is in, so it's just a matter of applying the transformation before rendering. you should only need do this at two places, the image rendering code, and the text rendering code. everything else is just made up of images + text, so doing the transform at render time in those classes should take care of it.
cheers,
jonathan
overall, you've done a great job. let me know if i can be of any assistance - we have a sourceforge site setup already that can take the source if and when you wish to opensource.
i may be able to help out with the textures.xpr side of it as well - i'll take a look into it next time i'm in a coding mood and don't have the xbox handy. if we can get it loading textures from, and injecting textures into textures.xpr, then that will get over the main burden of entry. ideally, you should then just be able to load any skin, alter a couple of things, and save it straight out.
cheers,
jonathan
i am not a big skinner, i just know how to code and love xbmc and thought i would try to give something back for all the use i get out of xbmc. so instead of complaining about the lack of documentation and why is it so hard to do this, ect... i decided to create a program that would allow you to see real time what you are doing and be able to edit it. i know how much time was spent on xbmc i am just trying to give a little back :) it seemed like a good idea at the time, i didn't realize how much was involved with rendering a skin.
i did not set it up to scale it to a different resolution, it is set to simply show the boundaries of a pal screen and an ntsc screen. it is not set up to display a pal xml file in ntsc mode or the other way around. i figured you would either build a ntsc skin or a pal skin. if this is something that is needed to edit a skin than i will see what i can do.
as far as the file missing the first time, it is because the settings have not yet been set. it is basicly a warning that you need to set the directories up. the file is the strings file. this is loaded every time you start the app.
i have tryed to get the size down, i based this off vga resolutions. i can get the app less wide and a little less tall and hope to get it to 1024x768 in the full release.
i tried creating a program to read the images out of an xpr file but i read they are not in png format anymore and are converted to an xbox native image. if this is wrong and the images are just grouped into a single file and can just be read from the xpr file then i would have no problem writing a loader. the problem i was having was reading the header. the position of the files within the xpr file were not making sense, unless the encoder to make xpr uses alot of padding. that or there was an added byte i was reading. if i have some time i will build an xpr file with 2 small identical images to see the seperation and positioning.
just checked it out and the 2 png images i added were 3k each. after the program was done the xpr file was ony 2k so there is definately a form of compression.
i just dl'd the latest zip from http://www.jimk.xbox-scene.com/downloads.htm
i ran the exe and almost every time i click on the preview tab i get the exact same error (same addresses too) dialog box...
http://members.cox.net/affini/previewtab.jpg
i've tested my deswizzle code on square images from 32x32 up to 256x256 without issues. gonna check non-square images later tonight perhaps, then i'll look into the rest of the stuff (lzo decompression etc.)
hopefully i can get an opensource textures.xpr reader done up by the end of the weekend for 32bit images at least. animgif's etc. might be a little trickier.
cheers,
jonathan
in the new version there is no preview page, and editing page, they are combined and all the problems with the old gui are gone.
after all that i have to do it virtualy as i don't want to actualy create a image file, i just want to convert it and assign it to a tgraphic for display in the editor. that way skin designers don't have to worry about there images if they do anyway. i think most skins have the images as well or a place to download them. as is the reason this is not at the top of my list for things to do. so thats where i am at :)
1. a header describing the textures in the file.
2. the textures. these are in xbox native swizzled formats, and are then lzo compressed. they will be block aligned so that reading from harddisk is fast (512byte aligned i believe). once you read the data in, you need to decompress to get the swizzled texture, then deswizzle to get the original image as a 32bit plane.
i had a play last night, and reverse engineered the swizzling of 32bit textures for sizes 2^n by 2^n from 4x4 up to 32x32. i'm going to write a quick program up at some stage (tonight maybe?) to check that my procedure is correct, and then investigate what happens for 2^n times 2^m where n != m and for larger texture sizes.
once this is done, extraction from xpr should be reasonably easy to do. it'll have the added bonus that we can create an xpr file independent of the xdk, thus making xbmctex fully available to anyone to use (it's currently source code only).
cheers,
jonathan
dword magic code to indicate filetype (maybe xmct (xboxmediacentertexture)
dword width
dword height
dword texturedata
whatever is easiest for your application to read in.
i'm thinking a dll or lib with a single function at first:
bool loadtexture(const char *texturename, void **data);
is probably the easiest way to do it. that way, loading any skin will render correctly even if you only have textures.xpr - nice and user-friendly.
cheers,
jonathan
i could place a preview button for each resolution or 16:9 preview and it would just render the file, but the preview screen now allows you to drag items and scale items and each time you moved an item i would have to readjust the scaling based off selected resolution and the file it was loaded. to just scale when rendering would be no problem but editing at a scaled level would be decieving.
as far as using the program you may find the more you use it the more things will make sense. i spent some time writing the information for the website and it will help alot with using the program. once you see how everything works between the two pages(preview and editing) you will see how the program was intended to be used. the editing page is mainly for nongraphical settings. but for placement and width and height of items the preview page is best. i am sure you noticed that you can click and drag items to the position you want and scal them by clicking in the lower right hand corner. the green cube next to the yellow box that displays the selected control will turn lime green when you are ready to click and scale.
depending on the quality parameter, xbmctex can pack to the dxt* compressed texture formats, though this is generally discouraged - it gives a smaller filesize, but at a reasonably high quality sacrifice (particularly for transparent textures).
ideally, you want to work out how to unswizzle an image. it should be pretty easy to do this by passing in a couple of nicely defined bmp images and seeing how the swizzled file format goes - i'm not sure if the usual dx8 routines handle this or whether they're xdk-specific. i know that at least one of the routines used (either compression to the dxt* formats, or swizzling) is an xdk routine. it would be nice to have an open version of this if possible.
i can take a look at this if you like.
cheers,
jonathan
i'm happy to implement a simple check and get a new version of xbmctex out that supports a "don't allow extraction" flag if there is a demand for it by skinners. all previous xpr files will be unextractable if i do this though.
alternatively, i can output the files in a format readable by the skinning app, but not otherwise easily viewable. ofcourse, once it is shown on screen, it can be screendumped anyway.
for this reason, i'm not going to bother going to the effort of making it secure - as kraqh3d points out, you can get the textures if you really want them by using the xbmc source code and writing a bit of code to save them to disk.
if anything, i'll just add a simple flag that will require coding experience to circumvent.
all:
i can now extract all the 32bit and 8bit images from textures.xpr, uncompress and unswizzle them. next step is to extract the animated textures, and then the compressed textures (of which there is only 6 or so in cvs's textures.xpr.) i'm not yet sure whether i'll bother with the compressed textures though - will have to see how easy the formats are to decipher.
jimk72:
we should probably get in contact regarding to how best incorporate the textures.xpr file decoding into the skinning app. i can build it as a dll or whatever if you want - whatever is easiest for you to work with. please drop me an email (jcmarsha<.at.>fastmail.fm) if you wish to discuss this.
cheers,
jonathan
sorry, i have to chime in now... that's just silly. if the skinners dont want their images potentially stolen, then they shouldnt make a skin for an open source project. everything necessary to extract images out of an xpr is already freely available in our source code. you cannot stop it, not even with this silly protection mechanism.
first thing i notice is that it doesn't seem to be doing scaled rendering quite correctly - remember, xbmc has support for showing the pal files in ntsc modes etc.
the scaling occurs as follows:
1. the file location gives the coordinate system it is in (eg 720x576 if in the pal or pal16x9 screens)
2. we then scale all coordinates to the coordinate system that xbmc is running in (eg 720x480 for ntsc - thus, all vertical offsets should be scaled by 480/576)
other than that, looking good. a couple of exceptions when i went to the preview window with no file being loaded, and a complaint on first load that it couldn't find file "" being the only other minor issues i've found.
btw: do you think it's possible to make it a little smaller? 1024x768 screenmode makes things a little tricky - there seems to be a reasonable amount of room to squeeze things up a bit.
cheers,
jonathan
in the new version there is no preview page, and editing page, they are combined and all the problems with the old gui are gone.
yes, this was without a file loaded... i like hte fact you combined the edit & preview.
btw... my apologies if i missed it but are you going to be adding xpr support?
since most people use it; xpr support would be kick-azz
i think we should respect this, and:
1. make a new version of "xpr packer" with ability to choose "unpackable=no"
2. make any unpacker respect this
3. the above in a secure way that cant be circumvented with a simple recompile and 1 line codechange
#If you have any other info about this subject , Please add it free.# |