151

Re: OpenGL ES

parasti wrote:

[...] coin particles look super tiny at a high resolution. This is because OpenGL has an implementation-defined limit on maximum point size, and if I understand this correctly nothing can really be done about it, without possibly a more significant rewrite of the particle system.

I think this needs to be fixed, really. It's hard to accept a scene element that does not scale with the screen resolution. At 1024x768, the calculated point size is 96 and at 1280x1024 it's 128, while the actual limit on my system seems to be 63.

Using code adopted from sol_bill, I made a quick-and-dirty test and was able to achieve the desired particle look (size and rotation) by drawing them as billboards again. Not sure what the performance penalty is here, but given that goals and teleporters no longer contain any particles, their total number never exceeds 64.

152

Re: OpenGL ES

Yeah, I agree. We can probably have inexpensive point sprites on mobile devices and good-looking billboards on the desktop at the same time, no need to limit ourselves so severely just to cater to mobile performance.

153

Re: OpenGL ES

You guys are freakin' wonderful!

Neverball is set to be the next BSD, running on toasters and sh*t

lol

Currently Playing:
Celeste and Electronic Super Joy

154

Re: OpenGL ES

Elviz wrote:

[...] their total number never exceeds 64.

Just recalled (and checked) that the maximum for item particles was 256 in 1.5.4 and earlier. It must have been lowered for the GLES branch.

BTW, the current point sprites appear to have their vertical axis flipped: what's up on the original image is down on the screen and vice versa.

155 (edited by parasti 2011-11-26 13:34:58)

Re: OpenGL ES

You are correct on both accounts.

Particles underwent some hardcore optimization. If you consider that there are 4 vertices per billboard and 1 vertex per point sprite, the number of particles was actually reduced from 256 * 4 = 1024 to 64. These 64 points are drawn with a single draw call every frame while there were about 3 model-view transforms and a draw call per every visible billboard.

And the point sprites appear flipped because GL generates the texture coordinates against its own conventions: (0, 0) is at top left instead of bottom left, and (1, 1) is at bottom right instead of top right. This is documented in the point sprite specification (didn't see the rationale though), we're just not accounting for that.

156

Re: OpenGL ES

[Shadow disappearing under certain circumstances]

parasti wrote:

This is a direct consequence of doing the shadow in a single pass; there's no way to change this without either going back to multi pass or disabling the separate specular color effect.

Elviz wrote:

I could create a chrome-dull(-faceted) material for use with UFO, and something would probably have to be done about the white in snow.map (TdF II) which also has shadow trouble. There may be more cases, I haven't checked all levels. Sidestepping potential technical merits of the new mechanism, the workaround-free shadow we had previously seems more appealing.

I've read through this and related threads to find more information about the motivation behind the shadow rendering change. Apparently, what happened is that rlk had wanted to use multi-texture all along, and now that the required compatibility has improved, the ES renderer rewrite offered an opportunity to do so. And only after the above path had already been chosen, did the interference of specular effects pop up as an issue.

So, with the nifty new texture environment code in place, it appears that the changed shadow mechanism is here to stay. If that's the case, would you say that now is the time to work around the problems by adding materials and modifying maps as needed?

157

Re: OpenGL ES

As far as I'm concerned, it's just a small graphical quirk that few will notice. Desirable to fix, yes, but not important enough to work around it. Once we start using GLSL shaders, which will probably eventually happen, where we'll have more control over the lighting/shadowing than the fixed pipeline offers, the problem will resolve itself.

I won't be bothered if you'll still want to go ahead with any material/map workarounds.

158

Re: OpenGL ES

parasti wrote:

As far as I'm concerned, it's just a small graphical quirk that few will notice.

Well, it depends on what levels they play.
A player would have to be comatose not to notice the missing shadow in TdF II:

http://i40.tinypic.com/v6jhpj.png

159

Re: OpenGL ES

That doesn't contradict my statement. Instances where this happens are few and far apart, simply because in only a small number of levels does the ball ever need to traverse surfaces that shiny. The screenshot also fails to depict that it is the specular highlight overpowering the shadow, which happens only at certain tilt angles, and the shadow is just fine when the highlight isn't there or has less intensity.

160

Re: OpenGL ES

I think it's the snow-blindness setting in. :-)

161

Re: OpenGL ES

Whats the current performance for opengles like now?
I did a port of the opengles branch a while back for the pandora and anything beyond the first level was unplayable, but that was a while ago so maybe improvements have been made.

162

Re: OpenGL ES

parasti wrote:

Instances where this happens are few and far apart, simply because in only a small number of levels does the ball ever need to traverse surfaces that shiny.

And it is these instances that the aforementioned workarounds, if implemented, would be aimed at.

The screenshot also fails to depict that it is the specular highlight overpowering the shadow, which happens only at certain tilt angles, and the shadow is just fine when the highlight isn't there or has less intensity.

By nature, a screenshot intended to demonstrate a problem depicts the problem case and not any non-problem cases. Of course the specular highlight is overpowering the shadow. That's the issue.

163

Re: OpenGL ES

Why the tone? I stated my opinion and elaborated on it further. I also said I don't care what you do with it.

164

Re: OpenGL ES

Pickle wrote:

Whats the current performance for opengles like now?
I did a port of the opengles branch a while back for the pandora and anything beyond the first level was unplayable, but that was a while ago so maybe improvements have been made.

No performance improvements have been made.

165

Re: OpenGL ES

@Pickle -> Wasn't the Pandora released with 1.0GHz CPU? The Pandora is way more powerful than the GP2X WiZ, and Quake 1 positively flies on the WiZ. I guess you have a larger screen to deal with, but it should still be a very playable ~30fps+ on the Pandora (unless using software OpenGL, and not GLES), in which case, it would be ~5 fps.

Currently Playing:
Celeste and Electronic Super Joy

166

Re: OpenGL ES

No the standard speed is 600 Mhz, some units have been able to reach 1 Ghz by overclocking and also increasing the OPP voltage setting.
But the CPU isnt the bottleneck its the GPU. First level was 20+ fps, but past that it was < 10 fps.

167

Re: OpenGL ES

How can you be so sure that GPU is the bottleneck? A low FPS can be an indication of either one. The Maemo port has a similar performance issue. Last I spoke with the guy working on it, we established that doing fewer physics updates per second results in a noticeable FPS boost. So in that case, it is definitely CPU.

168

Re: OpenGL ES

Sorry Pickle, I heard that slow takeup, and advancement in chip design (with many smartphones now having DUAL CORE 1GHz processors) made OpenPandora put a 1GHz CPU in it to sweeten the deal (or at least for new purchasers, not pre-orders).

Pandora have been very unkind to people who pre-ordered, delivering freshly built machines to those who paid the most cash more recently. VERY UNKIND INDEED!!!

Currently Playing:
Celeste and Electronic Super Joy

169

Re: OpenGL ES

parasti: it has been a while since I ran it, but im pretty sure i tried running with an overclock and didnt see a performance change. I assumed at that point it was a GPU bottleneck, but it could be CPU if it was so slow the overclock didnt make a dent. If indeed these changes improve performance it would be nice if they made it into the branch so others like me can test them.

themacmeister: no, all the cpus were already purchased for the first batch, so those parts will have to be used. One of developers mentioned looking into a better cpu, but the person that does the hw design quickly shot that down. I think at one time there was talk about selling units that were tested for a 1 Ghz overclock, but that never became official.
There have been a couple of upgrades that have occurred, at the very beginning the nand size was changed. Most recently the soc memory size was increased to 512 mb (from 256 mb, since 256 mb are no longer sold).

Yeah the premium upgrade was indeed a very controversial move, but it was mainly because the cost to make the pandora was wrong.  Also the factory populating and producing the boards, pretty much stopped making them.
Production is now being handled by someone else and with a local (and reliable) manufacturer.  Funding to support both a new run of boards plus covering previous orders is provided by investors (not preorderers). New pandora are expected in Feb. and with the positive news of progress so far it appears it might actually happen. It seems it sure would have been better if the production had been managed in this way from the start, although with all the crazy things that have happened, who knows what difference it would have made.

170

Re: OpenGL ES

Pickle wrote:

parasti: it has been a while since I ran it, but im pretty sure i tried running with an overclock and didnt see a performance change. I assumed at that point it was a GPU bottleneck, but it could be CPU if it was so slow the overclock didnt make a dent. If indeed these changes improve performance it would be nice if they made it into the branch so others like me can test them.

There are no "changes" to speak of, it was just a test to confirm that CPU is the culprit. BTW, OpenGL ES port has been merged to trunk for some time now, I don't recommend using the gles branch still.

171 (edited by Elviz 2013-04-16 22:58:09)

Re: OpenGL ES

Elviz wrote:

Goal height is 3.0, or 192 units in Radiant. The goal effects shouldn't exceed this height, yet the new ones do. This means that they pierce through geometry built specifically to accommodate the above height.

What I did in Nuncabola to fix this was to add a glScalef(1.0f, 0.75f, 1.0f); call after drawing the beam but before drawing the effects. This way it's the inner rays instead of the outer ones that reach the goal height.

Affected levels are Hard 18, IV; Nevermania 08, 09, 18; Dave's Levels 03.

Edit: ...and Nevermania 19.
Edit^2: Nevermania 20, too.