the latest ver is complete and availible along with a new website and instructions. just load up the version you have, go to the instructions page and click home and it will give you the information.
if you didn't download the older version a link will be posted at xbox-scene soon.
enjoy and please give me feedback!
great! will take a look.
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
yep that would be because i only did one partial skin and am learning as i go. lol
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.
excellent.
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
when you create a skin though you would create it in pal or ntsc, you wouldn't create a combination of the 2 in one file. so if you build a skin using the program and build it using the pal setting. you would not need to edit it on your pc in ntsc because xbmc will do the conversion for you. or if you are skinning for ntsc you wouldnt need to worry about pal adjustments as xbmc will convert it when rendering. the only real changes between the two would be the images you use. if you do not want your images to look stretched when rendered in a different resolution you would edit the image file not the skin. this would be the same for 4:3 and 16:9 exept with these the actual pixels don't change, only the aspect ratio.
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.
true - editting in a scaled mode isn't ideal - but then again, the actual image shown by the preview window is only going to be what you see in xbmc if it's an hdtv mode - all other modes don't have square pixels, so the aspect ratio will be wrong. anyway, it's something to think about for the future - skinners like to see as close as possible what things are going to look like, and if adding the transformation isn't too painful code-wise (it shouldn't be) then imo it'll be a useful addition. also, xbmc doesn't scale the fonts, so on different resolutions these can look different, due to both aspect ratio, and image resolution.
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
yea my tv is hd so when i was doing the previews they looked exactly like what the tv did.
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.
we rather not see a xpr extractor - until skinners have a choice to protect it.
i believe i've mentioned this in the past, but unsure if it was to you.
i agree. i just sucks that people don't read instructions. it is planely stated that my program will not load a xpr file and to enable the preview you have to download the source images for the skin you are editing. alot of skins have them with it or show a link in the readme and people just don't take the time to read. i have had so many emails and posts saying the program is no better than the first beta because it doesn't work. the images will not show up. every time i ask them if they have the source image they say no just the xpr file. lol i am glad i wasted all that time typing the information on my website.
does it do this even after you opened a file and selected a control, or only before? if only before than it has been fixed
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.
(jimk72 @ dec. 05 2005,16:58 Wrote:does it do this even after you opened a file and selected a control, or only before? if only before than it has been fixed
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 am looking into xpr support. i can now extract all images from an xpr file but they are still in d3d texture format. i found what i need in c++ to convert them back to the original image file, its just i have to do this using perl in delphi not c++ so i have to find a delphi wraper for the d3d dll that contains the code to convert it so i can call the code inside delphi using perl.
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
the key is getting the image unswizzled. once that is done, it's just a 32bit bmp for most images, so conversion from there should be straightforward. animated gifs are quite a bit different though (they're 8bit multiple images next to each other, with a set of palettes - i would leave these till last).
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 am leaning on not implementing xpr reading. there is parts i can not figure out. i can read the main header but the numbers don't seem to work out so there must be some padding going on. i also am having problems reading the header for the image. i guess that most of the new skins out there include the images or a link to download them so it is not a real big deal.
