Sorry your browser is not supported!

Hello AppGameKit fans,

nearly two years back, I ask about ASTC
https://forum.thegamecreators.com/thread/218221

The reasons are clear:
- memory save
- performance


So this video was published for optimising "apps" for the Oculus Quest.
I am working since 2016 on a project for the OUYA, and I made the same optimisations, if possible.


So it is nearly the same as for Low-end PCs or mobiles devices. Because you would need about 20 times the performance of a normal game. Why?
If my game could run on a Raspberry Pi or an OUYA with 1280 x 720 @30 fps and maybe some frame drops here and there with maybe only 20 FPS, it would be playable.
The Oculus Quest / Go has 1,600-by-1,440 pixel per eye. That is about 2.5 times the resolution, but because of the two eyes, that's 5 times the resolution.

The Oculus Quest has a 72 Hz refresh rate, Rift and Vive 90 Hz.

So if we would have 20 FPS on a Raspberry Pi and can play a game, we would need about 4 times the FPS for VR.

That means, 5 times the resolution, 4 times the refresh rate, so our game has to be 20 times faster for VR than it is on the OUYA / Raspberry Pi.

Okay. A PC and the Snapdragon 835 with Adreno 540 has about 567 gflops and the OUYA only about 12 gflops. The Raspberry Pi has a VideoCore4 graphics with about 24 gflops.

So, what I am trying to say is, if we could optimizes the performances on OUYA and Raspberry Pi to 20 ~ 30 FPS at 720p, that would be also great for VR.

Why texture compression? The OUYA supports DXT because of the Tegra 3. The Raspberry Pi ... puh, I don't know.
The NES / SNES classic mini are based on Mali-400 GPUs, they support OpenGL ES 2.0 and also ETC1 texture compression.

I understand the biggest problem with texture compression, and that there are a lot of formats out there.
The NES / SNES classic mini only have 256 MByte of RAM. The GPU and CPU are nearly as good as of an Raspberry Pi or an OUYA.
But with only 256 MB RAM it is very limited.

We at this moment only use 32 Bit RGBA pixels with AppGameKit. With ETC1 we could have 4 Bits per Pixel. It would be maybe not 1:8, but maybe 1:2.6 because of ETC1 has no support for alpha.

Maybe sometimes it would also help, to could store 24 Bit images in memory. Most of the textures have no ALPHA, but we use the memory.


e.g. the mali 400 and also the OUYA are able to understand 4k x 4k textures, with AppGameKit at the moment that are about 64 MB in memory.
The OUYA has about 1 GByte of RAM, the SNES / NES classic mini only 256.

So the OS needs some memory as well, maybe we have about 128 MB on a SNES / NES classic mini. That would be only 2 textures. All light baked in. No normal maps, no specular, etc. Only diffuse with shadows "_D2" in FPSC Classic terms.

With 24 Bit texture memory and not 32 Bit texture memory we could save about 25% in the most places. With grayscale textures (8 Bit monochrome), maybe we could save here and there also some, like with gras, stones, walls ...
And with compression we could maybe save up to 1:4, and could have not only 2 textures in memory, but 8.

Why would we need 8? We could stream textures. Have day/night cycles. Could change locations. Have open worlds with different environments.




What are you thinking about texture compression? One problem, I see is, that the compression-tools before maybe not open source. And we don't know the device the game/app should run on. But ASTC, DXT, ECT1 are standards. I know, Apple uses PVRTC or so and that is also a problem.

I also read, that S3TC Patent expired in Sept. 2017, and more linux drivers will support it. S3TC aka DXT. So all our FPSC Classic textures and so on could be used. And we also could have a legal compressor for that.

... [empty post]

Today I saw this posting
https://opensource.googleblog.com/2019/05/google-and-binomial-partner-to-open.html

https://github.com/BinomialLLC




What I wanted to see is an implementation in AppGameKit 2.0 / AppGameKit Studio, so we could benefit from texture compression also on older hardware. We could use the BASIS-tool to compress our PNGs and maybe we can have a new command like "SetTextureCompressionInMemoryActive(1)" or LoadBasis() instead of LoadImage ... or LoadImageWithTextureCompression ...

I am planing to have some 4K x 4K textures and every texture would be uncompressed at this moment about 64 MB in memory. for 10 textures that would be ~ 640 MB.
With BASIS this could be about only 80 MB.

6:1 to 8:1 compression and savings in memory.

AGK already supports Colour Compression... what it doesn't do is Automatically Convert Media.
So you HAVE to use an Application such-as Intel DDS Toolkit for Photoshop, Compressionator, etc.

Now as a keynote, what's important to keep in mind is that you're using a Compression Format that your Graphics Hardware Supports; otherwise while it might provide a smaller Storage / Memory Footprint initially; it will have to Decompress and be used as a 'RAW' Asset rather than as a Native Compressed Format.

Vulkan' BASIS isn't "New" but rather is an Intermediate (like SPIV-R) that is performed at Runtime with whatever the Optimal DCC is.
But keep in mind that ETC / DXT / NV1 / BC1 are all essentially the same Format... and not exactly great.
They're known as Lossy Compression Formats, and while you might not have noticed it with Albedo / Diffuse Images; I guarantee most have noticed it with "Blocky" Normal Maps that ruin the illusion of said Effect.

Modern Lossless formats such-as BC6H or BC7 not only retain a near 1:1 with the original image, but do so a smaller footprint and support for HDR (Tonemap Independence)
As noted provided you compress the format; AppGameKit Supports it and will use that., in-fact DCC is mostly independent of Engine Support itself; hence why for example Fallout 4 can be compressed from 50GB down to 18GB with an increase from 1024x1024 to 2048x2048 Textures; going from RAW TGA to DXT5-BC6H Format... which not only is a damn sight better on the Memory but actually showcased in some cases (like AMD GCN Hardware) upward of 35% Performance Uplift.
Purely because it's running everything natively, without any need to change anything about the Fallout 4 (Creation) Engine; which as noted doesn't technically "Support" Compressed Formats specifically; just whatever Direct3D / Graphics Drivers do.

@Raven

so you mean, I could use LoadImage() also with *.DDS files? e.g. OUYA supports DXT

So from what I understand, .basis and the ASTC-files would have to be more supported on the driver side of the computer system / GPU. And it would work in the "engine" with App Game Kit.

So from what I also read of yours, it could be possible, to "compress" the textures of Fallout 4 a lot more, if the textures would stay at 1024 x 1024 and maybe add some more lossy artefacts and or formats like ASTC. Didn't know, that Fallout 4 uses uncompressed textures. Thought DXT was standard since 2006 for the XBox 360.

Sorry, but you really are very incorrect. (Are you thinking of some other product altogether??? GameGuru or something else??). AppGameKit wont load formats other than these: PNG,JPG or BMP



Currently AppGameKit supports loading PNG and JPEG files only. DDS and all the other formats that you have stated will not be loaded by AppGameKit at all. Im not sure why you went to all the trouble of writing a long post on compression formats when you have clearly never loaded any of those into AGK.

While the file formats PNG and JPEG are compressed on disk, they are loaded in raw format 8bits per pixel and passed to open GL.



See the images section here: https://www.appgamekit.com/documentation/tips.html

Alternatively, take a look at the Teir 2 source code and you will see that when loaded into the openGL implementation the internal colour format used is GL_RGBA - a completely uncompressed RAW data format. Id suspect this is to ensure maximum compatibility across the MANY device types that AppGameKit has to support and the fact that OpenGL ES doesnt necessarily support automatic compression.
No internal (GPU based) compression is used or requested by AGK. If it was then the argument would be GL_COMPRESSED_RGBA or one of the MANY compressed formats. You also go on to tell us how Direct X and its drivers recompress images except that AppGameKit uses open GL. You can check the current consumption of memory due to images with a command

With the new Vulkan renderer it will be interesting to see if loading compressed images is added or not but its NOT in AppGameKit at the moment. It would be nice to add this and support more formats in a new release of studio so that the GPU memory usage is a bit more optimised.

@Raven

you need everytime an encoder. Don't matter if it is for BMP, JPEG, PNG or what ever. Photoshop or something like that. And to compress the data you need a good compressor. RIOT for PNG or TinyPNG
https://riot-optimizer.com/
https://tinypng.com/
https://www.fnordware.com/superpng/

It is the same with MP4 / H.264 / H.265 Encoders. And with Audio-files etc.

Mostly there are free and payed Encoders for every fileformat. Since App Game Kit is no Music program, there are no option to manipulate MIDI files or WAVE and MP3 within the editor. And it is also no image manipulation program like Photoshop. And also no video editor. No 3D model program and so on.
But we could program all of that with App Game Kit, because it is something like a compiler thingly.

What I am asking for is the support for .basis because that would be a "container"-format, an intermediate format, like the JAVA binaries, and the graphic drivers could transcode it into GPU memory. I understand, that it is one thing, to have memory blocks with pixels and another thing, to have texture file data.
I also understand, that the compression of a non compressed pixel image into a texture format for the GPU is not something that could be done in a few milliseconds. For JPEG and PNG encoders there are hardware support in some chips or the algorithms are fast and easy to understand for ARM and x86 CPUs in some kind.

I am not asking for an encoder. The .basis-Encoder is somehow free since Google made it Open Source. And also the "decoder" or "transcoder", which can do transcoding on the fly and that is the benefit! It does not depend on ETC1, ETC2, PVRTC, DXT, ASTC, what ever, if a GPU could understand e.g. only ETC1, the transcoder delivers ETC1 and saves maybe only some memory, but the app / game works fine.
And if an GPU supports DXT, the transcoder delivers that. So the developer of the game don't has to know, which GPU vender on which OS supports which texture format. Using .basis would work fine.

It would work on a Raspberry Pi and on a GTX 2080 Ti. Without GPU texture compression, the loading of uncompressed images would be longer and the hardware would need to have much more RAM. So if we trageting the Raspberry Pi 3 with it's 1 GB RAM for all or only 512 MB RAM in some cases, we can't have so much uncompressed data in the memory.

I see the benefit in App Game Kit that it can deliver a small footprint in App size and runs on low spec hardware. We are not talking about 50 GBytes of asset data. We are talking about some 100 MB asset data, but for Smartphones this could be a problem.

somehow loading a GIF with LoadImage() and make a Sprite out of that, doesn't result in more memory usage.

So that could be a compression that doesn't get the RGBA8888 uncompressed treatment, or! and I guess, that is more likely the case, it is not detected by the GetImageMemoryUsage() command the right way.

A compressed GIF that takes ~ 135 kByte would result in a

before, 0.371 MB (couldn't test it inside the program without // commenting it out)
after GIF loaded 0.487 MB

so maybe that are about the 135 kBytes. But the GIF is:
- animated with about 8 Frames
- second, if it would RGBA8888, it had to be about 135 x 188 Pixels by 32 Bit colors (4 Byte) ~ 0.097 MB

so it maybe that a GIF only uses the memory of one frame???

Maybe the image is to small to get an exact result


don't know, if I have done any test correct. Don't know why I made "before1#" 2 and 3 exactly. It is late