opentechengine / discussions Goto Github PK

http://playcanv.as/p/iCL6sxgF

Nvidia details this as an issue to port Doom3BFG to Andorid in this article: https://developer.nvidia.com/content/bringing-doom-3-bfg-edition-nvidia-shield

it seems that the input makes the app to crash when loading a map because the inputs get paused or doesn't keep working and Androd detects it as a crash

maybe we could incorporate Nvidia's solution to the engine?

also in this article it is interesting the reflection on the asset storage: on how it differed in idTechX from idTech4, to store every asset, necessary in a level, packed within the level's pack, therefore there is a lot of repetition of assets. This helped when reading data from an optical disk but in modern flash drives this is no longer necessary.

Finally got OTE to build successfully on Linux, all thanks to Kortemik :D. I noticed the new version opens a map when clicking on campaign, very nice, however I noticed that after clicking on campaign the mouse cursor vanishes. When pressing escape the mouse is still gone, but there is a sign of mouse movement when hovering over the buttons.

I was checking out this game called Scorn, it's a horror adventure inspired by H.R Gigers art.
There is very little footage in the trailers of the game-play, but from what i've seen it looks impressive. I have been playing around with the rendering cvars and consider the capabilities between RBDoom3BFG, OpenTechEngine and Storm Engine 2 to same type of graphics from Scorn. I'm not sure what engine they are using. Here's the link to the game site. http://www.scorn-game.com/

Aah ok missed the UE4 logo at the end of the video.

I know it's an old version, and I know the fact that the ImGui are being worked in order to replace the mfc tools in the tools from doom3.

but can we get it to compile again? the current show-stopper is the boost header version, the configure file expects an older version (I think) but I don't know how to update it, this is the error I get:

checking for Boost headers version >= 1.46.1... yes
checking for Boost's header version... 
configure: error: invalid value: boost_major_version=

any idea how to soolve this error?

all things pertaining to the Blender Map idTechX map editor here, so I stop hijacking other's discussions with my crappy program :)

my repository: https://github.com/BielBdeLuna/Blender_IDtech4_GPL_map
which I will keep updating the "alpha" branch until I feel i have a master to push

current version: 0.0.4

here is my plan:
export brush data without correct texture placement 0.0.1--DONE
export surfaces without correct texture placement 0.0.2--DONE
export scaled data 0.0.3--DONE
export material name 0.0.4--DONE
export rotated data 0.0.6
figure out a way to export with correct texture placement 0.1.0

export vertex wheighted data in order to open it with idTech X 2.0.0

d3BFG is at the moment to only game that should be playable in the OTE but ATM it isn't playable as a mod of it. making it playable as a mod should allow us to detect errors in the engine that should be sorted out.

1 - mod files aren't yet priority over files packed in *.resources files:
Making fs_resourceLoadPriority default as 0 should allow modding in case of having *.resources files in the mod folder. I made a PR in order to solve this.

2 - *.resources files or any other mod files in the mod directory should be prioritized over any file in the base directory:
When using fs_resourceLoadPriority as 0 *.resources files in a mod directory become the least priority posible even having files in the base directory having further priority than them.

I think this should be the priorities:

1st priority ) common files in the fs_game directory
2nd priority ) *.resource files in the fs_game directory
3rd priority ) common files in the fs_game_base directory
4th priority ) *.resources files in the fs_game_base directory
5th priority ) common files in the base directory
6th priority ) *.resources files in the base directory

3- sound devices doesn't seem to be well detected by openAL, there is no sound and launching s_restart end up with error messages.

I haven't tried SteamOS and not sure as to what changes Valve's team is making to the system, but it leaves me to wonder whether or not they will be using the real-time kernel to focus the system resources on the games.

How long will it take before technologies such as OpenCV, OpenCL, HSA, Vulkan become part of the game development pipeline? Real-time raytraying through OpenCV using OpenCL and HSA to fight bottlenecks could be promising in the future, possibly a step into creating virtual worlds as seen in the Matrix films. Could it reach the ceiling of the uncanny valley?

do you guys see plausible to include it in the code?

imagine the common situation where a window with deformation shader is behind an explosion with another deformation shader, only one deformation is displayed (the one closer)

I wonder if this issue could be resolved with some JIT magic on a per frame basis, so the first step would be to identify the shaders every pixel is subjected to, then on those pixels subjected to more than one shader dos some JIT adding the shaders together creating a new shader (just for that pixel!) in order to render the pixel correcly

maybe there could be a way to simplify the process and identify what pixels would benefit from the same shader?

do you think that it could be possible?

Mario from Xonotic agreed that we can use their assets. It's taking me too long with making OTE assets. So for now i'll be converting Xonotic assets for OTE so we can start testing sooner. Xonotic falls under GPLV2.

We have a very nice front page here: http://opentechengine.github.io/

It's generated out of this repository:
https://github.com/OpenTechEngine/opentechengine.github.io

I think it needs some improvements to be more fancy. Feel free to pull request your updates. Please note that the repository is quite huge (1.5G) due to doxygen.

How fancy

http://opentechengine.github.io/doxygen/html/d4/dbe/class_b_f_g_1_1_c_e_g_u_i_menu_1_1_menu_interface.html

I bet you like it too @DanielGibson

Sorry for spamming the Issues in OTE!

Thanks @DanielGibson, I was really thinking in installing XFCE, there's some things they made on Gnome 3 that I don't like, and it became much more resource hungry, I like a simple desktop that just works and consume low resources.

@yetta1 note that Awesome window manager is a Windows Manager and not a desktop environment, so it won't come with many of the softwares and tools that a desktop environment like Cinnamon comes with.
If you want a very lightweight environment, I think it would be better to search for another distro that comes pre-configured, one that I liked was CrunchBang, but this project died.

If you want, you can install a window manager and configure everything to your liking (it's Linux :D) but it will take time and requires effort, I know because I messed with this before :)

I might be in a position where I might have to compile OTE for windows, for a team that wants to do some mod for Doom3, now I don't have access to a Windows machine. I wonder can code be compiled following the compilation in the readme from within Wine? is there any option for a cross operating system compile solution, in Dhewm3 there was "mingw-w64" but I never used it, and I guess it was a cross operating system compiler?

The texture rotates when moving away. It's in the png format, 128x512/

I was reading about the X-Ray engine used on the Stalker games and I found out that the source code is available on GitHub. I'm not sure if it's a leaked source or the developers released it, it's not free software as the license file tells.

You can find it here: https://github.com/OpenXRay/xray-16

I got surprised as I didn't see much information about the source release, that's why I think it may be leaked source.

Anyway, I think it's OK if one study the code.

The shadows cut off, any way to increase the range without breaking the shadow?

I'm watching this lecture from John Carmack, it's quite old but was wondering what your take is on it.

https://www.youtube.com/watch?v=MG4QuTe8aUw

I'm currently experimenting with Blackbodies etc in Blender with Cycles and using scientific data to simulate lighting and materials based on wavelengths etc. The results when done correctly is quite impressive when using energy based models.

The advantages I can think of is that it would create realistic rendering and will cut down on texture use as wavelength/blackbody values can be hardcoded and mixed with stencil/alpha textures ( possibly proceduraly generated. ). This helps add randomness to the textures and how it is shaded according to the lights values from the blackbodies.

Here is an example of blackbody lighting, It also affects the translucency of the candle wax.

http://wiki.blender.org/uploads/thumb/5/5a/CyclesRelease269ColorTempCandles.png/800px-CyclesRelease269ColorTempCandles.png

Would it be possible to integrate something like this into the cegui interface for shader experimentation real-time?

http://glslsandbox.com/e#26785.0

I'm not sure what improvements have been added into the shaders. Just dropping some suggestions here.

Anistropic specular
Parallax
Self-shadowing relief
texture based lighting/dynamic?
Subsurface scattering

ran make and got terminated with FontManager.cpp, I think it is the 'all' build target.

compilation terminated.
libs/cegui/CEGUI.git/cegui/src/CMakeFiles/CEGUIBase-0.dir/build.make:1066: recipe for target 'libs/cegui/CEGUI.git/cegui/src/CMakeFiles/CEGUIBase-0.dir/FontManager.cpp.o' failed
make[2]: *** [libs/cegui/CEGUI.git/cegui/src/CMakeFiles/CEGUIBase-0.dir/FontManager.cpp.o] Error 1
CMakeFiles/Makefile2:363: recipe for target 'libs/cegui/CEGUI.git/cegui/src/CMakeFiles/CEGUIBase-0.dir/all' failed
make[1]: *** [libs/cegui/CEGUI.git/cegui/src/CMakeFiles/CEGUIBase-0.dir/all] Error 2
Makefile:137: recipe for target 'all' failed
make: *** [all] Error 2

Running make with the ignore error flag, it's compiling the code, with some warnings and errors.

I remember I was searching about compression algorithms some time ago and I found this one to be great https://github.com/Cyan4973/lz4 / https://code.google.com/p/lz4/ it's very fast and was used in Battlefield 4 and many other software.

Do you think it would be a good addition to the engine?

I propose to create a document with ideas we want to implement, with ideas we have, and with ideas we agreed to implement

we could also add how we think we could implement the ideas

what do you think?

the first step I'll try to re-implement is the GUI for loading levels, and I'll try to implement it without loosing the SWF implementation

So, finally there is a breakthrough with collisions ( here is the test case https://drive.google.com/open?id=0BwE6dxM0O2PsQUNncWw0aGFuZms ):

http://www.pasteall.org/60504/diff

not mine, but I tested and it works. The only issue that is left is anim stuttering: https://www.youtube.com/watch?v=q-4Z7CTYodk

Just letting you guys know that I am back on my pc. I will start working on the packaging and cleanup for the demo level, models, textures in the next few days.

I'm having issues building OTE on Windows 10, I've tried VS 2015, Eclipse and Codeblocks. All errors are different each attempt. I can't run the debug binaries provided by Kortemik on his sourceforge page, as I do not have VS 2013's debug libraries. Could one of you maybe provide me with a 64-bit release binary?

What kind of assets would be good for OTE demos and projects? Right now I'm using MakeHuman, and some model editing programs like Zbrush to make a basic generic 'player model,' as a small art project for OTE community...

Would it be out of the question to discuss porting Ogre 3d into OTE? Ogre has a load of next gen features... A demo on how to do a full game menu GUI in MyGUI (kinda like CEGUI-lite) for Ogre can be found at the 'Ogre VDrift' project page... There is also a GPL Mahjong game one of the main CEGUI programmer dudes designed using CEGUI and Ogre that has a pretty complete demonstration of how to get a game working with a basic menu, besides the nice demos already included with CEGUI... I did a simple Valve style GUI for CEGUI and Ogre for demo if anyone is interested, it's GPL just ask...

While formatting code I saw some little things that can be done to improve the code:

1 - There's a lot of for's iterators declared in the beginning of the function, and also for's that uses post-increment instead of pre-increment. So I can change them from this:

int i;

for (i = 0; i < myvar; i++)
{
// CODE
}

To this:

for (int i = 0; i < myvar; ++i)
{
// CODE
}

which limits i scope to the for loop and increases performance by a little amount.

2 - Some code that does nothing, for example:

canContinue = false;

const saveGameDetailsList_t  &saveGameInfo
        = session->GetSaveGameManager().GetEnumeratedSavegames();

canContinue = ( saveGameInfo.Num() > 0 );

The line canContinue = false; does nothing.

Please, if you found other things like this add them in this "issue".

I've been trying out modded versions of the renderprogs, not sure if the engine is loading the files correctly, it's not showing any changes or adding any new effects. I'm mainly trying to get SSAO in the engine. Even deleting the folder the engine runs fine without change. I've also used resourceLoadPriority. Is the vertex/pixel shader code hardcoded into the engine as well?

I'm currently adding the path routines to the AI and tried something: in c++ and other languages you can write parts of the methods of a class in another file.
This might prove useful in order to have the code well separated in groups of methods or functions that correspond to an area, could this be done in idTechX script? it can be done

as long as in the script-object (idTechX has no objects, but has script-objects which depends on entities) those functions are introduced, you can then extend them in any other file, as long as then the file is included

so you can have:

a ai.script file an then a ai_extra.script file

and in ai.script you can have this:

object super_cool_ai : super_cool_ai_base {

    void super_cool_fucntion();
    void not_so_super_cool_function();

};

void  super_cool_ai::not_so_super_cool_function(){
    // not so super cool code here
}

and in ai_extra you have this:

void  super_cool_ai::super_cool_function(){
    // super cool code here
}

you then in the main.script file add this:

#include ai.script
#include ai_extra.script

idTechX will accept the code, so this means that the engine will keep searching unfound functions until the end of the files and if he doesn't find it then it will error out to desktop with the pertinent message.

this is great to have the AI code not in a single file like how it was in doom3 scripting but have it well separated in different files

it would be great though to have those separated methods be able to be reused whenever it's necessary for the user, but this can only be done in two different occasions:

• it needs to be used in a superclass form the class the user is reclaiming that method, so the method can use variables already initiated by the superclass
• or have those methods be self contained so they can be used anywhere, but then this is more akin to the "subs" (subroutines) than those out of the class defined file methods.

maybe the best practice would be to make an AI that uses the least amount of variables so it's more process intensive but allows for even more flexibility? and maybe use variables just for the most generalist functions so they are initiated in the well above superclass stratification?

Open Tech Engine is creative cooperation applied to game development.
Open Tech Engine Achieves cooperation through creative means.
Open Tech Engine strive for meaningful functionality as the basis for different applications.

A stepped process:

1 - building a meaningful community.
The best way to hold a community together is trough having a modifiable platform, and having a genuine interaction with the community

1.1 - build a modifiable platform
to have a modifiable platform means to have a set of assets that people can use as basis for their mods/games/applications
the best way to have a first modifiable platform is to create those assets in an organized way

1.1.1 - building the first assets in an organized way
the easiest way to create those assets would be to create meaningful assets, and identify what assets to build would be far easier as a part of a coherent game, since the engine is the byproduct of an existing game, the easier game to create would be something similar to that existing game

1.1.1.1 - building a first game
since we don’t have a big team, the best bet would be to create a “vertical slash” a couple of levels, or a single level, two to three weapons, and two to three enemies, with that “vertical slash” in place levels could already be created and mods could already be done

1.1.1.1.1 - building a vertical slash
we could copy existing mods or games, beside the game the engine is a byproduct of, as our “vertical slash”
here is a list of proposals of single or couple of levels long mods that could be interesting as basis for our initial “vertical slash”:

doom - The City of The Damned : Apocalypse - video - link
quake - Plumbers Don't Wear Ties (But They Do Carry Shotguns) - link
quake - The Altar of Storms - video - link
quake 3 - The edge of forever - video - link
quake - The Marcher fortress - video - link
quake - Firetop Mountain - video
quake - The Horde of Zendar - video
quake - Forgotten Sepulchre - video - all last three within this mod

we could have something build like one of them updated with the current improvements the engine has, that would serve to gather the limits of the engine we have on our hands, and a trial to resolve bugs from the new improvements, it could be something meaningful enough to stand on it’s ground but not overly complex to build.

1.1.2 - building the community pro-actively
since now we have a small asset pool, we could try to build a community out of mapping, that would serve in more than one way, it would build community out of the creations of the community. And would serve to create new assets and empower tool creation. Sort of:
http://www.thedarkmod.com/missions/

1.1.2.1 - manage the community with creativity
we could have a lively community with mapjams, or even with yearly competitions, sort of:
https://www.quaddicted.com/

1.1.2.2 – guest-mapping
proposals for known mappers to guest as mappers for our engine as propaganda of the community, let those that inspired us also inspire others on our behalf.

1.1.2.3 – perpetual campaign for the engine and it’s possibilities
every time we get a new feature create screen shots and didactic videos that attract new talent to the community and pro-actively distribute the videos on the appropriate social networks, sort of:
http://www.celephais.net/board/news.php

1.1.3 - enhancing the community possibilities
we could also build community from a asset point of view, with a repository of assets so everyone can supply their created assets so all in the community benefit from the community efforts, like this:
http://www.realm667.com/index.php/en/

1.1.4 - enhancing the reach of the engine
building other «vertical slashes» for games that differ from the original game, the engine is byproduct of, would be wiser at this stage so the possible applications of the engine are enhanced

2 - enhancing the technology of the engine
building better technology should be an end goal that would be beneficial to all anytime

2.1 – recognizing the outsider work
works outside the community are also valuable, let’s people into the community but doesn’t require it, so a proactive attitude towards outsider work should be the normal attitude

Storm Engine 2 has been out for some time now, along with Blender add-ons for it:

https://github.com/motorsep/StormEngine2

Seems the old issue has come back. The PNG files do not show in DarkRadiant and reverts to the shader not found image. For now I've reverted to using TGA's.

Texturing is taking longer than expected, the preview has the base colour. I still need to do the details, then render to another UV layout to eliminate the symmetrical texturing and less seaming. After it's done. i'll save out different colour versions for multi-player and future in-engine editing. The model is under 3000 triangles.

Hi guys, I'm in the process of moving to another country and won't be taking my desktop with me, so I'll be away from the project for a while until I have everything settled and built a new system. I don't want to release the assets I have so far as I want the release to be a surprise. I'm not sure how long I will be away from the project, so if I'm scarce it's due to the move.

Would it be possible to do some kind of per model back facing occlusion and LOD models in the engine to help optimize scenes using high poly models? Some modern games have characters with models going up to 200K+, I'd like to do character/weapon models and some static models with higher poly counts but feel it may cause issues. Currently I'm modelling with lower polys/triangles and splitting up higher poly static models based on what BFG uses.

I'm working on textures for the game and would like to use a compressed format which has no legal restrictions. So I looked up alternatives and found out about the Kronos group KTX format. This is similar to the DDS format without the S3TC patent issues. Would you guys consider adding in the libktx into the engine? Here is the Kronos link to the format.

https://www.khronos.org/opengles/sdk/tools/KTX/

Biel's vision is a good foundation to build on and i would like to further enrich it with technical ideas to make the engine a more stable bases for development, easier to maintain and extend and more accesible to content creators.

The codebase is quiet big with alot of moving parts, but some of these parts are outdated or legacy stuff which makes it unnecessarily hard for our small team to maintain it, examples for this are cg shaders and their translation into glsl/hlsl, flashbased gui system, 3rd party libs source code which is just "drop in" in the codebase, complex handling of these 3rd party libs but also git submodules.

My idea would it be to firstly make the engine more "equal"on multiple platforms, one step in that direction would be to finally deprecate cg shaders in our engine and replace them with a platform-independent alternative, imho the only option we have here is glsl as shader language, this means the logic to parse and handle cg shaders should be removed by a proper glsl shader parser.

Similair the flashbased menu should be removed by an alternative, we have already cegui integration but i propose that we instead try to reenable the old doom 3 gui system as it is a battleproven and has atleast some consumers within the doom3 community like for example the darkmod aka the is knowledge available how to create guis using it.

3rd party libs is a more difficult topic, we have code just dropped in as it and we also have a certain amount of git submodules. Both have certain problems, 3rd party libraries that are just dropped in like that dont receive any updates from upstream, this includes security related fixes but also potentially useful new features which we might want to integrate. Our git submodules that we have are already a bit better in that we have a copy of the upstream source which we can update easily at any time, but they also have the problem that the library in question already needs to be available via git or that we maintain the source code ourselves in git which adds alot of maintainance burden for our small team. Because of that i suggest that we remove the dropped in versions of 3rd party libraries and git sub modules and instead refactor our cmake build configuration to be smarter and find these required libraries itself. Potential devs and packagers are then free to provide the required libraries in any suitable way.

Reducing the codebase like that while make it easier to maintain it but we also what to make our engine more attractive for content creators, one way to do that is to add more modern content formats, in terms of 3d models ahve have for example "only" stuff like md3, md5, lwo and probably something else and it looks similair on the audio side. We should aim to add newer formats to the engine like OpenGex, glTF 2.0 but also older but widely used formats like ogg to give content creators more ways to use their work with our engine.

But content creators dont only need more available formats but also tools to work with, this means we also need to bring back the old engine tools the original version of doom3 had. These tools are sadly not platform independent and need to be reworked. We already have a simple light editor as proof of concept thanks to Daniel's work.

(First draft of my proposal, will update it as i get more ideas)

To keep the OpenTechBFG issue tracker overseeable, feel free use the issue tracker of this pseudo-project as a discussion forum

I defaulted the cvar fs_resourceLoadPriority to 0 so it makes it easier to mod the engine:
RobertBeckebans/RBDOOM-3-BFG#241

I also added this as a patch for OTE:
OpenTechEngine/OpenTechBFG#79

and I added an explanation for compiling in linux:
OpenTechEngine/OpenTechBFG#77

what do you think?

Damiel and Me have been speaking lately about the nature of the project, we feel the project lacks planning and a common vision, at the moment it’s just a couple of individuals working here and there without a clear direction, we propose a way to define a clearer direction with a defined set of steps, we propose that during the next week we have free proposals posted on the ‘forum’, each on on it’s own 'issue' thread so it can have it’s own discussion separated, and the following week we vote on it, and the most voted it’s the one we could follow.

On the proposals, we consider it should have a clear vision stated in a few lines and a proposal for a stepped process to reach it, in order to differentiate the proposals from other stuff in the ‘forum’ we could have their individual 'issue' thread named starting with:

[OTE 2017 Vision] – name of the proposal

The discussion on the proposals should be useful for revising the presented proposal in order to gain more votes, hence the week of time for the proposals. Then in the beginning of the following week we freeze the proposals and vote on them.

This doesn’t mean we won’t accept things outside the voted proposal, or outsider work, ( There is always the outside loner that will call us deformed soviet bon-vivants :) , his work apportions will always be welcomed ) it just should concretize our common efforts.

So next week ( sept 18 – sept 24 ) is proposal week for the vision for OTE in 2017

list of proposals:

[OTE 2017 Vision] – Technical ideas and clean up of the engine
[OTE 2017 Vision] – a communal and open approach ---> merged into the other one <---

Proposals are merged as they are now

next Week ( Sept 25 - Oct 1 ) is vote week!
in order to vote let's leave a message in the proposal thread stating that we vote

vote passed

I tried this map earlier for Darkmod which has animated grass and water. It runs quite smoothly, the only thing missing is player collision with the grass to flatten it.

Here is the link to the pk4:
http://www.moddb.com/mods/the-dark-mod/addons/arcturuss-animated-grass-demo

I can't use the mouse when in fullscreen, it only moves when in windowed mode. It also stops me from typing in the console.

With the last commit we have GLSL as the sole language for the engine, currently we generate the GLSL files from the original CG files the engine came with, once generated the GLSL files, the CG files are no longer needed.

This method was already used by doom3BFG where GLSL files and HLSL files where being generated from CG files (HLSL and CG being both created in part by Microsoft, are very similar)
HLSL files though are not used, nor CG, when in-game only GLSL files are used, just at the start of the engine, the CG was converted to GLSL.

HLSL was used somehow in the xbox 360, CG in the PS3, but none of the code remains in the engine, and GLSL was used on Windows, Mac, and Linux.

so why not stick with CG? because the conversion is a wasteful process, and because CG will no longer be updated as it's been deprecated by Nvidia (their sole maintainer), and because, if needed, code could still be translated back to CG or HLSL, with some added effort.

Why was CG wasteful: during the translation of CG code to GLSL, only the types where changed, from Float4 to vec4 and stuff like that, so any variable "float4 colour" in the CG file was translated as "vec4 colour" into GLSL, and like this with any other type that needed changes where translated accordingly.
also some variables changed name following a convention stated in the c++ code.

But between languages there was also changes in the base functions, like the one the extract the colour of a pixel from a given image, in CG it reads like this:
float4 tex2D(sampler2D samp, float2 s) page 774 on CG documentation
in GLSL it became something like this:
gvec4 texture (gsampler2D sampler, vec2 P [, float bias] ) page 98 on GLSL documentation
so the code is written for a function named "tex2D" that is the same as the "texture" function that takes the same parameters.
then, the clever guys at ID came up with a good solution, they added to every GLSL a part of code with some specific functions, like in the case of every fragment shader, the following would be added:

	"#version 100\n"
	"#define GLES2\n"
	"#define PC\n"
	"precision mediump float;\n"
	"#extension GL_OES_standard_derivatives : enable\n"
	"\n"
	"void clip( float v ) { if ( v < 0.0 ) { discard; } }\n"
	"void clip( vec2 v ) { if ( any( lessThan( v, vec2( 0.0 ) ) ) ) { discard; } }\n"
	"void clip( vec3 v ) { if ( any( lessThan( v, vec3( 0.0 ) ) ) ) { discard; } }\n"
	"void clip( vec4 v ) { if ( any( lessThan( v, vec4( 0.0 ) ) ) ) { discard; } }\n"
	"\n"
	"float saturate( float v ) { return clamp( v, 0.0, 1.0 ); }\n"
	"vec2 saturate( vec2 v ) { return clamp( v, 0.0, 1.0 ); }\n"
	"vec3 saturate( vec3 v ) { return clamp( v, 0.0, 1.0 ); }\n"
	"vec4 saturate( vec4 v ) { return clamp( v, 0.0, 1.0 ); }\n"
	"\n"
	"vec4 tex2D( sampler2D sampler, vec2 texcoord ) { return texture2D( sampler, texcoord.xy ); }\n"
	//"vec4 tex2D( sampler2DShadow sampler, vec3 texcoord ) { return vec4( texture( sampler, texcoord.xyz ) ); }\n"
	"\n"
	//"vec4 tex2D( sampler2D sampler, vec2 texcoord, vec2 dx, vec2 dy ) { return textureGrad( sampler, texcoord.xy, dx, dy ); }\n"
	//"vec4 tex2D( sampler2DShadow sampler, vec3 texcoord, vec2 dx, vec2 dy ) { return vec4( textureGrad( sampler, texcoord.xyz, dx, dy ) ); }\n"
	//"\n"
	"vec4 texCUBE( samplerCube sampler, vec3 texcoord ) { return textureCube( sampler, texcoord.xyz ); }\n"
	//"vec4 texCUBE( samplerCubeShadow sampler, vec4 texcoord ) { return vec4( textureCube( sampler, texcoord.xyzw ) ); }\n"
	"\n"
	//"vec4 tex1Dproj( sampler1D sampler, vec2 texcoord ) { return textureProj( sampler, texcoord ); }\n"
	"vec4 tex2Dproj( sampler2D sampler, vec3 texcoord ) { return texture2DProj( sampler, texcoord ); }\n"
	//"vec4 tex3Dproj( sampler3D sampler, vec4 texcoord ) { return textureProj( sampler, texcoord ); }\n"
	"\n"
	//"vec4 tex1Dbias( sampler1D sampler, vec4 texcoord ) { return texture( sampler, texcoord.x, texcoord.w ); }\n"
	//"vec4 tex2Dbias( sampler2D sampler, vec4 texcoord ) { return texture( sampler, texcoord.xy, texcoord.w ); }\n"
	//"vec4 tex3Dbias( sampler3D sampler, vec4 texcoord ) { return texture( sampler, texcoord.xyz, texcoord.w ); }\n"
	//"vec4 texCUBEbias( samplerCube sampler, vec4 texcoord ) { return texture( sampler, texcoord.xyz, texcoord.w ); }\n"
	//"\n"
	//"vec4 tex1Dlod( sampler1D sampler, vec4 texcoord ) { return textureLod( sampler, texcoord.x, texcoord.w ); }\n"
	//"vec4 tex2Dlod( sampler2D sampler, vec4 texcoord ) { return textureLod( sampler, texcoord.xy, texcoord.w ); }\n"
	//"vec4 tex3Dlod( sampler3D sampler, vec4 texcoord ) { return textureLod( sampler, texcoord.xyz, texcoord.w ); }\n"
	//"vec4 texCUBElod( samplerCube sampler, vec4 texcoord ) { return textureLod( sampler, texcoord.xyz, texcoord.w ); }\n"
	//"\n"

As you can see "tex2D" is there as well as "texture" in the same line, so since in GLSL there isn't a function named "tex2D" they've created one so they don't have to parse the CG files, the rest of the file is the CG file minus the comments. so all this list is all the different functions the CG used in all fragment shaders converted to GLSL, even if you don't use any of them in your little fragment shader CG file, you'd get all this stuff copied in your GLSL translation

And ultimately there is another reason: the GLSL spec for 3.30 version is only 116 pages long
while the latest CG spec for CG 3.1 is only 1027 pages long (as it covers the CG API, the CG API for OpenGL, for DX9, for DX10, for DX11 etc... ) so the documentation is compacter, more to the point, and with relative ease of understanding, I recommend to download the GLSL documentation: https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.3.30.pdf

so now with my PR this can end:

now all the CG code is in it's own directory named /renderprogs/cg/ so rendreprogs is free to contain just GLSL code

as I explained in my pr, right now there is still CG conversion going on, the engine looks for CG files, and if they exist and the engine is forced (which currently is forced by default, until we supply GLSL files ourselves ) then the engine converts the CG files from their folder to the appropriate GLSL files in the /renderprogs/ directory, as well as making a copy of those converted files in their appropriated GLSL directory, as it did before (but now it uses the GLSL files in the /renderprogs/ directory )
the engine can use several different version of GLSL depending on what GPU you have in your machine, and on the level of the GPU you have there, as well as the drivers you use.
The engine currently it uses OpenGL32 core profile which uses the GLSL version 1.50, although the lowest machine that runs the engine at OpenGL32 core profile (yeah, my machine XD ) is capable of OpenGL3.3 at core profile, but this stuff is for future pull requests.

there is a new cvar with my PR:
idCVar r_sourceGLSL( "r_sourceGLSL", "0", CVAR_BOOL, "Whether if we use GLSL files as source for the shaders or CG files");

as this piece of code states currently is defaulted off if we want to use pre-existing GLSL this has to be turned on when starting the engine adding the following command after the engine

+set r_sourceGLSL 1

but first we have to create all the GLSL files to start playing with them!
for this we have r_alwaysExportGLSL which is defaulted to 1 so the engine works out of the box with the CG code.

and here comes the only bug I couldn't solve:

if we set r_sourceGLSL to positive and then set r_alwaysExportGLSL to negative, not all CG files get translated

so if we're working on the GLSL files there is risk of overwritting your work with the "crap" in the CG files! so right now as a solution I propose the following:

1. start the engine with +set r_sourceGLSL 1 +set r_alwaysExportGLSL 1
2. and once completed the conversion quit and re-start the engine but this time with +set r_sourceGLSL 1 +set r_alwaysExportGLSL 0, or even better change r_alwaysExportGLSL to 0 as default behaviour in the c++ code.

why not distribute already GLSL files? instead of keeping redistributing the CG files? because the GLSL as they are created now, they don't contain any comment, and have excess code that should be eventually cleaned, and also there are some things we could do that Motorsep does in his engine fork, that is heavy use of the "import" statement, so GLSL files (that most of them are copies of one another with different names) could be very small.

once we have cool GLSL code we could stop distributing the old CG files and distribute our own GLSL code as well as invert the default value of r_sourceGLSL and r_alwaysExportGLSL in c++ code.

Hi guys. I'm still working on the art assets guide. I was wondering if one you would do a tutorial for users to add in their own GLSL.

Would it be possible to add in assimp (http://assimp.sourceforge.net/main_features_formats.html)?
It supports many model formats and could make it easier for artists to export to OTE.

Could the source and binary versions also include links to scripts for importers/exporters for the popular 3D modelling tools in the documentation? Or better include the scripts or forks of them?

I can't seem to get alpha channels to work with PNG's or TGA's in OTE, I've tried various material code from D3, but the texture ends up being completely invisible. Can someone maybe give me working material scripts?

Creating this for any future issues on Linux, discussions, tips & tricks etc.