GLES2+ and multithreading?

For code related discussions and questions
Post Reply
samuraicrow
Greenhorn
Posts: 12
Joined: 15 Sep 2015, 17:50

GLES2+ and multithreading?

Post by samuraicrow »

Hello all,

I've been playing Warzone 2100 for years now and love 3.2.1 with a passion. Anything newer requires a better Linux box than mine uses since the shader model is newer than my graphics drivers support. (Yes, it's a Core2 Duo with the cheapo Intel graphics core.)

I've heard that OpenGL ES 2 can work with Warzone sources if patched through GL4ES so I'm looking to start using it on my 8-core ODroid XU4 but was wondering if native GLES support would expose multithreading possibilities. Current versions are very obviously single-threaded and run well on my dual-core Intel but suffer on my single-board ARM Linux machines.

After having looked through the forums here, I saw some references to LibAngle and Vulkan. The former will help me but the latter will not at all. I have no new systems that support Vulkan. Is there any status updates on this?

What I had in mind for the threads were only compute-intensive tasks being sent to the background threads: Artillary shots, line of site shots, sensors and the like, and collisions could be computed on other threads and their outputs retrieved only to update the global game engine and such. Of course the main thread would still have to handle the OpenGL ES 2 context, rendering and timing of the display.

There is so much more I'd like to discuss but I think I'll end it with the note that I'm not too literate on the modern C++ dialects but do write some code when I have the time. I don't post often but I do still play quite frequently.
User avatar
moltengear
Trained
Trained
Posts: 170
Joined: 22 Jul 2017, 15:05

Re: GLES2+ and multithreading?

Post by moltengear »

Looks cute.
Image

My opinion. The best thing is to make a special version for such devices.
Sounds should be in PCM format. To reduce the computational load.
Textures should also be compressed for this graphics processor. Mali-T628 MP6.
Also concerning the text. Only English and only const char *. There is no utf8.
If we throw out the freetype, and make that the const char* is applied immediately to the compressed textures

If we make a new cross-platform engine, then not everything is so straightforward.
If there is an engine, then there will be an extra load on the processor.
It is desirable that the graphics engine itself, before compilation, "evaluate" the scene and give out the code for different rendering scenarios. I think this is important for small devices.

1)But increasing support for various devices can slow down the development of this dull AI. I think. I often see when two builders need to build something, instead they start dancing ballroom dance.
2)Searching for ways. The unit tries to go through the whole crowd.

3) Threads. There is an opportunity to create many threads and see how much each one is loaded. For high efficiency. But it's not so easy to program.

I looked at the existing code.. This is not at all easy for a first-level programmer. For example, if you take such a piece of code from the file data.cpp.

Code: Select all

static const RES_TYPE_MIN_FILE FileResourceTypes[] =
{
	{"SFEAT", bufferSFEATLoad, dataSFEATRelease},                  //feature stats file
	{"STEMPL", bufferSTEMPLLoad, dataSTEMPLRelease},               //template and associated files
	{"WAV", dataAudioLoad, (RES_FREE)sound_ReleaseTrack},
	{"SWEAPON", bufferSWEAPONLoad, dataReleaseStats},
	{"SBPIMD", bufferSBPIMDLoad, dataReleaseStats},
	{"SBRAIN", bufferSBRAINLoad, dataReleaseStats},
	{"SSENSOR", bufferSSENSORLoad, dataReleaseStats},
	{"SECM", bufferSECMLoad, dataReleaseStats},
	{"SREPAIR", bufferSREPAIRLoad, dataReleaseStats},
	{"SCONSTR", bufferSCONSTRLoad, dataReleaseStats},
	{"SPROP", bufferSPROPLoad, dataReleaseStats},
	{"SPROPTYPES", bufferSPROPTYPESLoad, dataReleaseStats},
	{"STERRTABLE", bufferSTERRTABLELoad, dataReleaseStats},
	{"SBODY", bufferSBODYLoad, dataReleaseStats},
	{"SWEAPMOD", bufferSWEAPMODLoad, dataReleaseStats},
	{"SPROPSND", bufferSPROPSNDLoad, dataReleaseStats},
	{"AUDIOCFG", dataAudioCfgLoad, nullptr},
	{"IMGPAGE", dataImageLoad, dataImageRelease},
	{"TERTILES", dataTERTILESLoad, nullptr},
	{"IMG", dataIMGLoad, dataIMGRelease},
	{"TEXPAGE", nullptr, nullptr}, // ignored
	{"TCMASK", nullptr, nullptr}, // ignored
	{"SCRIPT", dataScriptLoad, dataScriptRelease},
	{"SCRIPTVAL", dataScriptLoadVals, nullptr},
	{"STR_RES", dataStrResLoad, dataStrResRelease},
	{"RESEARCHMSG", dataResearchMsgLoad, dataSMSGRelease },
	{"SSTRMOD", bufferSSTRMODLoad, nullptr},
	{"JAVASCRIPT", jsLoad, nullptr},
	{"SSTRUCT", bufferSSTRUCTLoad, dataSSTRUCTRelease},            //structure stats and associated files
	{"RESCH", bufferRESCHLoad, dataRESCHRelease},                  //research stats files
};

For example, I welcome even assembler, but if this assembler is only in the body of the function. But I don't like this design.
pastdue
Warzone 2100 Team Member
Warzone 2100 Team Member
Posts: 339
Joined: 13 Aug 2017, 17:44

Re: GLES2+ and multithreading?

Post by pastdue »

On the matter of multi-threading:

The game already uses multi-threading for things like loading games and data, and tasks where it is a benefit - like processing path-finding.

For other tasks, I'd encourage you to run a profiler on the game - the latest builds of the `master` branch on GitHub have a number of performance enhancements that massively reduce CPU overhead (without any additional multi-threading).

In fact, if you make a fresh build from the master branch I suspect you'll see a huge performance improvement if earlier builds were CPU-bottlenecked on your machine.

On OpenGL ES:

Some recent steps towards possible future OpenGL ES support have landed in the master branch. The game does not officially support OpenGL ES yet, but we're on the path towards a flexible shader model that supports that in addition to desktop OpenGL.
samuraicrow
Greenhorn
Posts: 12
Joined: 15 Sep 2015, 17:50

Re: GLES2+ and multithreading?

Post by samuraicrow »

Building from source, I got 3.2.3 to work via the GL4ES shim... ...except for the invisible menu text. I couldn't test the main game engine under Debian Jessie. Building the tip of the tree, I couldn't get it to complete the configure script because it needs a newer version of Qt than 5.3.

Re:system limitations
The ODroid XU4 is a small board machine but unlike the RasPi series, it has 2 gigs of RAM. The main limit is the lack of drivers for OpenGL. GL4ES diverts most stuff to OpenGL ES 2 just fine but by no means is it finished. The drivers for the ODroid go up to GLES 3.1.

Re:GLES support
I'm glad GLES support is coming. I'm currently running Debian Jessie (8.x) on my ODroid because the Ubuntu Mate install that is the default doesn't come with GL4ES installed anywhere. Of course the best running OS for the XU4 is Android 7.1 via the LineageOS distribution. There's not much I can do to code for that though.
Post Reply