pegwars : political economic and galactic warfare

Changed exporters to read object name, and initialise the file/save dialog with the correct name. This should make it much quicker to export objects and also makesexplicit and easy the rule that you must save the mesh file to the same name as the object. i.e. As long as you name your object, export is as quick as pressing run exporter and OK. Added 4 lights into the cockpit. This runs slow! It's now doing 5 passes over the entire scene with shadow-mapped lights. Optimise the lighting - get lights to cull their drawCommands against both the camera and the light. Skipping doing any culling at the Python Scene level, done immediately in c++ Solution - LightingRenderChannel has lightCuller_ and cameraCuller_ these run lightculler then cameraculler . Bug - You can see black squares around the light frustum. Fix by turning off the AmbientLightingChannel. Looking into why meshes bound to AmbientLightingChannel are causing the lighting anomaly ambient_cube_map.vsh : Outputs the projec

Fixed light map projection by setting the wrap mode in TextureStage to border. This may affect other maps, yet to see any side-effects yet. Cockpit is now properly attached to the spaceship, and has its own lights working. If you link a 'CockpitPos' object when making a spaceship, the cockpit will be attached in that spot. Cockpit camera now uses cockpit-local transform from 'Camera/Transform/Position' Screenshot shows one outside light and two in-cockpit lights

Ok so now I'm up to date, I've blogged all my diary entries I had in a text file on the computer. The posts won't come as frequent anymore because they'll happen when they happen, and before they happen I'm going on a 2 month road trip and moving up to Darwin :) After that I hope to settle into a new place, a new lifestyle and new PEGWARS development.

Made a new city block, this one a little park with 8 trees. Added option to include Logic=****** in the user properties, this is initially so I can export City Pieces with WrapWorldPosition already there. Used the new .object exporter, works well.

Got many boost::python things working now that I am using shared_ptrs. Always knew I should have but was too lazy to do so, it finally became necessary. The main thing is I can now access worldObject hierarchies *safely* and pass IData back and forth from python. From this I now get WorldObjects loading, creating Python LogicObjects from the object files, and now have an onLoaded call. All Logic Objects get onLoaded called once the entire WorldObject is loaded. Lights are now loaded from .object files, and they are controlled via LightLogic scripts (which currently have to be loaded via the ScriptLogic wrapper class). The LightLogic currently sets the light matrix based on the position of its worldObject. I should make a C++ light object that is intrinsically tied to world objects. Also created is the ControlCentre script. This will be responsible for running all the ships' systems. First up I'll just be using it to shoot pulse lasers.

Loads done since the last posts. Just a quick comment though. I was getting no WorldObject::Ptr to python by-value runtime errors, simply trying to return a child smart pointer. I thought boost would have taken care of this since I carefully made sure all my WorldObjects are now reference counted via boost::shared_ptr. However, to fix the runtime error, I had to declare that my WorldObject::Ptr was indeed simlar to a WorldObject by changing the class declaration : class_ >("WorldObject", no_init) to class_ >("WorldObject", no_init) Funnily enough I didn't have to do this with IData::Ptr, weird

Now to tweak I need realtime control over shader constants, python access would be good enough. So I'm going to try and hook in with the ShaderManager and register values by shader name and register. Done .

Debugging SSDO, although only at the SSAO stage. Just changed the depth_normals shader to output projectablePos.zw from the vertex shader and dividing z by w in the Pixel Shader to get the desired depth. This should be the correct depth, and removes the /50000.0 hack in the previous vertex shader. The SSDO effect is very sensitive to its world radius, you can either see the small details or the large details. But doing importance sampling on the filter taps allows for a much vaster range for the effect to be visible. Gonna randomise over time the taps. The effect reallly needs 64 taps to look good. So I'm going to try and downsample the depth image and do SSDO on that. Now trying to change the visibility function. Even the testVisibility function gave decent results.

Now trying to get lighting working using the new Scene construct and support for n lights. Split LightScene into a write and read phase, each with their own RenderChannelStrip The goal of this is to have the draw order for all render channels interleaved to look like this: light1 write light2 write ... camera1 draw depth light1 read light2 read camera1 draw materials camera2 draw depth light1 read light2 read camera2 draw materials ... This is now done. Now there are heaps of Render Channel Strips, each describing one stage of the pipeline. Multiple lights are not completely working, as they have no current way of utilising a separate render target (all are hard-coded to use data/lightMap1.xml) If lightX write, lightX read can be customised to use any render target, the lighting can be performed. OK gots this all pretty much working, for n lights. The light maps seem at least to write correctly. The throwing of the lig

Thing are going so fast it's hard to keep track. Heres some current thoughts: All is working as planned, benefits of thoroughly testing the python scene library before using it in PyPegwars There are a bunch of Python classes mirroring C++ classes, and confusing things right now, e.g. MeshPiece, RenderChannelStrip The 'planets' aka light probes are being rendered via worldObject bind to CameraChannelStrip. The lightmaps are being rendered via worldObject bind to LightChannelStrip. The lighting on the objects is happening via the old system, i.e. C++ world objects binding to render channel strips. How do I have 3 camera scenes, i.e. Far, Near and Cockpit, all rendered from the same viewpoint? how do I share a camera around? Currently there are 5 scenes: farScene scene cockpitScene camera's CameraScene light's LightScene TODO tonight Get rid of the python RenderChannelStrip concept entirely Change WorldObject to store (material,drawCommand) map instead of (renderCh

Goal : get planets and suns rendering. This requires displaying the render channel strip that the world objects are currently being bound to. Changed the "DrawScene" update command to actually draw a scene, instead of a render channel strip. This is because the scene has extra stuff like a camera/lens to setup rendering with - it may also have render targets etc. Basically we need to go via the full RenderMethod::standard fn because it does important stuff like clearing the back buffer and calling beginScene()/endScene(). In the end we may not want to use RenderMethod::standard Split out RenderMethod::standard to ::beginScene and ::endScene Problem now is the 'debug render channel' uses / clears the depthTexture. Alternatives here: 'debug render channel' only has 'Gui' and 'Console' channels makes old modules (dog fight, architect) not work make them work with the new scene architecture ALL DONE TODO : get rid of the 'debug render cha

Created all the old Pegwars Application Modules ObjectPool - added error msg to report objects that have no vizCallback Working on SpaceFlight module. should this module create a solar system, or have one passed in? doesn't matter yet, defer this decision. got it promoting planets and suns to the appropriate far/normal/cockpit scenes made first link between python and c++ game : planets + suns now *have a* world object that represents themselves. planet and sun created by solar system and added to SpaceFlight's scene. SpaceFlight has far/near scenes, ticks all objects and culls them between far/near objects. bindMesh for sun/planet now binds the 'debug python mesh' and its world object. Created C++ RenderChannelStrip ( instanceable RenderChannelManagers ) Replaced WorldObject::visible with bind( RenderChannelStrip ) and unbind(RenderChannelStrip ) Added DebugChannelStrip for now, a singleton channel strip used by python console / engine statistics etc and also the one

Stingray : the new engine Stingray is organised into a Channel strips. Each has a list of RenderChannels, and each of these have a list of DrawCommands. The strips and channels are created and arranged in an order specified by the game programmer. This design means that a Stingray game is not bound to forward-rendering, or deferred-rendering, single or multi-pass materials etc. It is completely flexible from this standpoint. Channel Strips are purely for convenience, they are repeatable blocks of Render Channels, for example implementing shadow-mapped light requires light-map-write and light-map-read channels. These two make up a LightMapChannelStrip; each light-mapped light thus creates its own LightMapChannelStrip. The fundamental drawing unit in Stingray, the DrawCommand, exists so that all draw commands can be sorted with respect to one another. This allow s each render channel to sort its draw commands to draw in the most optimal order. For example the depth-pass channel req

Pegwars, or Political Economic and Galactic Warfare, is my hobby computer game that I've been writing since, um about October 1997. That's 12 years ago! For anyone that has been around computer games a long time, the word ELITE should mean something to you. Something special. ELITE was the game that hooked me for life. Until ELITE, games were a fun curiosity, usually involving run and jumping a little man , llama or 'Horace' around 2D levels, requiring pixel-perfect accuracy and some bleepy soundtrack that these days is considered somewhat 'retro-cool'. ELITE was a full 3D (wireframe) space combat exploration and trading game, which involved 8 entire galaxies, alien races, missions and more. All of this on a 48K ZX Spectrum. For an 11 year old boy, that was quite something, and my mind was truly blown. Ever since university and being able to write somewhat coherent code, I've been writing PEGWARS, my interpretation of this genre. It's my hobby pro