I slight handy faq for those who care at all of this engine:
Q: Are you working on the engine? There's no updates!
A: YES. I am. I'm currently going through some personal stuff.
Q: Why haven't you updated!?
A: Because there's still nothing really interesting happened.
Q: What's "AGE"?
A: Acronym for Autumn Graphics Engine. Engine used for game development.
Q: I've heard stories of "AGEs", what's that?
A: Acronym for Autumn Graphics Engine subversion. Used when the engine structure is extended and/or modified to fit game's needs. Normally subversions have their own codename.
Q: What's the current status of AGE?
A: Lighting and textures are implemented, still fighting with spotlights.
Q: What will you do next?
A: Material pipeline.
Q: Why should I give a crap of this engine?
A: It's versatile, extendable, modifiable and absolutely not overgeneric free engine with LUA, XML and Python scripting support. Comes with full source.
Q: Why both LUA and Python?
A: I'm not sure yet which one I will use as primary. Both have their pros and cons.
Q: Xml?
A: XML yes. Used for materials and some other features I will explain later.
Extra, extra!
Q: Why are the updates so slow!?
A: Because I'm currently attending military. It swallows 71.43% of my free time.
June 5, 2009
May 11, 2009
NEW Milestones
Milestone I (updated):
Rewrite everything and add threading support, so it adds more speed to multicore systems.
So.. I had to do alot of rewriting to get this done. Currently, AGE uses one thread per node, so actions of nodes (cameras, entities, lights, yes even lights) have a thread if it has a action.
So in larger systems engine may use up to 12000 threads, if the designer hasn't thought of one little detail.
Scenes can have an action too. Scenes, in essence are just and simply containers for nodes. These nodes represent a scene, or level if you prefer, in the game world. Scene actions are used to control the global level events and nodes. You can disable, hide, show, move, whatever any node. This is impractal for some events, but helps alot to narrow down the number of threads running.
Currently this milestone is achieved, and I'm working on materials.
I would love to show you a screenshot, but I'm not home at the moment (and don't have my memory stick with me), so please cope with me for few more days and I'll update next week with a textured scene (or spheres + complex models if I'm lazy and won't work out the scene file format).
Milestone II:
Materials materials materials.
So, the materials pipeline, which means I will also have the need to write compatibilty system too.
Materials.. I will explain the pipeline when it's fully designed and tested to work. Now I will rant about some of the features in my compatibility system:
struct ageCompatibilty;
Compatibility is an important feature of any engine hoping to survive the PC. Even if a engine works in my computer, it doesn't mean it will work with the exact same setting on yours.
That's why ageCompatibility is an important feature. It lists all the features of target pc. OpenGL level, texel fillrate, max texture size... Name it, and it probably is in the compatibility system. This struct is mandatory for the material pipeline when choosing which shaders can be displayed (take an example of pc which does not support floating point 16 bit texture value. This means that this pc is unable to process HDR rendering).
struct ageLevels;
Levels. We all know the games that have the "settings" in their menu. This 'little' struct is used to determine WHAT and HOW things will be done in MAX settings. So even if you hit the Ultra-level for the texture size, it doesn't mean all textures are 2048x2048. No. It means that it's the max. The developer using the engine must provide the data supporting the settings. Some games never use higher than 512x512 textures. So the Ultra or High setting is useless.
For this, the developer may change the level descriptions and assigns. default values for texture size are:
none - 0x0
low - 256x256
med - 512x512
high 1024x1024
ultra 2048x2048
but the developer may find high/ultra useless, so he changes the values to:
none - 0x0
low - 64x64
med - 128x128
high - 256x256
ultra - 512x512
or just to
none - 0x0
low - 256x256
med - 512x512
high - 512x512
ultra - 512x512
which means, that 512x512 is the maximum texture size rendered regardless what setting is used.
Enough of ranting about useless features and back to dev ->
Rewrite everything and add threading support, so it adds more speed to multicore systems.
So.. I had to do alot of rewriting to get this done. Currently, AGE uses one thread per node, so actions of nodes (cameras, entities, lights, yes even lights) have a thread if it has a action.
So in larger systems engine may use up to 12000 threads, if the designer hasn't thought of one little detail.
Scenes can have an action too. Scenes, in essence are just and simply containers for nodes. These nodes represent a scene, or level if you prefer, in the game world. Scene actions are used to control the global level events and nodes. You can disable, hide, show, move, whatever any node. This is impractal for some events, but helps alot to narrow down the number of threads running.
Currently this milestone is achieved, and I'm working on materials.
I would love to show you a screenshot, but I'm not home at the moment (and don't have my memory stick with me), so please cope with me for few more days and I'll update next week with a textured scene (or spheres + complex models if I'm lazy and won't work out the scene file format).
Milestone II:
Materials materials materials.
So, the materials pipeline, which means I will also have the need to write compatibilty system too.
Materials.. I will explain the pipeline when it's fully designed and tested to work. Now I will rant about some of the features in my compatibility system:
struct ageCompatibilty;
Compatibility is an important feature of any engine hoping to survive the PC. Even if a engine works in my computer, it doesn't mean it will work with the exact same setting on yours.
That's why ageCompatibility is an important feature. It lists all the features of target pc. OpenGL level, texel fillrate, max texture size... Name it, and it probably is in the compatibility system. This struct is mandatory for the material pipeline when choosing which shaders can be displayed (take an example of pc which does not support floating point 16 bit texture value. This means that this pc is unable to process HDR rendering).
struct ageLevels;
Levels. We all know the games that have the "settings" in their menu. This 'little' struct is used to determine WHAT and HOW things will be done in MAX settings. So even if you hit the Ultra-level for the texture size, it doesn't mean all textures are 2048x2048. No. It means that it's the max. The developer using the engine must provide the data supporting the settings. Some games never use higher than 512x512 textures. So the Ultra or High setting is useless.
For this, the developer may change the level descriptions and assigns. default values for texture size are:
none - 0x0
low - 256x256
med - 512x512
high 1024x1024
ultra 2048x2048
but the developer may find high/ultra useless, so he changes the values to:
none - 0x0
low - 64x64
med - 128x128
high - 256x256
ultra - 512x512
or just to
none - 0x0
low - 256x256
med - 512x512
high - 512x512
ultra - 512x512
which means, that 512x512 is the maximum texture size rendered regardless what setting is used.
Enough of ranting about useless features and back to dev ->
April 23, 2009
Kittens 2
I'm sorry I still haven't posted anything
I'm still working on making the threading system even more agile and work with me like it should.
I already have some type of python binding ready, still gotta make some improvements there, so I have scenes ^^
Soon. Soon you will get the first sphere/complex mesh renderings. (I will try to get million polygon mesh, or something similar for benchmarking).
Update: I have everything "ready" now I need to do some integrational shit (Adjust system and apply new stuff and edit code moar). I would've updated days ago, but my OS-reinstallation didn't go so.. smoothly.
I'm still working on making the threading system even more agile and work with me like it should.
I already have some type of python binding ready, still gotta make some improvements there, so I have scenes ^^
Soon. Soon you will get the first sphere/complex mesh renderings. (I will try to get million polygon mesh, or something similar for benchmarking).
Update: I have everything "ready" now I need to do some integrational shit (Adjust system and apply new stuff and edit code moar). I would've updated days ago, but my OS-reinstallation didn't go so.. smoothly.
April 8, 2009
Kittens.
This should be in a way in babysteps, but I rather not dirty it.
I decided to change early on the design to be multithreading-friendly. This means pretty radical changes in some parts so if you can forgive me for delaying next "chapter" for few weeks and I'll probably be able to provide some screenshots too.
Most likely spheres. At least one.
I decided to change early on the design to be multithreading-friendly. This means pretty radical changes in some parts so if you can forgive me for delaying next "chapter" for few weeks and I'll probably be able to provide some screenshots too.
Most likely spheres. At least one.
April 7, 2009
Milestone I & II
As I wrote, I'll start a series that tell about the progress of AGE. Each article describes the Milestones in question, sample usage code/script and perhaps some screen shots. Be aware of the fact the first ones will look lame, simple and just are meant for educational purposes only.
Milestone I
Description:
Basic Core functions (Windowing, renderer, wrapper) and Camera projection system.
The "original" AGE is written in C++ using Microsoft® Windows® API and Open Graphics Library (OpenGL). These two API's are split to their own files, so if someone whines about no DX10.1 support, he can write himself by opening the Renderer.cpp and edit the namespace (age::renderer) functions. Same for the OS-specific stuff, Windows API related code is in Window.cpp file, where unrelatedly most other functions are implemented too.
The first milestone was to implement a way to communicate between OS and API without having the user to write ANY API-specific lines and create projection system through so called Cameras.
Put simply, currently you can create simple scene with window and camera by using following code in the main file:
The camera "set" function is long, because user sets all camera specific values to it. I could've also set all of them one by one by setPos, setRot, etc. or setProjectionPos and setWorldPos functions that take projection specific values and world positioning specific values respectively.
Milestone II
Description: Input
So in all simplicity, the second milestone is to implement inputting system. Currently I'm on my way to implement and test Xinput gamepad support. I also made (from boredom) structures that include PlayStation, PlayStation 3, Xbox, Xbox 360 and Generic pads. I didn't remember to make one for Wii controller, since it works a bit differently and I'd have to actually use time to find out an SDK for reference.
Input a class so you have to call
I didn't include any shots now, since I'm sure everyone can imagine rotating test triangle in a window.
Milestone I
Description:
Basic Core functions (Windowing, renderer, wrapper) and Camera projection system.
The "original" AGE is written in C++ using Microsoft® Windows® API and Open Graphics Library (OpenGL). These two API's are split to their own files, so if someone whines about no DX10.1 support, he can write himself by opening the Renderer.cpp and edit the namespace (age::renderer) functions. Same for the OS-specific stuff, Windows API related code is in Window.cpp file, where unrelatedly most other functions are implemented too.
The first milestone was to implement a way to communicate between OS and API without having the user to write ANY API-specific lines and create projection system through so called Cameras.
Put simply, currently you can create simple scene with window and camera by using following code in the main file:
#include "../inc/age.h"
using namespace age;
int main()
{
Driver* d = new Driver();
d->initDriver("Engine!", 640, 480);
ageid camera = d->addCamera();
// Viewport position, viewport size, clip near and far,
// FOV, position, rotation and bg color.
d->getCamera(camera)->set(Vec2s(0,0), Vec2s(150, 150),
Vec2f(0.1, 1000.0), 45.0,
Vec3f(0,0,200), Eul(0,0,0),
Vec4f(0.1, 0.0, 0.2, 1.0));
while(!d->getDone())
{
d->mainLoop();
}
return d->end();
}
The camera "set" function is long, because user sets all camera specific values to it. I could've also set all of them one by one by setPos, setRot, etc. or setProjectionPos and setWorldPos functions that take projection specific values and world positioning specific values respectively.
Milestone II
Description: Input
So in all simplicity, the second milestone is to implement inputting system. Currently I'm on my way to implement and test Xinput gamepad support. I also made (from boredom) structures that include PlayStation, PlayStation 3, Xbox, Xbox 360 and Generic pads. I didn't remember to make one for Wii controller, since it works a bit differently and I'd have to actually use time to find out an SDK for reference.
Input a class so you have to call
input->keys[KEY_A]to check if 'A' is pressed. I might simplify it even further by merging it into Driver. Who knows.
I didn't include any shots now, since I'm sure everyone can imagine rotating test triangle in a window.
April 3, 2009
More on engine
I noticed that I hadn't done proper planning on the file system, so it kind of blew on me. I need to do some reprogramming (thanks to my "go with the guts"-style) on the engine design in general..
I'll update when I'll get this solved. I blame logic.
I'll start new "series" here too, The Babysteps of Engine, which reports the progress in detail. First chapter next week.
I'll update when I'll get this solved. I blame logic.
I'll start new "series" here too, The Babysteps of Engine, which reports the progress in detail. First chapter next week.
March 26, 2009
Autumn is coming!
I've been working on a game engine from scratch that I will later on use to make games with the workflow I've been dreaming of: Blender for everything, meaning that I will be able to do the scenes in Blender and use export button to create game content.
Of course I will have to make game-specific editors such as content creator and level editor not level designer.
I've got the general structure done and hopefully end of next month will be the date of releasing first videos of ingame scenes (probably crappy ones, but scenes anyways).
What I hope to get from this engine, is ultimate control over the game world. I will rant about game scripting in C++.
Expect more than this type of screens:
Of course I will have to make game-specific editors such as content creator and level editor not level designer.
I've got the general structure done and hopefully end of next month will be the date of releasing first videos of ingame scenes (probably crappy ones, but scenes anyways).
What I hope to get from this engine, is ultimate control over the game world. I will rant about game scripting in C++.
Expect more than this type of screens:
Subscribe to:
Posts (Atom)