Deprecated Open GL Research and Code Changes...

[datahead8888]

The fixed function pipeline in Open GL is deprecated. Programs are supposed to use the newer Open GL, which requires GLSL (a shading language to write Open GL code snippets that run on the GPU).

Prior Forum Discussions:

• http://secretmaryo.org/phpBB3/viewtopic.php?f=6&t=2885&p=17575#p17575 and
• http://secretmaryo.org/phpBB3/viewtopic.php?f=1&t=9929&p=44619#p44619 (toward bottom)

These are the major things that are deprecated in the old Open GL and that must be changed if they're in use in order not to have deprecated code:

• All matrix transformations must be done with GLSL (ie do not use glRotate3f or glTranslatef)
• Lighting must be done through GLSL (ie do not use glLightfv)
• Textures must be done through GLSL (ie do not use glEnable(GL_TEXTURE_2D); )
• All drawing calls must be done using vertex buffer objects and not immediate mode (ie do not use glBegin or glEnd function calls)

Tasks:

• [ ] Verify - are there any Open GL categories of importance other than the ones I listed above?
• [ ] Research support for fixed function pipeline on newer graphics cards versus support of GLSL on older graphics cards (as possible - forum posts might be a good avenue)
  • Professor Han Wei Shen at Ohio State University said that after a certain point, support for the old Open GL will be dropped, and a lot of programs will break. Many other people think it will be a long time before this, however.
• [ ] Identify a list of all major Open GL function calls or constants that are deprecated
• [ ] Run text searches through the Secret Maryo source code to identify all usage of deprecated items
• [ ] Identify 3rd party library to replace some of the matrix/vector functionality that is no longer handled by Open GL
  • GLM seems to work pretty well - http://glm.g-truc.net/0.9.5/index.html
• [ ] Analyze logic and structure of Open GL relevant code
• [ ] Write code for changes
• [ ] Unit Test Changes
• [ ] Regression Test all of Secret Maryo Chronicles (anything that displays must be tested)
• [ ] Write documentation for Open GL rendering

NOTE: Not slated for upcoming release

[Quintus]

Wow, that’s a lot. You will have a hard time working through this issue :-)

Professor Han Wei Shen at Ohio State University said that after a certain point, support for the old Open GL will be dropped, and a lot of programs will break. Many other people think it will be a long time before this, however.

This is not really a question about thinking or not, it’s a decision made by the OpenGL project, so you should look for definitive information on https://www.opengl.org/. This will give us a final date, but of course, the earlier we switch to new standards, the better it is. Waiting until just before it is required is bad. Maybe you should embed your code in #ifdef statements so the new code can easily be enabled/disabled by means of a compilation configuration flag.

Unit Test Changes

Currently, SMC does not have any testing code. I’m not sure if this is really necessary. We are not a commercial project that guarantees a working program, neither are we a library that should really be working as it is used by others. As an open-source end-user program, most of this and

Regression Test all of Secret Maryo Chronicles

will be handled by the community. As long as it is playable, people will complain in the forums or even make bug reports if something doesn’t work as expected. Note I don’t want to prevent you from writing tests, but if you think you can live without them this would be fine. If you think you can’t, be warned SMC currently has no tests and you will have to write a lot of these yourself.

Write documentation for Open GL rendering

Yes. SMC has far too few information on its internal working. The more is documented, the better.

Btw., I’ve edited your initial post to better interact with GitHub’s markdown rendering. This is now a nice task list that can be checked as the process continues :-)

Vale, Quintus

[datahead8888]

I haven't agreed to code this yet :P Actually, as I said, my availability in coding in general has more to do with my own schedule in school.

To a large extent I was just being very detailed in the sub tasks. For example, we could remove the sub task for researching support across different cards if we wanted to; though it's not bad to look into a little if we can.

By unit test, I did not mean writing test scripts. When people run tests for sections of changed code by hand, this is often called unit testing. From this perspective all changed code is supposed to be unit tested.

Yes, community testing is what I meant by regression testing. However, we want to make sure different people ultimately try all the display logic out and need to tell them to do this.

Documentation is usually a problem for large scale projects. I just figured it'd be a healthy thing to add to the notes. I can't say I've always been perfect about doing this on things I worked on either. You said yourself the old developers left the project, so this is something worth thinking about on future tasks; though it needs to be done more at a project level, not just for Open GL changes.

[datahead8888]

It probably is possible to do the vertex buffer object part by itself first and merge that into the code base. This change is probably a bit tedious by itself. This could be separated into its own github task if we want.

We will also need to evaluate whether we want to continue using OpenGL directly or use a renderer to do it for us. This is related to the discussion on using Bullet because it is a question of our development philosophy. Now is a really good time to make this decision, since legacy OpenGL code has to go. I will have to make a forum posting on Bullet & Rendering when I get a chance.

[Luiji]

I was going to comment on this awhile ago but forgot to. I personally think it'd be much more valuable to use a library to handle 2-D rendering then to implement it ourselves. Right now little bits and pieces of OpenGL code are sprawling throughout the code-base. Additionally, we have to regard whether or not we want OpenGL proficiency to be a requirement for developers to successfully contribute.

Personally, I'm a big fan of SFML[1]. It provides a really easy to use C++ API for 2-D -oriented graphics programming. Alternatively, I believe the latest versions of SDL handle OpenGL rendering in a similar way (though personally I find the SDL APIs wretched). I used to do a lot of coding with Allegro[2] which has the main bonus of being able to support Direct3D as well without any change in client code, though (like SDL) it's just a C API (though a much better one than SDL).

SFML and Allegro (and probably SDL) also have APIs to allow direct OpenGL access when necessary and contain shader support, so we aren't exactly limited by this solution. Since we already require SDL 1.2 to setup the OpenGL interface and handle I/O, we aren't exactly adding a dependency but are replacing it, so we don't have to worry about adding to dependency bloat.

In any situation this is a fairly large project, as no matter what (including the SDL upgrade) we are re-factoring an entire code-base of graphics programming. Since the deprecated APIs are still commonly supported, we'll have to consider whether we want to deal with this in SMC 2 or 3.

[1] http://www.sfml-dev.org/ [2] http://www.liballeg.org/

[datahead8888]

 I will have to make a forum posting on Bullet & Rendering when I get a chance.

--Sorry, I was focusing more on trying to get SMC to compile with the time I had and haven't had a chance to post this yet. When I do post it, would the Development section on the main site be a good place? I also have some different thoughts on what 3rd party libraries might be appropriate for these items and what is supportable for newcomers; I can post these thoughts at that time.

The discussion about using a renderer came about after I debated Quintus a bit on the physics implementation in IRC. If we embody an absolute, strict "never 'reimplement the wheel'" and interpret that to mean that we should never implement our own geometry or physics algorithms, ever, it would not make sense for me to invest time in a serious OpenGL conversion or start working toward challenging OpenGL tasks. Thus I raised the question about whether we want to do away with OpenGL and have a renderer do it for us.

As I've said, I lean more toward implementing our own physics/OpenGL or jerry rigging custom code for both of these with libraries that do portions of work. The place to really debate that will probably be the forum entry.

simpletoon indicated he wants to rewrite the collision system to use BSP trees. We need to tell him to hold off on this until the question of physics / object collision systems is resolved. I was poking around, and I think Bullet already implements tree based systems for collision detection. I like the idea of enhancing our own object collision system ourselves, but I don't want simpletoon to waste his time if everything goes Bullet.

Thank you for your feedback, Luiji.

[datahead8888]

I pm'ed simpletoon about the bsp trees.

[Quintus]

simpletoon indicated he wants to rewrite the collision system to use BSP trees.

You can use an @brianvanderburg2 mention, then GitHub will drop him an email and a notification on his dashboard pointing him to this discussion.

As I already explained, I’ve no experience in graphics programming. I will follow whatever suggestion you find good, as long as we don’t pull in a tail of ten more dependencies or so.

In any situation this is a fairly large project, as no matter what (including the SDL upgrade) we are re-factoring an entire code-base of graphics programming.

This is true, but SMC’s code base is ten years old. We can’t carry it around forever. I agree that rewriting the graphics base cannot be done in 2.0, it’s too large. We can branch off after the 2.0.0 final release a feature branch for this, and when we find it to be useable, we will merge it back into devel, for whatever release is there to come. Changing dependencies is not a breaking change (in contrast to changing level file format or such things), so we can do this anytime, without having to wait for a major releases if we don’t find that useful.

Valete, Quintus

[brianvanderburg2]

I don't really know much about graphics programming, OpenGL, bullet, or other systems. I've read some tutorials on OpenGL programming, but most of them have focused on using glRotate/etc. Are there any good cross-platform (and preferably open source) tools for GLSL? I mess around here and there, but have never engaged in anything quite as comprehensive as this project.

Even the way game_core works could be refactored, for instance to use objects for game actions:

class cGame_Action_Base { virtual void Execute( ); }
class cGame_Action_Load_Level public cGame_Action_Base { ... }
class cGame_Action_This : public cGame_Action_Base { ... }
class cGame_Action_That : public cGame_Action_Base { ... }
...
begin_action.Add(new cGame_Action_Load_Level(...));
middle_action.Add(...);
end_action.Add(...);

I remember viewing some code for a game once that used the idea of screens and a screen manager. Instead of having game modes (MODE_MENU, MODE_LEVEL, etc), there existed as screen stack, and all input/updates went to the currently active screen. A screen could call the manage to add a new screen to the stack to become the next screen, end the current screen off the stack, or replace the current screen with another screen. Something like this:

class Screen
{
public:
    virtual bool Handle_Input ( );
    virtual bool Update( );
    virtual bool Draw( Surface* s);
};

class TransitionScreen : public Screen
{
public:
    virtual bool IsFinished();
};

class ScreenManager
{
public:
    void Push(Screen* s, TransitionScreen* t = NULL);
    void Pop(TransitionScreen* t = NULL);
    void Replace(Screen* s, TransitionScreen* t = NULL);

    Screen* GetActiveScreen();

private:
    std::vector<Screen*> m_screens;
    std::vector<Screen*> m_pending_delete;
    TransitionScreen* m_transition; 

    Screen* m_active_screen;
    TransitionScreen* m_active_transition;
};

Going to a level from a world would simple create a level screen and push it onto the stack. The level screen may contain a level manager for loading multiple levels that are used during the play of the level, and when finished, would return to the world screen.

The game code itself would look like:

void RunGame()
{
   // Do setup
   ...

   // Create the main screen and run the loop
   g_screens.Push(new GameScreen());
   while(Screen* scr = g_screens.GetActiveScreen())
   {
      scr->HandleInput();
      scr->Update();
      scr->Draw(surface);
   }

   // Do cleanup and exit
}

To a certain extent I wonder if it would be easier to rewrite the code using the existing code as a guide and making changes where needed than it would be to refactor here and there.

In the past, I even wondered about going to a total scripting system. I've seen some games that use PyGame that seem to work quite well. There is even a complicated 3D project (MakeHuman) that is coded mostly in Python and just uses custom extensions for some of the grunt work (actually now I think it just uses PyOpenGL). Could a core library be developed that would provide the grunt of the calculating support where needed, and then scripting be used for the rest? This is probably a bad idea though.

[datahead8888]

 I've read some tutorials on OpenGL programming, but most of them have focused on using glRotate/etc.

Unfortunately glRotate is deprecated and may not continue to function in the future. I was pretty ticked off at first when I found this out. The new GLSL way is more powerful, but it's a lot harder to get it to work.

@brianvanderburg2, did you help code the particle systems? I had thought you did for a while, but what I saw may actually have been a note saying you made particle systems accessible in levels.

 In the past, I even wondered about going to a total scripting system. I've seen some games that use PyGame that seem to work quite well. There is even a complicated 3D project (MakeHuman) that is coded mostly in Python and just uses custom extensions for some of the grunt work (actually now I think it just uses PyOpenGL). Could a core library be developed that would provide the grunt of the calculating support where needed, and then scripting be used for the rest? This is probably a bad idea though.

This actually is the ultimate interpretation of both "not reinventing the wheel" and making everything modifiable through scripting. C++ is useful for performance, easy access to low level C api's, and for systems programming. If you don't need one of those 3 items, you don't necessarily have to have C++. (It is expressive in some other ways, but it still has a learning curve). Thus if the decision is made to use libraries for all physics, rendering, image processing, etc, it's equally worthwhile to ask if C++ is needed. Likewise when implemented through Python or Ruby, everything is truly modifiable through scripting.

I'll be really honest, though...if SMC moves toward being a Python/Ruby game, I'll probably lose interest in developing it. This is a decision to be made by the team as a whole, though.

[Luiji]

BSP is designed for static games, and is absolutely terrible at handling dynamically movable items. This means that we would have to differentiate between static and movable objects, which reduces the capabilities of scripting.

If we manually implemented a collision detection algorithm, it would be much more effective to use dynamic quad-trees which would prevent any reduction in flexibility and still provides really good performance. Many newer games are opting for octrees (the 3-D equivalent) over BSP for this reason as well.

[brianvanderburg2]

I don't remember if I did all the particle emitter stuff or just made it available. The patch I did is at the discussion forum: http://www.secretmaryo.org/phpBB3/viewtopic.php?f=6&t=1082

I don't know if I would like SMC as a total scripted game with a core binary library. I love Python, but it still has issues. The global interpreter lock is one I hear about a lot, but also garbage collection at an inconvenient time may cause a noticeable pause.. I'm not aware about the workings of Ruby. There are other scripting engines out there as well. AngelScript is actually a statically typed scripting engine designed for C++, with a similar syntax.

For collisions, this link discusses quad trees vs a grid: http://www.java-gaming.org/index.php?topic=27858.0 I remember in the past I proposed a grid for collision detection, breaking the level into fixed-size grids. An item may span multiple grids if it is large or on the grid boundary. If so, then that item would be in both grids. When doing collisions, it would go through each grid, and for each item in that grid, test each other item in that grid. When an item's position changes, it would compute the new grid cells, the old grid cells, and make the changes as needed. I think Fluxy wanted to use BSP. A problem may be, if multiple items are in the same sets of multiple cells, then two different items may test collisions with each other more than once.

[Quintus]

I don’t think converting SMC into a core binary with everything else written in a scripting language is a good idea. It would mean rewriting SMC from the ground up. mruby also misses Ruby’s standard library and RubyGems, which would be required if you really wanted to code most part of SMC in Ruby code; at this point we would arrive at a point where we effectively could use plain old original Ruby and have some core stuff done with C extensions. However, original Ruby is not compiled and it would users require to install a Ruby interpreter before being able to run SMC.

From a performance point of view, mruby is only slightly slower als Lua.

For the graphics stuff, I silently follow your discussion. I’ve no experience with this.

Vale, Quintus

[Quintus]

And as for grids: SMC should not be forced into a grid I think. With pixel granularity you have some nice level design opportunities, e.g. holes than can be passed by furballs (which are very small), but not by Maryo.

Vale, Quintus

[Quintus]

Superseded by #105.