3.0.0 beta (ZGE on Android)
Moderator: Moderators
- jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
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/
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/
iterationGAMES.com
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.
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.
Hej Ville,
K
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 workaroundVilleK 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.
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: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.
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 futureVilleK 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.
K
I tested it and it's working fine now. Thank you.VilleK wrote:Ok found the problem with PNGs and it was indeed a fault in my code
Fixed now, please try downloading again.
BTW why .zgeproj and .exe files are larger with new png compression than previous versions with uncompressed bitmaps loaded from png files?
Hi Rado1,
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
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.Rado1 wrote:BTW why .zgeproj and .exe files are larger with new png compression than previous versions with uncompressed bitmaps loaded from png files?
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
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.
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.
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.
- 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.
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.jonaspm wrote:So the older version of ZGE without native png doesnt support png images or what?
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.