Jump to content

Search the Community

Showing results for tags 'pvrtc'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • HTML5 Game Coding
    • News
    • Game Showcase
    • Facebook Instant Games
    • Web Gaming Standards
    • Coding and Game Design
    • Paid Promotion (Buy Banner)
  • Frameworks
    • Pixi.js
    • Phaser 3
    • Phaser 2
    • Babylon.js
    • Panda 2
    • melonJS
    • Haxe JS
    • Kiwi.js
  • General
    • General Talk
    • GameMonetize
  • Business
    • Collaborations (un-paid)
    • Jobs (Hiring and Freelance)
    • Services Offered
    • Marketplace (Sell Apps, Websites, Games)

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Website URL


Twitter


Skype


Location


Interests

Found 2 results

  1. You may take advantage of graphic hardware supported textures on ANY chip architecture! Most of my effort went into adding formal documentation, so I will not repeat my self here. The page has not shown up yet. Will update with link when it does. Upshot is in order to take advantage of compressed textures, you have to know which compressed texture format(s) your gpu supports. If you pick one, all other hardware will not run your scene. Along the way of putting this in, a fall back was added for .DDS files with Direct X, dxt, textures, when not running on Windows browsers. This is much better than that though. For testing purposes, I made a version of the Mansion demo, where based on your hardware, a different compressed format is used. There is also a separate page where this was not enabled. I did not see any performance difference between these two on my hardware. Though the scene uses 105 textures, almost all are much smaller than 2k. Do to textures being multi-dimensional, space requirements explode as textures get bigger (up to 4k). A scene with a bunch of bigger textures would probably show much more of a difference. Enjoy. EDIT: Here is the url as viewed from Github (hope formatting will be same on BJS doc site) https://github.com/BabylonJS/Documentation/blob/master/content/tutorials/02_Mid_Level/Multi-Platform_Compressed_Textures.md
  2. I am probably talking to myself, but I have coded a solution for the 4 pvrtc texture formats inside a pvr container (file format). It is based on Brandon Jones work (as is the dxt / dds code already in BJS). When looking at the pvr file format spec, I noticed that there is a format element in the header (page 5) that has many more texture formats than just the 4. It includes pretty much everything even dxt & astc. Now, I think it would be a bad idea to use a pvr file container to hold dxt textures. It does seem possible to use a pvr container for any of the rest. Reason is that these WebGL texture extensions do not even know what a container file format is. You or your framework is responsible for the sucking of the faces (for cube textures) & mipmap levels out of the file. WebGL just has a compressedTexImage2D call where you pass it the data and a code for the format. I know astc has it's own file container format (in addition to dxt), but not sure about etc1/2 & atc. Anyone have a workflow for generating any of these texture formats, & know what container format is used? Used PVRTexToolGUI or PVRTexToolCLI, maybe? The intelligent texture selector is enabled by calling engine.setTextureFormatToUse() with the extensions of the formats you have to pick from on the server prior to loading any textures. /** * Set the compressed texture format to use, based on the formats you have, * the formats supported by the hardware / browser, and those currently implemented * in BJS. * * Note: The result of this call is not taken into account when texture is base64 or when * using a database / manifest. * * @param {Array<string>} formatsAvailable - Extension names including dot. Case * and order do not matter. * @returns The extension selected. */ public setTextureFormatToUse(formatsAvailable : Array<string>) : string { Since I do not have .astc exposed on any of my hardware (Apple A8's do support it though), I will table any decision whether to use it's container format or pvr. I am going to rework into a PVRContainer class and a PVRTCTools class that is a subclass. Separating will make things a little more modular. If I can come up with a way to figure out the how to detect the container type, even dxt could be separated from it's native container. The big plus would be you could use either the GUI or CLI tools above for all, I think. Would need help to do that though for dxt, @Deltakosh.
×
×
  • Create New...