General Progress Thread

Discussion in 'Mobius Engine Project' started by Gen, Mar 11, 2012.

  1. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    This thread is intended to be used to document the overall progress of the project for the community's discussion.

    Contributors are encouraged to post updates on what they're working on for the project by posting to this thread. Please keep update posts to things that are actually in the process of being implemented, or have finished being implemented. Also, please keep community discussion light in this thread, to keep clutter to a minimum. If you feel that you need to discuss an update at length, there's always the option of posting a new thread.

    Updates may include things such as implementation details, to design goals, and other relevant details regarding the development of a feature, or a particular piece of functionality in the core engine.

    This post will be updated with summaries of changes to consolidate major changes through the engine's development.

    March 10th, 2012:
    Work has begun on implementing a C++ interface for OpenGL context creation and management.

    April 14th, 2012:
    A smart pointer class with reference counting has been committed to the repo. (you can consider this to be the engine's first proper code)
    C++ interface for OpenGL context creation has been scrapped, working around with the GLFW library for windowing, GL context creation, and likely input as well.
     
  2. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    I've started work on a cross platform OpenGL context manager, that can create and destroy OpenGL contexts of varying definitions.

    Each OpenGL context has an ID and a set of attributes associated with it; though for reasons of management, we mostly just care about the ID. The C++ abstraction basically maps to whatever OS-specific means of creating contexts is. For the time being, each OS will have its own implementation of an internal manager that tracks the context with a specified ID.

    Eventually the abstracted API can probably be reworked to just use SDL 1.3 or 2.0 to reduce the burden of having to maintain platform specific implementations of the context manager.

    Currently, the interface looks like this:
    Code (Text):
    1. class MEOpenGLContextMgr {
    2.     std::vector<GLContextID> contexts;
    3. public:
    4.     MEOpenGLContextMgr();
    5.     MEOpenGLContextMgr(GLContextID ID);
    6.     MEOpenGLContextMgr(GLContextAttribs attribs, GLContextID ID);
    7.     ~MEOpenGLContextMgr();
    8.    
    9.     void CreateContext(GLContextID ID);
    10.     void CreateContext(GLContextAttribs attribs, GLContextID ID);
    11.     void DeleteContext(GLContextID ID);
    12. private:
    13.     void DeleteAllContexts();
    14. };
    Where GLContextID is of type const char *, and GLContextAttribs is a struct containing various context attributes (profile version, color bit depth, depth bit depth, etc.). contexts contains a list of context IDs that we're tracking. Any time a context is created, it's added to contexts, and added to the OS specific internal manager as well. The same goes for the deletion of contexts.

    On OS X we store our [font="'Courier New"]NSOpenGLContext[/font] contexts and IDs in an [font="'Courier New"]NSMutableDictionary[/font]. On Windows we'll likely store them in a map, containing the ID and HGLRC context.
     
  3. StreakThunderstorm

    StreakThunderstorm

    Member Member
    216
    0
    0
    Mecha Madness
    I like that you're keeping this transparent. Most other projects aren't like this.
     
  4. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    After a severe lack of progress (and time on my part), I've finally decided to start contributing different utility classes into the bitbucket repository.

    Today's update comes two fold: a smart pointer class with reference counting, and work beginning on windowing and OpenGL context creation through GLFW.

    The code for the engine's pointer and reference counting classes can be found here:
    MERefCount.h at version f4d714f5e4d4
    MEPointer.h at version f4d714f5e4d4

    These will both likely change significantly as the memory manager is implemented, and threading is implemented as well.
     
  5. Aerosol

    Aerosol

    FML and FU2 Member
    10,245
    1
    16
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    It's interesting that OSX is the main platform here, with Windows and Linux versions being ports. Are all the versions going to be developed concurrently? Or are we going to run into a situation where Mobius on OSX is at version 5 and the other versions are stuck at 3.0.2 or something?
     
  6. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    OS X is the current target, since it's my current OS of choice*. There's no other reason than that.

    Ideally all versions will be developed concurrently as we progress.

    * In otherwords, I don't really feel like booting up Windows or Linux right now to sort out development for those platforms.
     
  7. Aerosol

    Aerosol

    FML and FU2 Member
    10,245
    1
    16
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    Ideally, huh? I really don't want Mobius to hit any speedbumps towards getting a dedicated userbase because the only version with the features people want to use is for an OS that hardly any of us use. I trust you though, Gen. I'm sure you'll sort it out.
     
  8. Gen

    Gen

    This is halloween! This is halloween! Member
    309
    0
    0
    The Mobius Engine
    This is why we'll be using as many cross platform frameworks as possible, and probably CMake as well to make generating up to date build files on the fly with zero effort on any programmer's behalf (outside of maybe running cmake -G "SupportedIDEHere") possible. Really, the overall hope here will be that the only thing required to make the engine work on another platform is literally just building it.
     
  9. Aerosol

    Aerosol

    FML and FU2 Member
    10,245
    1
    16
    Not where I want to be.
    Sonic (?): Coming summer of 2055...?
    Fascinating. I almost have no idea what you're talking about due to having no clue how cmake and the like work (don't explain it, my head will blow up), but like I said, I trust you Gen. I understand enough.
     
  10. winterhell

    winterhell

    Member Member
    1,160
    0
    16
    I'll assist in testing and possibly porting for Windows as I'm too interested in the project but do not use Linux or OSX
     
  11. Sofox

    Sofox

    Member Member
    I'm a Linux user, so I'll be able to test it on that platform, specifically Ubuntu 12.04.
     
  12. Is it possible to get a sort of progress report on this? It's not that I'm just wanting an update to harass you, but I want to know what point you're at for suggestions. I recently (as in, downloaded it yesterday) started trying to figure out Google SketchUp, having heard that it's supposed to be incredibly easy to use, and it gave me a lot of thoughts about this engine that I wanted to share and ask about. However, if progress is at the point where the general idea is already set in stone, then I don't want to waste anybody's time.
     
  13. TheInvisibleSun

    TheInvisibleSun

    OVER THE TOP TECHNO-BLAST Member
    1,409
    0
    16
    Buffalo, NY, USA
    Sonic 1 Color Contrast
    From my experience with the program over the years, (in the field of Architecture) Google Sketchup is a pretty decent program for most simple modeling when it comes to user-friendly-ness. However, the problem with Sketchup is that certain degree of accuracy and depth is somewhat lost and sacraficed for said user-friendlyness (I.e. hollow 3d shapes anyone). This can be slightly averted by importing mathematically perfect drawings/models from AutoCAD or 3DSMAX, and working from there, but even more problems can arise in that process. Though it is very easy to use, there are certain more complicated, higher level things that are ludicrously difficult and frustrating to do in Sketchup, that would be much easier, or even only take a few minutes in MAX, AutoCAD or any other modeling program. (Trying to model things like Sonic characters would probably be insanely difficult to pull off in Sketchup) Another good thing about Sketchup is its great capability to render well, rather easily (using the appropriate plugins, like VRay or Maxwell), without worrying about a plethora of settings *looks at 3DSMAX*. Things like sunlight, shadows and global location are handled within the actual model and not the renderer, and can be visibly manipulated while you are working on the actual model.

    Personally, I like using Sketchup (I have even used it to create professional presentation models for my firm), but if it is used, it must be used wisely and carefully.
     
  14. Sofox

    Sofox

    Member Member
    Looks like I'll be posting here regularly now...

    Further to my previous work, I've updated the game code so now you can navigate around a simple 3d environment. It's a 3d "Hello World", but I've already taken some steps to keep the code organised and readable in a "start the way you mean to go on" philosophy, though more is probably needed since the idea is that this engine will be used by other people. Also added BUILD and LICENSE files.

    As for what to work on now, I'm deciding between implementing movement physics, or adding asset importing (COLLADA importing would be helpful). Any feedback on which one I should go for will be taken into account, and if anyone wants to help out with the coding that would be greatly appreciated (either reply or PM me). Indeed, ideas on art and design would be good to get a better idea on what the engine will need to do.

    All the code has been pushed to the new BitBucket repository: https://bitbucket.org/Sofox/mobius-game-engine

    License has yet to be determined, but I'll use MIT if I don't hear opposition soon.
     
  15. Sofox

    Sofox

    Member Member
    Made an update to the source so that now the "character" moves along with the camera (it's a blue rectangle, but gotta start somewhere!). Changes pushed to repository.
     
  16. Sofox

    Sofox

    Member Member
    Added basic rotation of the character, changes pushed to repository.

    Next up, orbiting camera.

    While I'm working the controls out, my short term aim is Max Payne style controls (FPS controls with a 3rd person perspective on the camera), then we can develop into more 3d platformer style controls.
     
  17. Relick

    Relick

    Member Member
    197
    0
    0
    England
    C++/DX10 Engine (not sonic related)
    Don't know if you have figured this out yet, but here is a trig solution (I assume a matrix option would be better, though):

    Assuming we know the rotation (this will be generated through the engine/changed using the mouse)

    Code (Text):
    1.         float x = 0;
    2.         float y = 0;
    3.         float z = 0;
    4.         float distance = me_character.camDistance;
    5.         float xA = cam.rotation.eulerAngles.x;
    6.         float yA = cam.rotation.eulerAngles.y;
    7.  
    8.         x = -Mathf.Sin(yA) * Mathf.Cos(xA);
    9.         y = Mathf.Sin(xA);
    10.         z = -Mathf.Cos(yA) * Mathf.Cos(xA);
    11.  
    12.         cam.position = new Vector3(x, y, z)  * distance;
    13.         cam.position += me_character.position
    I'm not sure how OpenGL handles angles so that is using standard Euler angles and some of the negation might have tp be changed but its obvious where I'm getting at.

    EDIT: Fixed it again :P
     
  18. winterhell

    winterhell

    Member Member
    1,160
    0
    16
    Using matrices would definitely be cleaner approach, though the resulting outcome is the same.
    Btw you should be wary of the way the axises work in OpenGL(and DirectX for that matter). Y is UP, despite what many people may tell you. They just artificially swap the letters for Z and Y in the 3D modelling programs because if Z is UP then some things are not possible, like doing a barrel roll with the camera. So when you load a model you may need to switch them, and maybe even negate one of them due to using left or right handed angles.
     
  19. Relick

    Relick

    Member Member
    197
    0
    0
    England
    C++/DX10 Engine (not sonic related)
    I've always assumed Y to be up and all those 3D programs to be wrong :P. That method works for y = up.

    EDIT: Or rather, y = pitch = up
     
  20. Sofox

    Sofox

    Member Member
    Alright, I've added the camera orbiting, a few more items to the area to populate the scene a bit more, and did a bit more code cleanup. Changes pushed.

    Relick & winterhell: Yes, I think that Matrices would be better for handling rotation, but truth is I'm a little rusty on matrix rotation, so I wanted to just get it working with minimal hassle. I'll probably revise it at a more appropriate time.

    Relick: Currently, glRotatef handles it so that the first parameter gives the degrees of rotation (in degrees), and the following 3 parameters describe the axis that the rotation is meant to be around.

    Basic movement is now done, time to work on basic physics. Time for researching and implementing collision detection.