@Georg
Quote:
LOL

@kas1e
Quote:
Great! But why "damn"?

Quote:
Aha!

Quote:
Maybe neverXXXX uses display-lists which probably results in a less inefficient render-path inside gl4es (or maybe he even uses VBOs then?).
Did it also fix Q3?

Quote:
I don't think this is wise. The stack-allocated index array shouldn't be an issue by itself (unless the stack is too small of course, but I suppose we can rule that out) and it's much faster than the fastest malloc.
This is the typical "a crash symptom appeared at XYZ, so let's change XYZ"-tactic he should definitely avoid!
So unless he found a true bug there, he should better revert it.

@kas1e
Yes, that would be it.

@kas1e
It doesn't *have* to be 0xFFFF on your side, that is (among many other nonsense values) just part of the invalid (random) indices on *my* side, your array may contain other random stuff.
As I said, the last ~ 20% of the array look plausible here, so for me at first glance it looks as if I'd get something like &indices[-4000].
Then again, those valid looking indices are rather high, so it actually looks more as if those 80% before that data are overwritten with crap.

Anyway, please do the following:
please upload a version to my ftp which spits out the count / pointer etc. at your glDrawElements like you did above and then simply also print out the, let's say, first 100 ushort indices, comma seperated.

@kas1e
Regarding neverball:

I checked the index array at the time of the crash. It contains about let's say 80% garbage (tons 0,0,X "triangles", lots of 0xFFFF indices; well it looks like semi-randomly trashed memory), the last maybe 20% look like somewhat valid indices inside the expected range.

Btw.: there are two glDrawElement calls before the one that crashs, those looks absolutely sane (reasonable indices etc.) and they work flawlessly.

Until the point of the crash the whole lib seems to work correctly, no sign of any lib or other coruption (and quite a lot happens under the hood until then), but then it's fed with this invalid index array and says good bye.

Of course I cannot say who's the one who *really* corupts it in the first place (because its coruption can also be a side-effect of something else).
But I can say that it is already corupt *before* ogles2 does any work inside glDrawElements, it is being sent in a corupted state to ogles2.

@broadblues
I think this little (in this case even uncritical) issue already has been covered in great depth when I said "Nice great stupidity by me indeed" and "I just fixed it for the next lib release."

@kas1e
Performance is a desaster, it has extreme hickups, but well, -O0 and your hack's temporary array alloc/free may easily be the explanation for this.
Q3 looks good that way here too (those other issues like wireframe-effect and depth-buffer-sky-issues aside), so at least here we seem to have more or less matching results

@kas1e
Oh, I *have* a bug. I only have to start that Q3 build. The thing is simply that by "luck" Cadog shows no symptoms here.
Btw.: please also upload the Q3-hack-version which shows no symptoms on your side.

@kas1e
okay, if it's still there then revert your system and forget about the RadeonHD.chip idea.

@kas1e
Quote:
Just like on my sam460ex I have exactly zero issues with any cadog build version. No distortions at all. The only true difference on our both systems is the RadeonHD.chip driver version (well, and the concrete gfx-card), IIRC. Mine is 1.17. Maybe we should try what happens if we temporarily exchange yours by mine.

EDIT:
For whatever reason the compiler apparently gets confused by the "inline" of rlVertexCommon.
Looks like with -O0 it doesn't inline it but creates a function call to it inside rlVertex4f etc., however it doesn't create this function which makes the linking fail.
Maybe you can make it link by adding a static in front of the inline. Or temporarily remove the inline hint.
What compiler (version) are you using?

@kas1e
That's what I meant, no background or whatsoever distortions at all here with cadog (only checked sam460 so far, will check x5000 later too).
Yes, doesn't come as a surprise to me neither
Go on, upload what you got, the more the merrier

@kas1e
It's simply not the culprit, just like every 2nd adjustment here and there it may simply change the symptoms somewhat. That's the way it is when there's some undefined stuff happening somewhere.

Quote:
Thanks, no need to, first version is enough, as being said: whether you use old aglCreateContextTags with the non-conforming tag-IDs or aglCreateContextTags2 with the new ones makes no difference for what's happening under the hood and it's not the source of the problems.

EDIT: both your builds (as the ones before) produce correct looking results here, no menu distortion at all.

@kas1e
Quote:
It won't behave differently (well, if it does then it's just a sideeffect of sth. else) and it is certainly not the cause for any of our issues here.
As being said: while Georg was of course absolutely right by pointing out the tags-wrong-IDs-bug in ogles2, there is nothing more there. And unless you used TAG_SKIP or other special tags (which AFAIK you did not), it simply did what you expected it to do. Other than this now fixed incompatibility to std. tags-processing, there is / was nothing wrong here.
Don't forget to read the changelog.

@Georg
Quote:
Nice great stupidity by me indeed
But yes, I do parse those manually so as long as you only use the tags that are defined by ogles2.lib everything is good (and if you don't "comply" here then the context will not be created as you configured it (or maybe in worst case simply crash there), no matter if you use the vararg or the struct-ptr variant, which internally boil down to execute the same code). I just fixed it for the next lib release. Thanks for noting!

@kas1e
Please upload your minimal test examples (like Cadog stripped down) to my FTP. The less complex a test prog is the better.
Also note that the beforementioned fixed ogles2.lib 1.20 wip-version (also containing some other new features) is on the FTP too.

@K-L
@mufa
The game vsyncs in fullscreen-mode.
However the very first release version was broken on AOS4 in this regards. If you didn't online-update then go and redownload the archive, please.
Then make sure to set the triplebuffer tooltype = 0 on your fast machines. The tooltype's name is a bit misleading, it will essentially cause the game to sleep when waiting for vsync.
If you still got issues then, see below

@Thematic
Thank you

@K-L
From the readme
Quote:
Please, I really want to have that stuff in the mailbox, nicely collected to be easily processable, not cluttered around everywhere. You may of course discuss your problems as you wish and where you wish, but don't expect me to handle those then.

Anyway, regarding ESC: if you're playing with joypad, keys won't be checked (for whatever reason that's how the game is designed, unfortunately). Maybe that's your problem. You have to enter the pause-menu with your joypad buttons. And cross fingers that your gamepad has enough buttons.
Emergency: a good old CTRL+C will quit to Workbench ;)

@DStatny
It's no fraud, after all they can ask for as much money as they want and they don't say that it's being splitted or whatever.
It's just that, thanks to the wording of their texts, you may probably believe that you support me / Amiga ports by paying more or that they were of help with the ports, which is both not the case. That's what ddni wanted to point out (thanks!).

The thing is actually pretty simple:
- Who will benefit from sales, no matter how many / how much you pay? Answer: Pixwerk.
- Did Pixwerk help with the Amiga ports / partial rewrite necessary? Answer: Not at all (actually the PC version benefits from my first fixes / optimizations).
- Where to donate if you like the Amiga ports and desperately want to give away some money? Answer: goldencode.de

So, if you want to give them extra support, pay more when buying the game.
If you want to support me, go to my homepage.

@all
Glad that it apparently works fine on most systems!
And many thanks to those who donated (no matter if it reached me, it's the thought that counts in those cases)
And remember to follow the short instructions in the readme in case you run into trouble!

Oh, and in case somebody didn't read all update-mails on the game or forgot it:
network support had to be dropped because at some point they suddenly switched to a commerical black-box-network solution, so the online-gaming-menu will remain greyed out forever (however, it would have been another bonus anyway, since it was not on the table at all when I agreed to do the ports). I once asked for fresh menu-item graphics, but nothing came, so I simply greyed it out because the menu-item-numbers are inside the same graphics...
Anyway, the Amiga-port's download information clearly says "local multiplayer" too, so it shouldn't come as a surprise to anybody.

Cheers,
Daniel

@ferrels
Yes, I know that kas1e is very excited, which is good of course. And he's of great help. After all it's thanks to his efforts with first Regal and now gl4es that ogles2.lib and Nova are being tested in real-life rather intensenly now and already got some nice improvements / fixes in short time.

@kas1e
Sometimes I just have the feeling that you need to be grounded a bit
Step by step. We'll for sure find and fix that and any upcoming issues. Sometimes it simply takes more than a couple of hours

@kas1e
Just like the other ~100, I have received your mail, but since I covered pretty much everything in my previous mails answers and because I had other stuff to do, I didn't answer that one yet
I said before "the more the merrier", so no need to ask me, just upload your test builds on my FTP (btw. I never received your hacked q3), but:

Quote:
I already told you and will repeat it again once more:
This is definitely not the issue!
As being said I had already checked this out in depth before you did (simply because it was the very obvious difference in the other render path) and found it to be all good.

Quote:
Let me repeat this one too:

"Don't draw false conclusions only because your hack seems to work around the problem. ...
The fact that some changes change that undefined behaviour doesn't conclude that those changes point directly at the true culprit, unfortunately."

The problem simply is not what you and the gl4es guy think it is. You are only changing the symptoms with your hacks.
Therefore, again a repetition: better revert that hack again, it was interesting but it turned out to not be the problem, so the only effect it has now is that it complicates things because it tends to "hide" the still existing real issue.

As with that ql4es build of that letter-game (which is broken for you but not for me) we simply got (semi)random / undefined behaviour here, caused by something else somewhere, but definitely not caused neither by glDrawElements nor the vertex-attribute's type / normalization.
Just let it go, man!

The root of the problem is somewhere else, earlier. It's most likely some memory coruption somewhere, where it is is still unknown, it can be in gl4es, it can be in ogles2, it can be in Nova (neither one can be ruled out yet).

As I told you I am investigating to make sure that it gets fixed - if it is an ogles2 issue. So far my investigations did not reveal a problem in ogles2, that's the current status. This does not mean that there is no problem in ogles2. It only means that I didn't find one yet. But I can say for sure that it is not directly related the vertex attributes being of type uint8 or normalized.

And also let me repeat something somebody else told you already: being pushy won't help

@Hans
I investigated. To make a long story short:

For whatever reason unknown to me it's an artefact by the mipmap filter, obviously only happening if Q3 renders its mirrors; the same geometry with the same texture parameters is rendered correctly if not going through the mirror.
If forcing the game to W3DN_LINEAR instead of a mipmap-filter, then the artefacts vanish.

I don't know how Q3 does its mirrors, apparently its neither render-to-texture nor via stencil, so it's probably done with some funny depth-buffer setup and / or via clip-planes (that latter would have to be implemented in some fancy gl4es shader), others will know better.

@kas1e

Quote:

Apparently you don't understand what those extensions actually mean. And that there's a reason why ogles2 doesn't report so many. Let me clear things up a bit:


Those are MiniGL's 22 possible extensions:

GL_MGL_packed_pixels
GL_EXT_packed_pixels
GL_EXT_bgra
GL_EXT_color_table
GL_EXT_vertex_array
GL_NV_texgen_reflection
GL_ARB_vertex_array_bgra
GL_ARB_multitexture
GL_EXT_compiled_vertex_arrays
GL_EXT_draw_range_elements
GL_EXT_texture_filter_anisotropic
GL_ARB_texture_env_combine
GL_EXT_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_EXT_texture_env_dot3
GL_ARB_texture_env_add
GL_EXT_texture_env_add
GL_ARB_vertex_buffer_object
GL_ARB_texture_compression
GL_EXT_texture_compression_s3tc
GL_S3_s3tc

Let's first remove the redundant ones which mean exactly the same, which means there are actually only 17:

GL_EXT_packed_pixels
GL_EXT_bgra
GL_EXT_color_table
GL_EXT_vertex_array
GL_NV_texgen_reflection
GL_ARB_vertex_array_bgra
GL_ARB_multitexture
GL_EXT_compiled_vertex_arrays
GL_EXT_draw_range_elements
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_env_combine
GL_ARB_texture_env_crossbar
GL_EXT_texture_env_dot3
GL_EXT_texture_env_add
GL_ARB_vertex_buffer_object
GL_ARB_texture_compression
GL_EXT_texture_compression_s3tc

Now let's remove those which are implicitely covered by ogles2 or which make no real sense in ogles2 because we got shaders.
Ooops, only 6 remaining...:

GL_EXT_packed_pixels
GL_EXT_color_table
GL_EXT_draw_range_elements
GL_EXT_texture_filter_anisotropic
GL_ARB_texture_compression
GL_EXT_texture_compression_s3tc

Out of those GL_EXT_texture_filter_anisotropic is covered by ogles2 explicitely too, so let's remove that too.
And from the special formats defined by GL_EXT_packed_pixels half (the most common) are supported implicitely, so that leaves us with 4,5 remaining:

(GL_EXT_packed_pixels)
GL_EXT_color_table
GL_EXT_draw_range_elements
GL_ARB_texture_compression
GL_EXT_texture_compression_s3tc

Now lets take a close look at those remaining ones:

- GL_ARB_texture_compression / GL_EXT_texture_compression_s3tc
Those are actually the only extension in MiniGL that give some additional value over ogles2 / Nova at this time.

- GL_EXT_draw_range_elements
This would be a nice extension - if MiniGL truely supported it. However, it does not: internally it simply calls glDrawElements. So the caller gains exactly nothing, it's a dummy. Nevertheless it would be a nice extension to ogles2 because it would spare me a min/max index detection run.

- GL_EXT_color_table
This feature is a pure software extension. It's not as if only an index-texture plus palette would be sent to the GPU. No, MiniGL internally converts it to one of the normal texture formats. MiniGL. What was the equivalent for MiniGL again? Right, gl4es. If you look for such an extension from the stoneage, expect it to be implemented in gl4es, not ogles2.


The point is:
the extension string reported by ogles2 is so short because practically everything is already inside ogles2 by default.
It is a mistake to expect ogles2 to return extension strings that are actually meaningless to ogles2.
It's the job of gl4es to translate those implicit and explicit features of ogles2 to OGL1 extensions.

Or put in different words:
if gl4es wanted / had implemented all that's supported, it could return an equally large extension string as MiniGL does... (actually it could most likely provide many more extensions with relative ease).

On top of that it sounds as if gl4es doesn't support true VBOs right now, which is something ogles2 offers by default too - and which is the big thing that gives superior performance.

Quote:
No. All that stuff (with the exception of texture compression) is implicitely inside ogles2. It is a mistake by gl4es if it doesn't use those features / returns matching ext strings.

So, it looks as if I have to repeat myself again:
gl4es needs much more work before you can expect great performance. At this time it a) wastes time internally for whatever logic (we can measure that fact) and b) it doesn't actually use what ogles2 offers to speed things up, a short extension string is just another proof of that.

Sidenote: let's not be unfair and not forget that there are issues in ogles2 / Nova too (e.g. 4 component extension, maybe bug in ogles2 with certain glDrawElements pointer setups) which right now prevent gl4es to use ogles2 to full degree in terms of glDrawElements and certain shader setups.

Quote:
With practically absolute certainty, yes.

Quote:
Naturally even the best glBegin / glEnd implementation is much much slower than a direct glDrawElements, and gl4es' implementation is apparently not the fastest, simple as that.

@Hans & kas1e
"black dots":
To me this looks as if some meshs were drawn in wire-frame mode in a second render-path, with texturing enabled and with a bit of z-fighting so the lines' pixels sometimes don't get through.
Totally weird.

@HunoPPC
Cheers mate

@kas1e
Quote:
I told you and it also was proven already, simply due to the existence of the last updates, what was done and what tests revealed:
gl4es required and still requires optimizations / fixes, obviously. Despite the last improvements it's still the major time-eater, simple as that.
And if current gl4es performs better on other platforms, I already said it, but I say it again:
it's easily possible that other platforms don't suffer that much as we do from things like heavy malloc/free or cache-unfriendlyness etc. (or are simply faster per se; other platforms performed even worse if compared correctly, namely that Pandora).

And regarding VBO:
it's a difference like night / day if you have *real* VBOs or no or only emulated VBOs.
Quote:
Taking all this into account all those comparisons above are no surprise at all.

So for gods sake, keep calm and let the guy improve it; then let Hans improve Nova and then let me improve ogles2.
And then let the gl4es-guy finally add real VBOs and all will be good
Certainly not tomorrow though. And following Hans advice I'm now definitely out until Nova has been updated

Cheers,
Daniel

@kas1e
No, with my test I simulated a situation where ogles2 get almost nothing to do. And still fps don't go higher significantly. The obvious conclusion is:
the part that calls ogles2 is the slow one.

Quote:
Not a lot? That's almost another 10% that were previously burned just like that. I wouldn't call that "not a lot"
And hey: in the last days gl4es has been sped up by factor 8-9 (!!!!) Apparently "only" by removing unnecessary heap-alloc-activity and fixing the broken glBegin / glEnd manager.
Makes me pretty optimistic that there's much more inside

Quote:Yes, it is.