[Gen]

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.

This post has been edited by Gen: 14 April 2012 - 06:55 PM
Reason for edit: Update on smart pointer class and GL context creation + windowing.

[Gen]

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:

class MEOpenGLContextMgr {
    std::vector<GLContextID> contexts;
public:
    MEOpenGLContextMgr();
    MEOpenGLContextMgr(GLContextID ID);
    MEOpenGLContextMgr(GLContextAttribs attribs, GLContextID ID);
    ~MEOpenGLContextMgr();
    
    void CreateContext(GLContextID ID);
    void CreateContext(GLContextAttribs attribs, GLContextID ID);
    void DeleteContext(GLContextID ID);
private:
    void DeleteAllContexts();
};

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 NSOpenGLContext contexts and IDs in an NSMutableDictionary. On Windows we'll likely store them in a map, containing the ID and HGLRC context.

This post has been edited by Gen: 11 March 2012 - 08:17 PM

[StreakThunderstorm]

I like that you're keeping this transparent. Most other projects aren't like this.

[Gen]

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.

This post has been edited by Gen: 14 April 2012 - 06:49 PM

[Aerosol]

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?

[Gen]

AerosolSP, on 25 April 2012 - 12:08 AM, said:

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?

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.

This post has been edited by Gen: 25 April 2012 - 10:19 PM

[Aerosol]

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.

[Gen]

AerosolSP, on 25 April 2012 - 10:39 PM, said:

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.

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.

This post has been edited by Gen: 25 April 2012 - 11:36 PM

[Aerosol]

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.

[winterhell]

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

[Sofox]

I'm a Linux user, so I'll be able to test it on that platform, specifically Ubuntu 12.04.

[Kharen]

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.

[TheInvisibleSun]

Kharen, on 20 August 2012 - 01:37 AM, said:

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.

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.

[Sofox]

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.or...ius-game-engine

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

This post has been edited by Sofox: 25 November 2012 - 06:19 PM

[Sofox]

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.