Eventhing looks new and shiny now!

There is a setting for max. objects (it's called differently for historic reasons though): https://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#maxPolysVisible

Should be doable. You can implement an IRenderHook and attach it to the objects in question. In it, implement the https://www.jpct.net/jpct-ae/doc/com/threed/jpct/IRenderHook.html#setCurrentShader-com.threed.jpct.GLSLShader--method and then do something like:


int handle = GLES20.glGetUniformLocation(shader.getProgram(), "your_uniforms_name");
GLES20.glUniform1iv(handle, intArray.length, intArray, 0);


in it...that should work...I guess...

No, there isn't. I guess, I never saw the need for it so I somehow overlooked it. Do you need support for this?

Internally, it's used (as you've noticed) for setting the blending modes, but that's the only part that uses it.

About the other questions:

• There's no setter for short-arrays in the API, so I guess not...
• I'm not limiting this, so I guess it depends on the GPU/driver what the limit is.

What's the minimum requirement for this game? I can't install it on any of my devices (granted, they are all a bit older now... )...

My approach is highly simplified as well. It only has to work for this kind of retro-styled arcade racer. Generating an actual landscape with free roaming would have been a completely different and much more complex story.

Nice one!

Long time no new project here...so I thought that I might as well contribute something.

It's not really a "project", but something that I'm working on from time to time. It started out as an experiment to see, how feasible it is to generate a road based on the random number generator alone. Over the months, it turned into something that you can actually "play" albeit it's far from being a game of some sort.

The road and the AI vehicles are all generated, nothing has been placed by hand. It has basic sounds, arcade like vehicle controls, traffic and a very crude collision "model".

Here's a video: https://youtu.be/o3MthgPRDsE?si=GEl1AJA2DRFxJCaJ

And this is how it looks:

If that's the case, I guess that there must have been a reason for it...

...I just can't remember it...

I see. If you call refreshMeshData() on the controller, the newly calculated normals should be updated in the controller and you can obtain them from there.

I'm not sure what you mean exactly...the vertex controller can access the normals already, so you can modify them there. The issue with that is, as the docs state, that this calculation isn't trivial, because vertex normals depend on adjacent polygons as well.

What do mean by

QuoteIs it possible to obtain the calculated normals so they could be fed into the vertexcontroller immediately?

Which calculated normals?

I'm not sure...I assume that the format is the same as the one that OpenGL uses? In that case, have you tried to use Matrix.transformToGL() instead? Despite the name, it actually transforms jPCT into GL and back again. Comparing what these two methods do, it looks like as if yours does somehow a "flipped" version of what jPCT's is doing. Like as if it's working on an inverse instead , but I'm not sure...it might be worth a try to give jPCT's method a shot, though.

Sorry for the late reply...not sure on what metric to sort such a thing, though. As you've mentioned, it doesn't seem to be a list. And a tree would most likely reflect the parent-child relationship.

Not sure what the screen recorder does. Maybe the built-in video encoder can encode screen content directly? No idea...getPixels() is as slow as OpenGL ES. Plus the conversion into jPCT-AE internal format, which requires some byte flipping.

This is an impressive piece of work. I've no idea how to control my plane and I crashed it into the ground, but it's cool nonetheless.