Whos converted to PVR?

#1 This is the theoretical part, without taking iTGB behavior and potential issies into consideration.


PVR is 1/8 to 1/16 of a BMP and remains like that in VRAM unlike PNG / JPG which will be bmp size.

it will save memory but much more important: it will considerably raise the performance as the bandwidth requirements drop to 13% / 6% for the same texture.

#2 Thanks for the reply Marc. Sounds good in theory :)

Ive just tried creating a square, power of 2 test image with no transparency and it looks pretty good, just images with transparency look messed up.

After a quick look it sounds like PVR does support transparency so im off to do some more digging.

#3 With transparency, ensure that you don't use one of the 2bpp formats, as that might be a bit problematic

also if you export from photoshop -> png, check out superpng
photoshop has a pretty crappy track when it comes to export alphaed pngs

#4 Thanks for the tip, I am specifying 4bpp as it happens so shouldnt be that.

My in game images are exported from Photoshop but the test ones ive created are done with Seashore on the mac. Any idea if that has issues with alpha? The corresponding PNG's alpha looks fine in the editor.

#5 Not had any luck with this yet, any transparent area of an image shows as black on the device.

Ive tried generating the preview PNG when creating the PVR and that displays the alpha correctly..

Any ideas?

#6 No idea, sorry :(

#7 Still had no joy, has anyone managed to get alpha to display correctly when using PVR's?

Been looking at this with Dave who is having the same issue, ive tried several different source images, made with different apps,the only difference I see is the colour that replaces the alpha sometimes changes (I think between us weve seen black, white and green depending on the source).

Ive just tried using a tga as the input for texturetool too, same thing happens.

It doesnt look to be the device as the same problem is seen in the simulator..

#8 Are you using the original tool (ie the one that comes with the iPhone SDK install)?

Because I thought it only accepts 32bit png unless I missed something.

#9 Yeah thats right the that comes with the SDK, I saw mention of using tga's somewhere so gave it a try.

It seemed to like it and the generated PVR appeared in game, although still without transparency..

#10 Ok, we solved this one - thanks to Matt Mittman for pointing me in the right direction.

The version of texturetool that comes installed at /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin was the wrong version of the utility. Instead, we needed a version (PVRTexTool) that can be found at http://www.imgtec.com/powervr/insider/powervr-pvrtextool.asp (Windows only, no Mac).

However, now I am having some trouble with cell-based image maps (for sprite animations). The tool compresses the file just fine, and I can see the whole image correctly if i add it as a static sprite on a level. If I attempt to reference a single frame within the image or if I create an animated sprite from the image map all I get is black frames.

#11 Well by definition that means that you are now using the wrong tool and that iTGB is using the data basing on the wrong tool.

Because the one and only right tool is the one that comes with the iPhone SDK (I assume you are on iphone sdk for 2.2.1, which is different than the 2.1 and 2.2 sdk), at least if you are interested in developing for the iphone

if its required to use the wrong one, then thats a major bug that must be adressed asap

#12 You beat me to it Dave ;)

It might be a bug then Marc, I think both me and Dave spent a couple of days trying to get texturetool to work, as soon as we switched to PVRTexTool it worked first time..

Theres even a photoshop plugin at the link Dave posted, that works too, which is nice.

#13 yea i think it has something to do with the apple texturetool being quite crap. It doesnt generate mip maps either? i didnt check into the 2.2 sdk but the one before was terrible. plus it didnt generate the binary headers that torque needed. we got weird upside down textures and all sorts. (it notes this in the text file that comes with the engine)

Also, the pvrTexTool is made of awesome. Use that instead

#14 I believe the older version of apple's texturetool didn't create mipmaps or have the header, but the current version does. It just didn't handle the alpha channel correctly for some reason when we tried the PVR in TGB.

And I'm still stuck on the animations even now. I haven't had a chance to look into the engine itself to see if there's some issue there or if it's some other problem.

#15 Sven: Well then iTGB is broken. If iTGB requires stuff that is not part of the official iPhone SDK, then its definitely a bug in iTGB.
Its hardly Apples fault if GG decides to not follow even the basic behaviors for Apples platform.

I've to say that this shocks me seriously because it shows a very fundamental and indepth problem that has already shown up a few times in the past when it came to just compile or the correctness of the Mac builds for TGBGame and TGB Editor in comparision to the Windows Builds.

This definitely shows that GG is NOT USING MACS AS PRIMARY PLATFORM TO DEVELOP ITORQUE
That somehow also lines up fine with my experience so far that iTGB works more like a TGB -> iPhone deployment path than a real iPhone development technology. Given that iTGB is not sold as an Addon to TGB (as addons hardly cost twice the cost of their technology), this is at least to me pretty problematic.
I don't intend nor do I want to touch TGB to work with iTGB.


The iPhone and iPhone SDK are Mac only technology, so you either work on Mac or you don't work on the iPhone, that simple it is.
Working on Mac as primary Platform for iPhone is NOT optional, its a must.
Windows is the optional supported platform here and when I see this kind of problems, I can only re-request: Stop supporting iTorque for non mac platforms for the time beeing. Focus on getting it working on Mac and the iPhone perfectly first, then think about supporting platforms that can and never will be able to deploy AppStore applications!


So could a developer please confirm this?
Please tell me that this is a joke, that this is just a strange incident that the windows tool works where the official (the one and only you should use if you work on the iphone!) SDK tools fail.

I expect this and all similar to be fixed in the forseable future (< 3 months), especially that the compiling and using iTGB only on Mac (the primary platform!) is finally taken serious and that the toolchain is brought up to the point to work nicely there.
No wonder did no developer so far understand the importance of an integrated build path in the editor including the capability to compile to PVR in a "Build iPhone" Step basing on specific settings on the images.


I will retest all the current OSX only problems (build not working, Apples PVR not accepted, ...) I know of with the next release of iTGB and expect to be able to mark all as cleared as iTGB is now out for over 6 months.

#16 The Windows one has a lot more options, and has the easier-to-use GUI interface, but if you want to use the Mac command line tool try this:


texturetool -e PVRTC -o -f PVR

e.g.
texturetool -m -ePVRTC --bits-per-pixel-2 -o outputfile.pvr -fPVR inputfile.png

#17 I'm aware how the tool works, thats not the point. Apple has documented its usage in the SDK documentations.


The point is that it might be that the Windows tool has more options.
But iPhone development is a Mac thing and always will be one, not a Windows thing, so the primary focus for the official development (what the devs do privately is their thing :) ) should be on using the official SDK and how to use it to get the best possible results and a usable workflow.
The "this is not our problem, we just use something not officially supported to save time" attitude definitely doesn't help making iCrash more stable or work better on OSX.

The target should not be how to save time by using non official stuff and risking that the technology does not run correctly due to focus on a development platform that does not even support iPhone development at all, as it is the case with iTGB 1.1

First comes Mac and once it runs there perfectly, then comes Windows, when the development target is the iPhone, not vice versa as it is the case with iTGB 1.1

Quote:I believe the older version of apple's texturetool didn't create mipmaps or have the header, but the current version does. It just didn't handle the alpha channel correctly for some reason when we tried the PVR in TGB.

This for example shows why focusing on tools for the very wrong platform is a serious problem because not all intend to develop for iphone 2.2.1 and therefor never might have downloaded the 2.2+ SDKs and instead use the 2.1 one and can not use pvr then.
I can link in the various "does not build on Mac", "play button does not do anything on OSX" threads as well.
iTGB 1.1 is a lot but still no iPhone technology as it does not work out of the box on osx, in case of the play button it does not work at all.

Can the user fix such stuff: yes
Should the user need to do so: No, definitely not at $500 for a TGB Pro source addition that does not take the platform specifics seriously into account yet.

#18 Hi Marc,

I dont understand your logic, sadly.

The iphone supports PVRTC textures, FULLY. does this mean that iTGE/iTGE should have only supported the format to the extent of apples crap version of texturetool? I hear its been improved with 2.2 (oh only a good number of months too late) but thats not the point.

If you car is made by apple, and they only release fuel but no wheels, and you can get wheels from another dealer, do you just drive without wheels or do you go for something functional. I dont understand how preaching the toolchain makes any difference the requirements for delivery. I agree on your view that the platform should be fully tested and used rather then a secondary platform but the tool argument is irrelevant in my view.

The engine supports PVRTC texture capabilities, the fact that apples tools DIDNT according to the specification - is no bug in iTGE/iTGB. its called foresight, and when one day apple spruce up their tool the engine will have been ready long before this, so that people wouldnt complain about non existant "bugs" which have nothing to do with anything.

I love the PVRTexTool command line tool cos it WORKS. i dont care which platform it forced me to used, i care about finishing the product in a decent time, not waiting for apple to catch up to their own implemented technology :)

Im not being harsh, just pointing out that i dont get the argument regarding the texture format.

#19 It is very well a bug.
Because the primary platform iTGB must comply to is Mac and Apple iPhone SDK

Not windows, simply because you can not develop an iphone game with windows, you must have a mac.
Perhaps its not obvious, but there are really people who do not have Windows and all those are/were incapable to use it because the developer of this "iPhone technology" used stuff from specifications different to Apple's
I don't care what the windows tool does or does not. What is important is what the tools in the Apple SDK do, as they are the official ones.

I do not have problems if it works additionally with other tools than that. But first it must work with that, and currently there are problems on that end so I have about 0.00000000% understanding for any recommendation or "thats better" as long as the stuff that MUST work just has some pretty annoying problems.

1. Does iTGB build on mac at all -> no not without you fixing the broken distribution
2. Does the editor work as it should on Mac -> no as well, play is disfunctional
3. Does PVR work: with the current version of the SDK now perhaps, but not before, because the support was implemented basing on specifications that differ from what Apple offered / offers.
This all would be far less of a problem if GG just had implemented the PVR compression with the editor itself as it is to be expected (after all S3TC compression is integrated as well), because then it would be unimportant as it would just work for iTGB. But as they decided not to invest the time to integrate it properly (reminds me of TGEA + DDS, pretty much a similar story as it was just hack-plemented, not implemented), it is a must that first apple works and then the rest.

I'm not interested in developing a windows game with iTGB. Thats the purpose of TGB Pro.
iTGBs one and sole purpose is developing an iPhone game and as such it has to follow apples standards with later options to support non standard stuff.

I've no interest to see another mess like TGBs genius trash-dx support (DX was once advertised as a feature) and the broken dynamic unload unfeature.

Thats what I mean with "take iTGB and its target platform finally seriously", that the primary focus must (not should or can) be to get iTGB working at least 95% perfect on OSX and once all is fine and working there, expansion to an unsupported platform (Windows which never will be able to create iphone apps) can be considered. Not the way its now, focus on windows and deliver stuff that does not work on OSX.

As mentioned, I'll be waiting for the next release and check all the stuff on my list again and react depending on that.

I don't see a point in discussing such things with you, you do not seem to understand the importance that the tools for the target platform are top priority to be used, then the rest in this case.

Develop for the X360 with TorqueX if you just want to develop for something else than a PC and want to remain on Windows, as thats where Windows is the native platform.
But please don't assume and especially dont imply / recommend to others that it is an anywhere smart move to develop an iphone game on Windows, because it definitely is not, especially not as long as the stability of iTGB is higher on Windows than on OSX & iPhone.


And just to mention that: i've both, a mac and a pc. My PC is actually a Core i7 920, 6GB RAM, GTX280 with a 8800GTS as PhysX processor and 4x 500GB in RAID5, so its not like my mac is stronger.
But its a core requirement that you can test the stuff on the simulator because testing in TGBGame is as usefull as watching your defrag program all day as it moves colored blocks. It gives you a basic idea of what is going on but neither does it give you any directly usable data on performance nor does it grant that it will work at all.

#20 Let's keep on topic here.

The confusing part for me is that the tool for creating the textures was only in the Windows distribution of iTGB. I understand this in theory - the tool is a Windows executable. However, I am working on a Mac and didn't bother to look at the Windows distribution at all.

I'm not sure what's planned for the next iTGB release, but if possible it'd be good to make all this a little clearer to everyone. And for all I know it is mentioned somewhere in the docs and I just missed it, but it would have been really obvious to me if I'd seen that PVRTC directory in the Mac install, even with a Windows executable.