Actually upbge has 1 more logic brick, movment sensor logic brick,
technically making it easier to use logic, also the motion actuator linV is set to accel by default, setting it to set linv 0-0-0 actually works now in the motion brick technically making it more usable for logic brick users as well.
Thanks for your answers. I’ll surely have to get my hands dirty to grasp a bit the whole picture.
@Ace Dragon, you have some good questions and thoughts as always! Its really best to ask the UpBge devs on the irc, they can answer best. But i see, that the blender repo is merged in the UpBge, so its really up to date! Only the bge is modified.
This is sounding really promising, i’m excited to see what happens.
For whats new go to here -> http://doc.upbge.fr/releases.php
Ive also compiled a new version (Win 8.1 64b).
One of the arguments I’m trying to make is this. The fork was mainly created out of concern for the development of the BGE (with the core purpose being to take it all the way to being a truly modern engine), but what they did was fork the entire Blender application which means they will also need to maintain all of the areas that are not related to the BGE and are out of their area of expertise.
In general, the project was started because they believed the BF allowed the stagnation of just the BGE for the most part, but we have a very real possibility of the UPBGE project allowing the stagnation in every area of their version of Blender except for the BGE. Either way, it means that there would be areas that become subject to code-rot and degrading quality, and as such might simply be more productive for them to offer Ton the opportunity of having them as the architects of the new 2.8 interactive engine.
As far as I know they don’t need to do that. They can just merge the new patches an all other areas of Blender with UPBGE every now and then. This means that they only need to mantain the BGE, the other areas will be updated by the BF as always.
If they do some major change on the design of the code (they delete and reimplement some important part of code) then there will be problems with the merge, but they have not done that and I don’t think they plan to do it either. Even if they were to redesign the BGE that would be just the BGE, the other parts of Blender could still be merged periodically.
Personally I think the the greatest problem with BGE is the logic bricks and the lack of a proper python API that can work with independence, that’s why I’m developing BGECore Framewrok. The only advantage of UPBGE for me is the increase of performance, but until they don’t have a buildbot it’s just not worth to compile UPBGE just for that.
I have seen some hints here and there about them formally diverging the code to where things like porting are no longer possible (not without a lot of work anyway).
If they want to ensure that UPBGE gets all of the latest advances from the BF, then they will have to make sure that they only touch the code related to the BGE (or otherwise they really do see the possibility of presiding over a version of Blender that is stagnant in every area not BGE related).
…2.8 interactive engine:) It sounds a little like degradation full game development.
It looks that way and the desires of the users of the BGE they are different than the path and plans for BF, but I understand the BF thing, a modern game engine + modelling, animation, etc. in one program,it is very difficult when it is on a few of the developers.
I agree, it sounds like degrading.
If you have a look at the development that happened in the past years in the Blender Game Engine, there wasn’t much going on besides maintenance. Keeping it like that for years won’t improve the situation. There have to be huge improvements to keep it alive. When the interactive mode was suggested, there was very little work happening in the game engine and from my point of view, it seemed to be the only chance to preserve it. By having more code in common, like the rendering code from the not yet finished viewport, the chances are increased that Blender developers might have a look at the game engine code from time to time and the game engine would directly profit from improvements that are made in the viewport.
The gap to game engines that are frequently used in released games is getting bigger and with the lack of developers, there is no realistic chance to make it smaller. As far as I have understood the idea of the Interactive mode, it wouldn’t change much in the Blender Game Engine, besides bringing it closer to Blender’s code base and to give it a more reasonable name. The more reasonable name is my opinion and I won’t change it 
I thought they said they were going to remove logic bricks.
From where did you get that?
They invite the ge team to rethink game logic editing.
This from this websight.
I think that means they won’t be the same as logic bricks.
—– Blender 2.8 – Workflow release —–
Just like for 2.5, the proposal would be to take a bigger leap to a bigger release by not releasing for a year. The 2.76 release then would be the last ‘real’ version we do until 2.80 somewhere in 2016.
Obviously, for the crucial fixes and smaller (stable) features we can do update releases 2.77, 2.78 and 2.79.
Don’t add the half finished Gooseberry targets but take the time needed to code it well:
Particle nodes, hair nodes, simulation nodes, modifier nodes…
Asset managing and browsing, linking, references, external files in general.
Integration in non Blender pipelines.
If somone wrapled c in pgi logic node python,
We would have something fast and flexible like unreal blueprints.
I would like to point out that there are no decided on plans for the BGE at this point other than it staying in it’s current maintenance state. The various discussions brought up so far are all proposals/suggestions/thoughts, and not official road maps.
While there are no official plans, I can make some comments as to what will be likely in the future of the BGE. First of all, there is no intention of removing publishing of games. This is something I have talked with Ton about, and he agrees that it is an important feature to preserve.
Second, the BGE is likely to follow along with the minimum OpenGL version increases that Blender is going through. If I recall correctly the plan is OpenGL 2.1 in the near future, and OpenGL 3.x for 2.8. This mostly means removing code that is for supporting old OpenGL versions and changing some use of extensions to their core equivalents. For the OpenGL 2.1 changes, BGE users are not likely to see much difference. For OpenGL 3.x, the biggest thing users will notice is the very likely removal of multitexture mode. The BGE’s multitexture mode is based on fixed function features that are deprecated in OpenGL 3+. Emulating multitexture mode with shaders would be redundant with the GLSL mode.
My personal thoughts for the BGE (again nothing official) is to start reusing as much Blender code as possible while trying to keep a similar feature set as the current BGE. This would likely mean an initial decrease in performance and some loss of features, but would mean an easier to maintain BGE that would be more likely to benefit from main Blender development. It would also encourage improving the performance of any Blender features the BGE uses (rendering, physics, animation, etc). Right now the BGE has very few development resources, so it is important to find ways to be as smart as possible with those resources.
If the UPBGE render and rasterizer become faster and more feature rich, while remaining stable, will it be pushed to master?
If the fork outgrows the trunk, will you support upbge kupoman?
With the limited development resources the BGE has available, it is unlikely anyone working on the BGE is going to go digging through the commit logs of UPBGE and try guessing what commits could be brought to master. This approach would also be error prone as important commits could get missed if someone unfamiliar with the history of the commits attempts to pick promising looking changes from the UPBGE project. The UPBGE team is always welcome to submit patches of features/improvements they feel are stable and well implemented to the BGE tracker.
For the rasterizer specifically, I would like to see the BGE using the viewport drawing code. This would make it difficult to bring UPBGE rendering features to the BGE. However, that could be a ways out if it ever happens. In the mean time, as I said before, patches are welcome.
While I have nothing against the UPBGE team, any time and effort I contribute to the BGE will very likely be to the Blender Foundation’s official repository.