3.0.0 beta (ZGE on Android)

Post by **VilleK** » Fri Sep 14, 2012 11:34 am

Ah, forgot about error handling

Updated now.

Rado1 · Post by **Rado1** » Fri Sep 14, 2012 11:53 am

I tested the updated version, but has problems with loading png images. Try to load the attached 512x256 png image causing crashing of ZGE (sometimes also Windows explorer process crashes together with ZGE).

jph_wacheski · Post by **jph_wacheski** » Fri Sep 14, 2012 12:43 pm

just wondering if the specular lighting should be working?, as it currently does not seem to show up on Android.
Also, will the shaders be coming to the ES android version? Just curious, there is still so much that we can do with what is already in, that I can get lost in experiments,. just noticed these missing.

Check out this ES shader live coding site! http://glsl.heroku.com/

Post by **VilleK** » Fri Sep 14, 2012 1:20 pm

Strange, it seems like there are problems with images where width and height differs. If I resize your image to 256x256 or 512x512 it works. I've contacted BeRo about it but there could be a fault in my code as well.

There are limits about fixed pipeline light models in GL ES so it could be that the lights that ZGE are using won't work fully. The modern way is doing lighting yourself using shaders but imo that is much more difficult.

Shaders in ES requires OpenGL ES 2.0. And the problem with using that is that fixed function pipeline is gone (just like in GL 3 and higher) which means that lot of functionality ZGE relies on (like matrix operations) will need to be rewritten. So we will come to a point soon where we will need decide if we want to lose backward compatibility with older hardware (GL 2 or lower, GL ES 1.1) or try to support everything through a software layer. I think the GL standard community messed up when they removed older functionality, they could have kept it as a software emulated library at least.

Post by **VilleK** » Fri Sep 14, 2012 1:30 pm

Ok found the problem with PNGs and it was indeed a fault in my code

Fixed now, please try downloading again.

Post by **Kjell** » Fri Sep 14, 2012 2:14 pm

Hej Ville,

VilleK wrote:Shaders in ES requires OpenGL ES 2.0. And the problem with using that is that fixed function pipeline is gone (just like in GL 3 and higher) which means that lot of functionality ZGE relies on (like matrix operations) will need to be rewritten.

It's less work than it sounds actually .. part of the required matrix operations are even already in the ZGE codebase ( for mesh transformations ). Plus, a matrix ( 4x4 ) variable type would be so much more convenient then any array based workaround

VilleK wrote:So we will come to a point soon where we will need decide if we want to lose backward compatibility with older hardware (GL 2 or lower, GL ES 1.1) or try to support everything through a software layer.

I don't think you need to drop support for older versions. When a user decides to target 1.4 / ES 1.1, then Shaders simply won't work ( no point in trying to emulate that ). But for the majority of features, you're going to need this "software layer" for ES 2.0 support anyway.

VilleK wrote:I think the GL standard community messed up when they removed older functionality, they could have kept it as a software emulated library at least.

Agreed .. although the fixed-function pipeline is already outdated by today's standards, so I can understand why they chose to lift that "burden" from mobile driver creators of the future

K

Rado1 · Post by **Rado1** » Fri Sep 14, 2012 3:14 pm

VilleK wrote:Ok found the problem with PNGs and it was indeed a fault in my code
Fixed now, please try downloading again.

I tested it and it's working fine now. Thank you.

BTW why .zgeproj and .exe files are larger with new png compression than previous versions with uncompressed bitmaps loaded from png files?

Post by **Kjell** » Fri Sep 14, 2012 3:34 pm

Hi Rado1,

Rado1 wrote:BTW why .zgeproj and .exe files are larger with new png compression than previous versions with uncompressed bitmaps loaded from png files?

When you build a executable with UPX compression, in most cases BMP data will get smaller, while PNG might get slightly bigger. Similarly, all imported data in .zgeproj files is stored using zlib compression.

So, PNG is a good option when you don't want to / can't ( Android for example ) compress your executable, or when you have a image that compresses significantly better using PNG+UPX compared to BMP+UPX.

*UPX can also be kkrunchy or anything similar.

K

Post by **VilleK** » Fri Sep 14, 2012 8:47 pm

What Kjell said, it depends highly on the content. The png decoder adds 10kb to the engine. So if your png is smaller than that then the net effect will still be a larger exe. Also png is lossless compression (just like upx and zip already use) so it won't make much difference over bmp + upx/zip. The most difference will probably be if several large 8bpp png images are used instead of previous bmp that always was stored at 32bpp uncompressed. It won't benefit Android either because apk-files are zip-compressed.

Note that "remove code" feature removes png decoder when not used, so the minimum (empty project) upx compressed zge exe is still less than 30kb.

If you want your uncompressed exe-files smaller then use png compression. Otherwise load the images as bmp (or jpg if you don't have alpha and don't mind jpeg compression artifacts).

In summary: the png support is a test. If we don't think it gives enough benefit compared to the increased engine size we can drop it again.

jonaspm · Post by **jonaspm** » Sat Sep 15, 2012 12:24 am

nice update! i´ll test it and see how it works, nice job VilleK!

Post by **VilleK** » Mon Sep 17, 2012 7:15 am

To summarize the support for native png:
- it makes the runtime larger
- it makes zgeproj larger
- it makes compressed exe larger (zip, Upx and Android apk)
I find it hard to see any real benefits here. I'm considering removing it again unless someone can demonstrate a good case when it is useful? Using built-in decoders for file formats seems to only be beneficial when it is a case of lossy compression such as jpg.

jonaspm · Post by **jonaspm** » Mon Sep 17, 2012 7:43 am

So the older version of ZGE without native png doesnt support png images or what?

Post by **VilleK** » Mon Sep 17, 2012 8:48 am

jonaspm wrote:So the older version of ZGE without native png doesnt support png images or what?

Yes, it can still import png images but stores them internally in uncompressed format. This gives better overall compression if your exe-file is compressed with zip or exe-compressor. The issue here is whether the Zge runtime should contain a native png decoder or not.

Rado1 · Post by **Rado1** » Mon Sep 17, 2012 11:14 am

Ville, would it be possible to have a choice for storage png files either uncompressed or with png compression? Usually, I use lzma upx compression for exe and Android uses zip for apk, so uncompressed bitmaps in ZGE result in smaller executables. I will probably never (or very occasionally) use png compression.

Post by **VilleK** » Mon Sep 17, 2012 12:45 pm

For now you can just use 32-bit bmp instead and you should get the same size as before.