As I don't have anything else to rant about, I will give quickish update about the status of the engine as of now.
Engine supports fully Python, and there aren't (atm) any found bugs. I'm in the middle of writing PAK file format for AGE, that, in all simplicity, works as a package, both crypted and packed, if so wanted. Currently it is designed to hold data for camera, entity, mesh, image, material, worldnode, light and shader. I also plan on adding the support for scripts later.
My COULDHAS is also been expanded with possible editor. It'd work as better management for engine data, and easier "export" of PAKs, as it's pretty hard to do directly from blender. Not impossible, but hard and complicated.
EDIT: I'm currently working on the Blender exporter. It's more easier than I thought.
Compatibility settings are still on the shelf, with only parts of it in use. I found it more important to program major features before making sure it's completely bug free and compatible with other machines. I will probably add the system before initial beta release to the wild, which should, by current plans, happen in three, four weeks. Before the release, I will try to upload a few videos and give complete list of features implemented and a little tutorial for fly through level.
April 22, 2010
April 11, 2010
Scripting AGE
AGE supports currently Python scripts. This means it gives you more rapid development cycles when you don't need to rebuild your c/#/++ project all over again.
Currently the system is as follows:
You make main.py that includes, at minimum, following lines:
That's it.
Then, if you want to add items, like camera, you add following lines after age.Driver.initEngine:
Then you need to create a new file, called camera.py that includes following lines to enable fly through:
Not so hard, but alot code to take in at once.
The "def on_update()" is a function that is called automagically inside the engine. You can also create your own, but you have to call them inside one of the predefined, automatically called functions.
Currently the system is as follows:
You make main.py that includes, at minimum, following lines:
# Import age library
import age
# Initialize AGE, give it title "AGE" and set
# window size to 768x480
age.Driver.initEngine("AGE", 768, 480)
# Loop driver update cycles as long as the engine
# is not "done" with the rendering
while not age.Driver.isDone()
age.Driver.update()
That's it.
Then, if you want to add items, like camera, you add following lines after age.Driver.initEngine:
# Create new scene, set it active and get it
curScene = age.Driver.getScene(age.Driver.addScene('Scene001', 1))
# Add a camera to our scene and make it active
cam = curScene.getCamera(curScene.addCamera('Cam001', 1))
cam.set( age.Vec3f(0.0, 0.0, 0.0), # Position
age.Eul(0.0, 0.0, 0.0), # Rotation
age.Vec2s(0.0, 0.0), # Viewport offset
age.Vec2s(768, 480), # Viewport size
age.Vec2f(1.0, 1000.0), # Clip distances
45.0) # FOV
# Set the script file camera uses, without the extension (.py)
cam.setPyScript("camera")
Then you need to create a new file, called camera.py that includes following lines to enable fly through:
import age
# Get the camera as global variable
me = age.Driver.getCamera("Scene001", "Cam001")
# Camera action
def on_update():
# Check if WASD or gamepad's Point Of View (Directional btns)
# are pressed and move accordingly
if age.Input.getKey(age.KEY_W) == 1 \
or age.Input.getPadBtn(0, age.BTN_POV_UP) == 1:
me.moveOriented(age.Vec3f(0.0, 0.0, -10*age.Driver.getStep()))
if age.Input.getKey(age.KEY_S) == 1 \
or age.Input.getPadBtn(0, age.BTN_POV_DOWN) == 1:
me.moveOriented(age.Vec3f(0.0, 0.0, 10*age.Driver.getStep()))
if age.Input.getKey(age.KEY_A) == 1 \
or age.Input.getPadBtn(0, age.BTN_POV_LEFT) == 1:
me.moveOriented(age.Vec3f(-10*age.Driver.getStep(), 0.0, 0.0))
if age.Input.getKey(age.KEY_D) == 1 \
or age.Input.getPadBtn(0, age.BTN_POV_RIGHT) == 1:
me.moveOriented(age.Vec3f(10*age.Driver.getStep(), 0.0, 0.0))
# Rotate camera 150 degrees per second in X and 120 degrees
# per second in Z
curRot = age.Eul()
curRot.x -= age.Input.getMouseForce().x*150*age.Driver.getStep()
curRot.z -= age.Input.getMouseForce().y*120*age.Driver.getStep()
me.rotate(curRot) # Apply rotation to camera
Not so hard, but alot code to take in at once.
The "def on_update()" is a function that is called automagically inside the engine. You can also create your own, but you have to call them inside one of the predefined, automatically called functions.
- on_[event]() : when an event; collision, deletion, scan and so on happens. how will the entity react to it
NOTE: This is the current method, which I most likely will change later for more dynamic script usage.
April 5, 2010
Thoughts about games and engines
While working on this engine, I've been reading and watching numerous GDC (Game Developer's Conference) stuff and I have learned alot of simple and advanced tricks, like multithread tasking, shadow mapping tricks, animation layering and reusing code in numerous ways, just to name few. Also a huge point that I've heard on many sources and witnessed myself, is that an AAA engine, like Unreal, CryEngine or Source have, at some point been a generic container of features and techniques, that then is mold into a game specific engine, with dropping and adding features, modifying some parts and just leaving the game specific stuff. The result can be something entirely different than what it used to be. This is also a huge point on getting the source code of an engine and why industrial AAA companies make a huge scene of it. It's true that Quake IV and Doom III used the same id Tech 4 engine, but the featureset is still so different.
This is also the case with AGE. I try to develop it so that I can later extend it to a game specific engine. Of course engines all have the core features remain the same, but some more high level, like shaders and action system might be altered.
Keeping in mind, that a game engine is the motor under the hood and the game is the nice seats, wheel, pedals and so on with the player being the driver, getting the experience of moving fast and waiting for the light turning green while burning the tires and listening to heavy rock. The game engine is the core to build a world for the player to experience.
A hint I've gotten from a industry veteran is, that don't make the game become experience, let the player experience the world the game creates.
This is also the case with AGE. I try to develop it so that I can later extend it to a game specific engine. Of course engines all have the core features remain the same, but some more high level, like shaders and action system might be altered.
Keeping in mind, that a game engine is the motor under the hood and the game is the nice seats, wheel, pedals and so on with the player being the driver, getting the experience of moving fast and waiting for the light turning green while burning the tires and listening to heavy rock. The game engine is the core to build a world for the player to experience.
A hint I've gotten from a industry veteran is, that don't make the game become experience, let the player experience the world the game creates.
April 3, 2010
Imaging AGE
As I promised earlier today, I will update some screens to you. I keep my promises.
But before them, I would like to give a small(ish) list that includes features in my current TODO-list and features on my COULDHAS-list.
TODO (in possible order of completion)
That's the short "public" version of my little list. I will explain how I implement things as I push on. I will also probably add tutorials when I see fit that this engine can be shared.
Now something random called screenshots:
Sphere. I know I said I wouldn't post a sphere. Couldn't resist.
Sled that uses two materials. Thanks to blendercookie.com.
Sled closeup. Thanks to blendercookie.com.
But before them, I would like to give a small(ish) list that includes features in my current TODO-list and features on my COULDHAS-list.
TODO (in possible order of completion)
- Shadows with spotlights, point lights and global (sun) lighting, in that order
- Dynamics
- Scene exporter to blender
- Material files
- Animations (keyframe)
- Particles
- Multithreaded system
- LUA scripting
- Scene graph: thanks to Samuel Anjam for reminding me of this thing. I was first a bit against it when he thought adding it to his engine, BlendELF, but then I also begun some investigations and thought why not. I will explain later what scene graph is and why it's useful.
- Cache and asset system: Or in direct terms; a more sophisticated file system.
- Bones animation: Something every GE nowdays needs. I just need to look up to this to implement it, when I get there.
That's the short "public" version of my little list. I will explain how I implement things as I push on. I will also probably add tutorials when I see fit that this engine can be shared.
Now something random called screenshots:
Sphere. I know I said I wouldn't post a sphere. Couldn't resist.
Sled that uses two materials. Thanks to blendercookie.com.
Sled closeup. Thanks to blendercookie.com.
AGE is still alive, folks.
I haven't been updating this blog for a while, so I'll bump it.
The AGE is still alive and I've finished great portion of it already, making it versatile engine to use in your game creation. I'm working on things like Python bindings, multithreading (and choosing which technique is the best to implement) and shader generator.
Currently AGE has the capability to the following:
Work work,
Inestical
The AGE is still alive and I've finished great portion of it already, making it versatile engine to use in your game creation. I'm working on things like Python bindings, multithreading (and choosing which technique is the best to implement) and shader generator.
Currently AGE has the capability to the following:
- Python scripting
- Multiple materials per mesh
- Multiple meshbuffers per mesh (LOD-system, experiemental)
- Support to all image types you can name
- LUA scripting
- Shadows with spotlights, point lights and global (sun) lighting, in that order
- Dynamics
- Scene exporter to blender
- Material files
Work work,
Inestical
June 5, 2009
About the engine status
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.
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.
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.
Subscribe to:
Posts (Atom)