BGE bug fixing report card; New team is off on a promising start

Bugfixes in the last four days

Fixes already logged in the release notes

  • Fix T42520 The movement of the mouse doesn’t works well in the standalone player (ee58d44)

  • Fix T42097 Mouse look slight threshold even set at zero (ee58d44)

  • Fix T40257: Frustum culling not working properly" (4fac29c, 8ebb552)

  • Fix T42858: Non uniform gamelogic names on copy (072d80a)

  • Fix T39026: No collisions detected with parented rigid body object (9e217cc)

  • Fix T42285: Crash of Blender in Gameengine/Physicsengine concerning ApplyForce (1af042d)

  • Fix T38935: BGE crash (Fase Orientation == Shadow above Collision Bounds == Convex Hull) (1af042d)

  • Fix T42919, T42218: BGE: Python-driven armature animation got buggy (bf157ce)

  • Fix T41570: Blender crash when physics createConstraint (9bd2a7c)

  • Fix T42437: Physics/Compound bug (4ed8b70)

  • Fix T41502: Path following jumping (5d06960)

  • Fix T43215: Rigidbody constraints deletion (8757209)

  • Fix T33762: Texture fonts were not using the material color (8db9b07)

  • Fix T43748: MouseLook actuator raises an Assert error (6d9c994)

  • Fix crash when a constraint misses its reference object (ffee7f1)

  • Total number of fixes so far for this cycle - 21

  • Total number for the last cycle - 6


It doesn’t seem like very much now, but I’m pleasantly surprised to see a hugely noticeable increasing in the number of bugfixes in the BGE since that new team with commit rights started working on it. There is still a large number of issues to tackle yet, but they’ve started to give me reason to think that they could actually pull off the task of putting some life back into the old engine.

How do you think they’re doing so far with this info?

I can’t crash the test build so far so that is promising enough for me :smiley:

Thanks lord Loki, Hg1, Jorge Bernal and Moguri and everyone else!
https://ssl.gstatic.com/ui/v1/icons/mail/profile_mask2.png

Sybren A. Stüvel

and anyone else I missed!

Nice to hear, and it gives me a greater sense of thinking that my old projects won’t implode on me if I try to play them (which not having to worry about things breaking would be a nice change for once) :wink:

To note, this isn’t going to be the thing that makes the BGE relevant again, there’s a long todo list after this which will need to be done (including code organization, mobile support, major optimization work, graphical upgrades, ect…)

I have migrated through every update, so my stuff is pretty much ‘Future proof’ because I remade it all in 2.72+2.73a :smiley:

the candidate does everything and is stable, and my new gpu laughs at my petty polycount. .022 ms latency on my scene in full hd 1080

In my view, the broken programming model, where the python scripting environment exists on top of the logic brick system, is the fundamental problem in the BGE, and until someone makes a decent effort to invert that relationship, bugfixes don’t mean much to me.

but logic bricks are in C right?

Why does that matter? how does it effect usage?

Coding in engine?

I think the bge only needs a few little steps to become great,

but the render is a big step that needs fixing.

after the render there is.

-Logic wire colors

-Leave last noodle highlighted feature or maybe a ‘wave of power’ animation

-worldPosition Sensor

-worldVelocitySensor

But I can pretty much do whatever I want at the moment without any of that,

and my gpu makes my old scenes look like nothing, just got to get some detail in there now…

collision sensors also need collision.hitImpulse

Bugfix count for this release cycle is now at 20.
http://lists.blender.org/pipermail/bf-blender-cvs/2015-March/074446.html
http://lists.blender.org/pipermail/bf-blender-cvs/2015-March/074447.html

Lordloki and others, keep it coming, because you’re part of the last chance that the BGE has if it’s fate is not to inevitably be removed.

You must stop writing overarching comments about the engine, and using hyperbole in the manner that you are.
You’ve stated before that you have not delved into the BGE source code a lot, nor are familiar with C++ programming practices.
I understand that for you the BGE works, and that’s great! But, there are fundamental design flaws (and growth issues) with the BGE that solid performance cannot renounce. Whether or not it runs well, and doesn’t crash isn’t the question. If an application crashes, it’s buggy and that’s bad (NB all applications are “buggy”). What’s being discussed is a more semantic notion of future proof design, and avoiding the possibility of bugs.

The “steps” that you mention quite often about what the BGE needs to become great are not the final mark. Not only this, but fixing “the render” is essentially 1/4 of the engine.

I do not mean this in an offensive manner, but the state of the BGE source code isn’t something that can be disputed. What can be considered is the scope of the task required to encourage the source code to conform with the needs of a growing engine, or whether it’s more efficient to look elsewhere. Whilst I recognise that the BGE means something symbolically to many forum users, it’s just another engine. Without belittling the hard work of those who have contributed to the BGE source code, there are other engines, and the only reason that I would avoid them is because of the ease and familiarity of integration with Blender (amongst a few other personal reasons). If another engine has an identical interface to the BGE, the fact that it is not the BGE holds little importance. Hence, enabling that level of integration is what is important, rather than which engine it applies to.

This and other commits show that in reality, your knowledge about programming and the realities of it in general is almost nill once you get outside of the subset of programming concepts used for Wrectified and once you get to any language that is not Python. We have tried to tell you, but it seems like you made the conscious decision to ignore it and carry on with your own fictional version of things.

Lordloki, Moguri, HG1, Panzergame, and others who are staying with BGE development know what needs to be done, and the list of what needs to be done is far longer and more complex than what you make it out to be.

If you don’t want to make an effort to understand and know where people are coming from, then please stop posting in all threads that mention the state of the BGE and/or talk about programming.

They are fixing bugs, while re-factoring,

the best way to get to know a sprawling code base is to fix bugs in it.

Those features would make it more newb friendly, I really don’t need anything new at the moment,

these are features for new users to not become scared of the pile of logic they create.

Only they currently are not doing any actual refactoring yet, anything related to that sort of thing is just talk at the moment.

Refactoring and bug-fixing are two different things.

from what I read they are unifying code style,
with each bug they fix, and there have been a few proposals
on the dev board to do the whole engine,

there has also been one for refactoring the whole engine.

developer mail list, and gamedev mail list.

Hi all,

Much of the BGE code does not adhere to the code style used in the
rest of Blender. I would like to see the BGE use the Blender code
style; not only because I simply like it better but also for general
consistency.

Some patches, like https://developer.blender.org/D1102, revert
Blender-style code to “old” BGE style. My preference would be to
actually do the opposite, and move new/altered code to the Blender
style, at the cost of (temporary) inconsistency within the BGE files.

I’m curious what you think about this.

Cheers,

sybren in the dev mail list.

A thought,

when I remade my own game from scratch, it was faster and easier then trying to dig around in my older poorly designed code,

could some one recode it from scratch, ‘on the side’ over time, using all the knowledge about the engines design gathered before hand?

Rather then the ‘stack of paper’ it is now? (everyone just sets a new page on top)

And C++ etc, is starting to make sense, I just need to get Git, and a compiler working.

But I have no delusions of re-coding it myself, I am still a scripter.

when I say fix the render, I really only want a few things,

VBO
Instancing
Static Draw call batching

and though the reasons are selfish (for Wrectified)

it will help any game with lots of instances of grass, or leaves or ?

The first time I wrote Wrectifed, writing each system took months,
now I can write each system in a day or less,

From mucking about in the poorly ordered code, can one of you proper coders remake it in a week?

what if I buy you a cookie and a french press?

This would not count as ‘fixing’ the render engine, but adding completely new functionality. Fixing means that you’re repairing functionality that is already there, but is broken.

The BGE devs. are wise to tackle things like bugfixing and code cleanup before they start adding new features, as we need to get the base right so it can handle such work.

another thing to note, I dont need most of the rendering speed ups any more,
Upgrading my computer made all of that matter very little now, as I was on older hardware,
however instancing would make very large open worlds with long draws accessible to slower older gpu/computers,

That would be nice, but again, we are not at the time to bombard the devs. with feature requests.

We know what we’d like the engine to have. There are many techniques for engine improvements, beyond what you’ve mentioned. There’s little point in stating what has already been stated a number of times.

If one can actively work with the engine, then discuss at will, as you develop, otherwise discussion is a waste of time.

I actually planned on helping monetarily, but I will crack the source tonight,

even if I start contributing, I will need to understand your style, and contribute things that make it through the tracker.

it will take a long time

I am mostly self taught and not well rounded, there are things I still dont understand
that well like mode % etc, I have large holes in my techniques still I fear,

the bricks it self are not the problem , is more over the container -> SCA

seeing the structure



C++
    SCA
        BRICKS
            PYTHON





C++ can still exactly where is now.(the root)

but below is a disaster and not seem there middle ways.

the inversion seem the thing more sane.

C++
    PYTHON
        BRICKS





with visual code that is CHILDREN, not parent.
i guess this is the standard in normal game engine

sca (the root of mistake) completely removed of course