Sonic and Sega Retro Message Board: Gen - Viewing Profile - Sonic and Sega Retro Message Board

To help better understand the needs of the community, I'd like to get a discussion started regarding a demonstration game to showcase what the engine can do. Consider this a sort of "choose your adventure" style thread.

This will not be a full fledged game, just a playable demo for users to better grasp what the engine is capable of.

Things worth talking about:
What would make the demo look pretty?
What hardware should it be targeted for?
What gameplay style should it follow?
How can we showcase specific feature sets with this demo?

Things not worth talking about:
How many zones should it have?
Should it feature special stages?
Which of Sonic's friends should be featured in the game?

The good points about having a demo, is not only does it show what users can do with the engine, but also provides a small pool of example content for users to look at and help them build their own games with the engine.

In terms of levels, there should be at most one zone with at least a single act.

To get things rolling, let's start off with a gameplay style question: 2.5D or 3D?

I have maybe a week before I'll be busy again with the general flow of work, so let's keep the ball rolling by starting a discussion regarding memory management.

Now, before we can have a general resource manager, we need a means to manage memory. Smart pointers is a good start on this, however we may want to access things from a pool at times, or store different objects or even individual attributes in containers in memory for access later on for the purposes of caching different assets at runtime (like, say, virtual texturing where we would have many smaller tiles loaded into memory that are then pushed into VRAM when they're needed).

So here's an initial proposal.

As it stands, we now have smart pointers with reference counting. We should automatically delete most objects once their reference count reaches zero, since a lot of objects we don't want to keep in memory at all times. There can be exceptions though, for things like cached data.

One idea would be to store all objects in unique pools for different purposes, using MEPointer as an interface to add and remove things from the pool. Each pool could be allocated at the global scope, either as a static member of a class or as a global variable, with MEPointer taking an optional additional parameter in its constructor for what memory pool the pointer should be allocated in. It could work something like this:

MEMemPool gBadnikPool;
void MEBadnik::newBadnik(MEModel &badnikModel)
{
    MEPointer<MEBadnik> badnik = new MEPointer<MEBadnik>(gBadnikPool); // Allocate our new badnik in the global badnik memory pool
    badnik->mModel = badnikModel;
}

void MEBadnik::killBadnik(long poolLocation)
{
    gBadnikPool.destroyAt(poolLocation); // Assume gBadnikPool will call our deconstructor for MEBadnik, thus deallocating the badnik at this specific location in the pool, and dereferencing its model asset.
}

There's several other means of managing memory here, and how this could potentially interface with the memory manager.

I'm hereby opening the floor to discussion with regards to how the memory manager should be designed and implemented. Do note that the memory manager will mostly be used for caching different data, helping to instance assets that have already been loaded into memory.

Hey everyone!

I know it's been fairly quiet around these parts, but fret not! The project isn't dead (yet)!

Today, we'll start figuring out what to do regarding the low level engine architecture. This level of the engine's architecture should factor in different systems that the higher levels of the engine will be built upon.

To get things moving, I'll put forth a few perceived needs for the low level architecture. Please feel free to criticize these, as none of them are written in stone.

Memory Manager
Thread Manager (could just use Intel Thread Building Blocks here to assist with this)
Input Manager (could just use SDL)
Sound Manager (could just use SDL)
I/O Manager
Graphics Manager (parts could just use SDL for context creation and management, others would probably need to be written from scratch; note this is not the actual renderer, just the low level bits we need for a renderer)
Math Library (there's many other projects that can be used for this)

Threading can be handled in many ways, but also could be considered optional for an initial pre-alpha. It would be nice however, to have the vast majority of the engine built with thread safety in mind.

If you feel I've left something out, or feel that one system may not be necessary, by all means feel free to comment below. We'll also need to come up with designs for these systems to define an ideal means in which they should work, and further help with the progress of the 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.

It was close, but our winner is LocalH's variation of the logo:


Original Post:
While I'm busy working on getting some initial groundwork done for the engine, let's get some ideas for logos going!

All ideas are fair game, bonus points if you have examples of design styles you feel would be best suited for the project. Even more points if you can visualize an idea on your own!

After enough ideas have been submitted (we'll go for 5 as the minimum here), we'll hold a vote to determine whose we should use.