@thellier
Quote:

That's all wrong.
GLSL for OpenGLES2 doesn't support *any* built-in variables (with the exception of gl_Position).
Again: there's *zero* remaining of any fixed-function pipeling with OGLES2. Where should a built-in gl_NormalMatrix come from?! Out of nowhere?
*All* such variables are uniforms (or attributes) supplied and calculated by the client program or variables calculated manually inside the shader and their names have zero meaning for the functionality.
The only thing that a variable change like the one you proposed will provoko is a compile or runtime failure - unless you consistently rename the variables all over the place, not just in the shader...

Quote:
Better don't. This is outdated and asumes a typical GLSL1-on-desktop-with-fixed-function-stuff combination from the stoneage.


@kas1e
Quote:
That's right. The variable names can be pretty much anything.
*But don't change them!* Unless you also scan Regal's other C++ code and change the names all over the place, e.g. in an glGetUniformLocation call...

Quote:
No, nothing gets "translated".

Quote:
OpenGLES 2 has no fixed function pipeline by definition.
That's the whole point of Regal: to implement those missing functions (and mimic some more).
And the *only* way to implement those missing functions using ogles2 is by creating a matching GLSL vertex / fragment shader pair.
This is true even for the most simple triangle-draw code.


Quote:
If Regal didn't create any shaders, then you either created invalid OpenGL code. E.g. a glBegin / glEnd without meaningful / invalid vertex content won't trigger Regal's drawing system and thus won't trigger shader creation (I suppose this is exactly the scenario you told above?).
Or you only called functions that don't require shader-usages. Such things are state-changes, texture uploads, etc. And the only draw-command that doesn't require a shader-program: glClear (which is why you see your blue background in any case).
In short:
*any* geometry drawing *requires* Regal to create a valid shader-program consisting out of vertex- and fragment-shader!

Quote:
Not necessarily. In both cases you are trying to draw a bunch of colored vertices, using the same OpenGL states. The only difference is that with the white triangle the color is not redefined per vertex. Apparently Regal doesn't optimize for this case (it could send the color as uniform) and always sends vertex color attributes even if not really required.

Quote:
Of course the ogles2.library will return -1 because there's no active valid shader-program. A valid bound shader-program is the requirement for glGetUniformLocation and similar functions to do sth. useful. -1 is the expected result if that's not the case.

Anyway, the thing simply is:
Nova (and maybe ogles2.lib too, depending on GLSL-feature) still needs some more improvements in its SPIRV-to-native-assembler before you can expect Regal to work. And / or manual modifications of Regal's shader generator are required.
Regal expects full GSLS support which we simply don't have at this time, although Hans already implemented quite a lot of stuff.
But right now you simply cannot expect Regal to run out of the box.

That being said:
I know 100% for sure that Nova and ogles2.library are mature enough to create shaders that can do everything required to come up with shaders that can mimic the old fixed function pipeline
However it might be quite a task to come up with such shaders and to integrate them into Regal / make the required changes to Regal.
Good luck!

@AmigaBlitter
Quote:

It depends on what you want to achieve.

You can easily use it to achieve FSAA: just render everything into an offscreeen bitmap which is 2x2 the size than you actually need it to be, scaling all your rendering x2 accordingly.
Then render that offscreen bitmap to the screen using Compositing, scaling it down to your real desired size using filtering, done.

Apart from that, e.g. for single lines there is no way which is free of probably undesired side-effects.

E.g. thellier's approach actually fakes AA by "abusing" bilinear interpolation in combination with fully transparent bitmap areas.
While this may produce sort-of the effect you desire for short diagonal lines, it will look wrong for straight lines (then the filtering will reveal its true nature and appear as some sort of halo around your line).
And depending on your "brush's" shape it will of course have very ugly start / end points unless you take care to compensate the stretching on longer lines by increasing tesselation and only using parts of the bitmap at that areas.

However, something like this is the only way to somehow come close to what you want.
Therefore here are some ideas on how to improve it (not tried, just brainstorming ;) ):

If you want to take that route then your best bet would be to adjust the brush-bitmap and / or UV-coordinates depending on line-size and orientation.
E.g. if you want to draw a straight horizontal line then you should take care that either the brush-bitmap does not contain transparent pixels at the top / bottom or that your V-coordinate is adjusted to not scan those areas during rasterization.

Maybe you can construct an acceptable compromise via some UV-adjustment depending on the line's angle (e.g. if your transparent "border" inside the brush is 3 pixels then the y-border-offset could be something like 3*abs(cos(line_angle*2)). Then add that value to your top-V-coordinate and subtract it from your bottom-V-coordinate.

This would result in:
angle 0 (straight horizontal): 3 (which means to fully remove top/bottom transparent border)
angle 45 (diagonal) : 0 (which means full border and thus full bilinear AA fake-effect)
angle 90 (straight vertical): 3 (like 0)
and so on

Same thing for U of course.

For the start/end "caps" increasing tesselation would probably do, as being said. So instead of 2 triangles render 6, the first fixed size 2 for the line's start, then the stretched main line, then the fixed size end.

@thellier
While you can most likely hack something together using Compositing (after all I even squeezed some sort of hardware z-buffer out of it in WingsBattlefield) so that the result is a bitmap where e.g. all not colliding pixels are masked out or so, it's most likely much faster to do it in software.

After all you'd have to lock and read back your "collision"-bitmap after the special collision-check-rendering.
And in that time a decent "manual" approach would be long done already.

Makes no sense IMHO (at least for your case, exception see below in "additional notes").

However, if you really want to do it, you'd do something like that:

0. I asume you want check for collision between 2 rotated / scaled COBs (Compositing OBjects :P ) which are RGBA bitmaps.

1. select the one with the smaller number of pixels in its bitmap, let's call that A. The larger one is B.

2. change your point of view so that B's rotation, scale and position is adjusted so that those values end up being relative to the unrotated, unscaled, 0,0-positioned A.

3. have an IGraphic RGBA bitmap prepared and cached that matches the size of A.

There are maybe several options on what to do next, one possible approach could be the following (untested, just from guessing / recalling the meanings of the flags and modes; I might be wrong or there's probably a way to make it more efficient, but it should get you on track nevertheless):

4. clear the bitmap to RGBA0000

5. draw B (properly scaled / rotated as in (2)) with COMPOSITE_Src and COMPFLAG_DestAlphaOverride. Important is to *not* set COMPFLAG_IgnoreDestAlpha because we need B's transparency info; setting that flag would also disable writing to the alpha-channel IIRC.

6. draw A into the bitmap, unscaled, unrotated to 0,0 with COMPOSITE_Dest_In_Src. Again, no COMPFLAG_IgnoreDestAlpha.

By all that only the parts where texels of both A and B contributed to should have alpha-values != 0 in the bitmap.
So the final steps are:

7. lock the bitmap, get pointer and stride.

8. loop through the pixel-data, as soon as you find any pixel with an alpha != 0 then you have a collision.

9. unlock


Some additional notes:

- if you want to test for collision only and don't care about with what you collide (e.g. a shooter where you die on contact with any enemy or so) then you can extend (5) and draw all your colliders B0, B1, ... Bn before proceeding with (6); use COMPOSITE_Src_Over_Dst then.
Note that this is a usecase for which this approach may be faster than the naive manual software check, because the player's ship and thus the collision-check-bitmap is very small, lot's of bullets / enemies share the same bitmap and can therefore be drawn in large batches.

- you can probably gain performance by trading some accuracy: just scale the collision-bitmap's size by 0.5 or whatever. Of course you must scale everything else then too.

- for "manual" software-collision-checks you'd of course do the same as in (2): transform everything into the local coordinate-system of the smaller bitmap to simplify things.

I took another look at the SDL2 sources and I suppose I found the reason for the "points mode:none" drop with ogles2.
It looks as if you're measuring the initial shader-compilation here simply because it's the first render-test.

GLES2_RenderDrawPoints calls GLES2_SetDrawingState, which in turn calls GLES2_SelectProgram, which checks the shader-program cache.
Since it won't find anything there at this time it will compile and compose the required shader-prog then.

This process has been massively sped up in ogles2 1.15 (and the netto time wasted is very low indeed) but in such a tiny benchmark it has huge percentual influence in the final number.

With the other one that drops, "RenderCopy mode:none", it's most likely just the same:
in the first frame of that respective render-test pretty much the same things happen, this time it's the very first draw-call that uses a texture and therefore it's the very first time that a fragment shader with texture-support is being requested, which has to be compiled and linked to a program first first.

So, if you change the benchmark prog to not consider the first frame renderered, the numbers should look as to be expected

p.s.: something else I noticed. In GLES2_RenderDrawPoints and GLES2_RenderDrawLines the input-SDL_FPoints aren't used directly but a temporary array is being created, all points are copied and offset by 0.5, then this temporary coord-array is being used for rendering.
If you extend the ogles2-render-path to use more appropriate vertex-shaders for the respective type of primitives instead of one-for-all, then this should be removed and the SDL_FPoint-input-array should be used directly. The 0.5-offsetting can be done in the dedicated points/lines vertex shader then (alternatively you could patch the projection-matrix for those types of primitives).

p.p.s: and some more regarding dedicated vertex shaders:
the current shader always does *lots* of computations that are *only* used by RenderCopyEx. Everything related to rotation is useless for all other draw-commands. Computations on center and angle, involving matrix setup, deg-to-rad-conversion, cos/sin, some adds, all just wasted time. So if / when you modify the shader-management subsystem of SDL2 to use different kinds of vertex shaders you should also take this into account, it won't hurt for sure.

@Capehill
Technically everything is "3D" in case of ogl-whatever

Yes, regarding the point-size stuff:

what I meant (and what I actually told kas1e before positing here, maybe I should have copy'n'pasted the mail :P ) is to remove it for the vertex-shader you *don't* use for point-rendering, of course.

So you should provide two vertex shaders, one for rendering if point-drawing is requested (that would be the one containing the gl_PointSize line) and one for everything else (triangles, tri-strips, etc.), without that line.

So the test package is doing undefined stuff when you render points now indeed, sorry (maybe it even works but it's undefined behaviour nevertheless).
However, it should be good enough to see if it truely makes a measurable difference for other types of geometry.

Kas1e just informed me about this thread.
Good to see somebody does something with ogles2

So far I have no explanation for that performance drop with "points mode: none".
Note however that I didn't actually try your test by myself yet.

I quickly took a peek into the SDL2 source though and immediately noticed one potentially huge useless performance eater:

in the file "SDL_shaders_gles2.c", line 51:
"gl_PointSize = 1.0;"
For god's sake: remove it It's completely useless and is quite a performance killer, removing it can probably speed up the vertex-shader by factor 1.5

Some other notes (and again, remember I didn't check it out myself yet):

depending on the actual number of vertices etc. you are drawing per frame, you probably don't really measure the actual potential 3D performance. I mean, if you render real fat stuff it should quickly perform much faster than "only" around 2x as fast as the others

Btw.: I also have no explanation why 1.15 would perform significantly faster than 1.14. Yes, the new version contains a huge speedup, but that's focused on one single function that actually shouldn't be called often, usually only on startup: glCompile. Such calls are muuuuuuch faster now indeed.

My two cents regarding this leaking issue:
https://www.facebook.com/daniel.mussener/posts/1599164646776643

The game looks good btw., performance on my sam460 and low-end SI is great, no hickups.

Cheers,
Daniel

@magnetic
Sorry, have been a bit lazy (only) with forum responses and diary updates the last week
Typo fixed
Yes, that complete menu-control via joystick / keyboard was something where I really thought "how could they forget that".

Anyway, added some new screenshots showing the bombing-airplane-conversion process. And also added some bombing-mission performance stats, which you'll like for sure

Those stats also show how important it is to cut down the triangle count as much as possible.

@magnetic
Quote:
Check out the development diary's initial paragraph for the latest estimation

Quote:
Not right now. Unfortunately it's on hold, half done, until I have finished the current stuff (which isn't "just" Wings Remastered )

@LiveForIt
Yes...

@Pepe
Yes And yes, I'm fairly optimistic regarding PPC classics (at least if there's a Mediator / Radeon too).

Hi all,

fresh stuff in the dev-diary: progress and madness with the level-conversion

Have fun,
Daniel

@logicalheart
Thanks And yes, that's such a type of issue indeed. However, in this particular case, the time-saving I now get thanks to all those scripts and the ModelConverter outweights the time it took to develop it.

@Hans
Yes, it's a pain indeed. I expect some more of that when it gets to the animated models, like the soldiers But well, not the first time that I have to mess with sth. like that, but the sheer number of models is very high this time.
Luckily I have some code and self-made tools from an old iOS game porting project that I can partially reuse, that will come handy now.
Assimp (great name btw.) looks really interesting! From a quick look the code's structure seems to be pretty clean, not such a mess as so many other open-source projects. Definitely something to consider, for the future.

@amigacooke
Thanks

@all
I just added a pretty detailed photo-session illustrating the model conversion process.
For more information also check out the diary's entries since yesterday

Cheers,
Daniel

@magnetic
Yes, you're right, it's overdue indeed... Somehow it was put on the back burner :P

@magnetic
Here on the Peg2 setup it was extreme during Wings' bombing areas, heavy during strafing and often during dogfights.
Now it is happening almost never. Occasonally there's a short beep.

@noXLar
Thank a lot

@all
Played around with my new 3D model format I came up with for Wings. Here's some bit-fiddle-fun for those who like that kind of stuff

@noXLar
Thanks

@samo79
Handled

@Srtest
Yes, on the Peg2 here the audio issue was real severe with Wings Remastered too. However, while I wasn't able to find / fix the cause in the driver I was at least able to minimize the phenomenon in Wings.
Actually, as weird as it sounds: one of the reasons why Wings' audio issues are probably more hefty compared to other progs on your setup is it's high rendering efficiency
Most textures are packed into large atlases (for bombing and strafing missions this is even done dynamically during loading; the game analyzes which ground tiles are used in the respective level and creates one or more optimized atlases for those on the fly) and the geometry is drawn using pretty large batches. While this approach increases rendering performance quite a lot it unfortunately makes the audio issue on some systems more likely

@magnetic
@pseudaxos
Of course I'm actively on it! Just not that active on the forums
Just uploaded some more screenshots. Currently finishing up the model-conversion/-optimization tool (already good enough for most tasks).

@noXLar
February sounds better; even with the current slow presales-pace I strongly hope it to be sold out until November

Quote:
Thanks! And yes, keeping it up. Since your post the (enhanced) funeral sequence and the (enhanced) medal-earned sequence have been done.
Approaching "everything done but levels"-state

@magnetic
Thanks! No, I'm not discouraged by that, no worries
Regarding that Peg2-RV250 issue:
While I still didn't find the real cause of all this and therefore don't have a driver fix / workaround yet, I could however come up with a workaround for Wings. I just hope it really helps under all circumstances at the end... But well, maybe the real problem has been identified and fixed until then. We'll see.