In this section you can check out what I'm currently working in, practically in real time.
If some of this seems cryptic it's because the logs seen here come directly from my personal productivity tool prio, and are really just "notes to self".
Nevertheless, if you are interested in what I'm currently working on, this space will certainly be updated FAR more often than the news section.
18:21:35 ace TASK: merge local::IStream into local::FileStream
14:53:13 ace TASK: test online replays on various machines
14:21:31 ace LOG
Ran tests, including online replay viewing, on the XPS. Absolutely no problems.
14:21:31 ace CLOCK: 00:00 hours
14:03:13 ace LOG
Viewed replay from jonas, looked like it worked.
There is always to option to implement the hash check for online storage, but I will leave that for later as it is a bit of work.
14:03:13 ace CLOCK: 00:00 hours
13:43:16 ace TASK: initial online replay tests
13:10:22 ace LOG
Hash integrity looks solid.
13:10:22 ace CLOCK: 00:00 hours
12:43:39 ace LOG
Reimplemented hash checks parallel to replay (separate file). This is less invasive.
12:43:39 ace CLOCK: 00:00 hours
12:30:16 ace TASK: bump replay format if zero speed code is ok
07:43:57 ace LOG
A completely pathological case; an asteroid actually managed to have a zero speed, as well as being positioned on the edge of the screen.
Is this an artifact of the edge repel code?
Adding code to check for zero speed, and if so randomize a little bit.
07:43:57 ace CLOCK: 00:00 hours
06:50:30 swörd TASK: sword plane to core
22:07:45 ace LOG
Bloody hell, the database was truncating the replay bytes above 2^16 bytes long. Apparently the datatype TEXT is limited by this (RX is gonna get a kick in the ass). LONGTEXT to the rescue...
22:07:45 ace CLOCK: 00:01 hours
21:38:02 ace TASK: unlimited string type
21:37:56 ace LOG
Implemented core::EpicString (hehe) for unlimited length strings.
To be fair, I checked out std::String, but the syntax fucking suxxored, so I implemented a simple and specific replacement.
21:37:56 ace CLOCK: 00:05 hours
19:43:12 ace TASK: check for string overflow
19:27:47 ace LOG
Big replays seem to decode wrongly, I am suspecting a string overflow problem.
19:27:47 ace CLOCK: 00:00 hours
19:27:10 ace TASK: more ace_webtests
18:30:25 ace TASK: storage test app
17:11:46 ace LOG
I regards to the problems with online storage; I had forgotten to de-chunk the HTTP response!
Exactly the same problem I had with Bloom, but I had forgotten about it and assumed that it was now part of the net::Http11Request implementation, which it is NOT!
17:11:46 ace CLOCK: 00:01 hours
13:38:35 ace_art TASK: font concept
13:38:33 ace_art TASK: menu system concept
13:40:26 ace LOG
Online storage, retrieval, and listing of scores is implemented, albeit with bugs.
Going to implement a dedicated test app to make sure that the storage and retrieval works as expected.
13:40:26 ace CLOCK: 00:00 hours
13:33:09 ace TASK: online storage of replays
10:26:02 ace LOG
Still working on online storage of scores / replays, major refactoring going on.
10:26:02 ace CLOCK: 00:00 hours
23:50:35 ace TASK: fix top of font stretched box effect to conform to top of gui
23:16:05 ace LOG
The current exe is configured with a local backend. To log in, just supply a name, anything will do. This name is stored in any scores you create.
23:16:05 ace CLOCK: 00:00 hours
23:06:23 music TASK: install partner instrument compilation
20:08:25 ace TASK: web based authentication
19:26:36 ace LOG
Working on the web backend.
In this case all relevant interfaces will probably be implemented as separate objects (as opposed to lumping everything together in the local backend case). This allows for a better separation of concerns as well as simpler parallel operation of HTTP requests.
19:26:36 ace CLOCK: 00:01 hours
23:08:02 ace LOG
Implemented a conceptual test for menu backgrounds. This uses meshes and the membrane shader animation support. No real work done on the non-membrane textures yet.
23:08:02 ace CLOCK: 00:00 hours
23:07:05 ace TASK: interface framing tests
17:52:24 ace TASK: document all controls in HangarController
17:57:32 ace LOG
Account name is now in the scores / replays. This bumps the version to 23.
17:57:32 ace CLOCK: 00:00 hours
17:54:47 ace TASK: add user name to replay storage
17:03:16 ace TASK: user name / profile stuff
17:03:08 ace LOG
Implemented basic account / login gui stuff, against a proxy / local backend. Speculating that I will need something similar to this at least for limited testing.
17:03:08 ace CLOCK: 00:01 hours
15:11:57 ztank LOG
Getting kind of distracted from ACE by this...
Even though I like the tightness of a simple multiplayer CTF or Domination style game, the game world and driving around in a tank really fascinates me, and resonates so much with the opening scenes of Tron where CLU is driving around looking for "data".
Was sketching on a big world map thing, basically a grid of sectors, and thinking that all the meshes for each sector would be too much to keep in memory and / or render at the same time. However, it looks like that once in the disk cache, the meshes take something like 5 msec to load, and the longest time I've seen when not in the disk cache is something like 59 msec. Doing that every single frame would give something around 16 fps.
So, there would probably be no issues at all with just swapping world meshes in and out of memory once a certain threshold is crossed. Thinking about keeping 4 in memory at once, centered on the player. The game uses under 100MB of RAM now as it is, even on a busy level like Sector D (from Z-Fighter).
However, what does one do in such a game? It is obviously single player at the core, in that there is a specific goal to overcome, and after playing some more Planet Calypso I don't think a free roaming world without specific goals is really all that interesting.
Could I mix and match sector types? Mountainous sectors that use a heightfield? Swörd-style sectors that are custom built? Need a GOAL!
15:11:57 ztank CLOCK: 00:11 hours
14:56:20 ace LOG
Changed score page for case when there are no scores.
14:56:20 ace CLOCK: 00:01 hours
14:46:39 ace LOG
Impulses no longer affect ship in 1337 mode when black hole is active. This felt like it undermined the feeling of power in the black hole.
This bumps the replay version to 22.
14:46:39 ace CLOCK: 00:00 hours
14:45:39 ace TASK: impulse affect ship with shield / black hole?
13:17:04 ztank TASK: decals use hit surface normal
23:53:55 ztank LOG
Spent some time building a tank for the game, had a lot of fun with that.
Learned a lot more about uv-mapping, and found a nice way to get the tanks colored the way I want them. Using basically a solid color texture with all tris of a given color mashed together in that area. Also having the texture tile vertically, so that animating the tank tracks is just a matter of offsetting the v component according to tank speed!
23:53:55 ztank CLOCK: 00:01 hours
23:50:16 ztank TASK: animated tank tracks
23:50:13 ztank TASK: tank model!
12:11:27 ace LOG
Implemented basic scoreboard pagination, sorting methods remain.
12:11:27 ace CLOCK: 00:00 hours
12:10:46 ace TASK: scoreboard pagination
09:14:59 ace TASK: better constant vector support
00:03:43 codebase LOG
Note to self, trust your coding instincts.
Working on ACE now, we have a custom built (external 3d program) scene that is lightmapped, and both the uvs for light and for the albedo are done "by hand". The artist, of course, gives the old "I have more control" motivation for this.
The lightmap bleed problem is classic (have to make sure there is room outside each mapped tri so that lighting is isolated), but not all of a sudden we have similar mipmap problems for the albedo as well!
What a pain; both a higher vertex count due to the need to split up the mesh for albedo texture reuse (there is only a single albedo texture for the whole scene), but automatic support for uv wrapping is out the window.
John Carmack is a smart man...
00:03:43 codebase CLOCK: 00:03 hours
23:36:09 ace LOG
Support for double uv hangar is now implemented. Lighting is also fully integrated in-app; when a lighting calculation is done the lightmap is reloaded from disk.
Edit lights and props in the hangar using the Hangar controller (G for dev gui, F5 to select the Hangar controller). Lighting is also performed here.
23:36:09 ace CLOCK: 00:01 hours
23:31:58 ace TASK: double uv sets for hangar, lighting needs to be done in a shader
23:31:49 ace_art TASK: hangar export 2 objects, one called "albedo", one called "light", must have same tri and vert counts
16:25:23 ace_art TASK: raw hangar (mesh, albedo texture NO LIGHTING!)
16:24:23 ace TASK: chase memory leak
14:05:13 music TASK: do some re-up tests
19:12:12 ace LOG
Fixed a pretty subtle issue, namely the case when roids are traveling parallell to the edges of the screen and are positioned very close the the same edge. This makes them very hard to see, and undermines the game flow as you think that the level is clear when it is not.
This is solved by detecting when they are close to the edge (within radius), if they are going in the right direction (speed dot the outward facing normal > 0.f) a force is applied along the said normal proportional to how close they are to the edge (closer = larger force).
This tends to send them across the edge they were tended toward anyway, even if the were moving just a little bit towards it, and should keep these cases from ocurring.
This breaks replays, so I'm bumping the version number again.
19:12:12 ace CLOCK: 00:04 hours
19:08:03 ace TASK: roid edge repel
13:11:58 ace TASK: DragPosScreen -> persistent to get it out of the constants file
10:47:55 ace TASK: think about coop multiplayer
10:44:02 prio TASK: alpha sort labels
10:22:45 ace TASK: main engine exhaust
22:34:25 ztank TASK: multiple tanks on two teams
22:00:47 prionews LOG
I have added a basic "how to" section to prio, available once you log in.
22:00:47 prionews CLOCK: 00:00 hours
20:06:24 prionews LOG
At Mad's suggestion I have added the projected completion date for all tasks at the top of the prio gui.
Active Tasks now also displays all tasks for all labels (alphabetically sorted by label) by default. Per-label functionality is the same as before.
20:06:24 prionews CLOCK: 00:01 hours
18:05:24 prionews LOG
I have added per-label display of: days / task, tasks / day, and projected completion date. This information is available when viewing Active Tasks.
18:05:24 prionews CLOCK: 00:01 hours
18:04:03 prio TASK: label completion prognosis per label
16:46:32 prio TASK: clean up labels
16:41:54 prio TASK: label completion prognosis
16:34:46 prionews LOG
Added "estimated task completion date" to user stats. This deserves an explanation...
I've always been bothered by the tendency of various software development methodologies to include "task estimation" as part of the process. In my experience nobody wants to estimate (it is too hard / not precise enough), and also no one cares if their estimations are off or not, due to any number of factors / excuses.
As part of my original vision for prio I am now calculating a projected / estimated completion date solely based on historical data. As long as you have retired any task, prio can calculate your completion rate and therefore also a projected completion date (based on your rate and the number of active tasks you have left). The numbers and dates in the user stats section of the login page is based on all tasks, regardless of label, for each user.
Of course, some people will argue that this is at least as imprecise as traditional task estimation, and perhaps feel that this is just another useless statistic. Personally I've always wanted to see my own "productivity" rate calculated in just this way, and the biggest bonus (for me) is that it's completely automatic, doesn't require estimation, and is based on real historical data.
Do with it what you will!
PS Similar calculations will soon be available per label. DS
16:34:46 prionews CLOCK: 00:09 hours
15:29:43 prio TASK: all sql to model
20:03:13 ztank TASK: map
19:22:50 ztank TASK: 4 direction laser cover
19:11:15 ztank TASK: switch to aabb based collision
19:11:00 ztank LOG
Removed CollisionGrid completely, now everything runs on AABBs.
19:11:00 ztank CLOCK: 00:00 hours
15:09:59 ztank LOG
Switched to aabb collision for bullets, i.e. no more collision grid.
15:09:59 ztank CLOCK: 00:00 hours
00:36:50 prio LOG
Moved SQL to Model for unsorted tasks. Now only retired tasks remain. Looks like there is quite a bit of commonality to be factored out in Model.
00:36:50 prio CLOCK: 00:00 hours
17:54:00 prio TASK: doSubmittedLogs, move sql to model, do labelrights filtering in model
17:51:18 ace TASK: research in-engine lighting for hangar
13:13:16 ace LOG
Implemented the ambient cube solution for meshes, works quite well. Going with calculating at the edges of the bounding sphere in each direction.
13:13:16 ace CLOCK: 00:00 hours
13:12:39 ace TASK: light cube for props
00:01:18 ace LOG
Added prop instances to occlusion of lighting (in addition to the mesh that is being lighted itself).
A blurred (I used 2.0 pixel gaussian blur in PShop) 512x512 lightmap is definitely high enough resolution.
Found and fixed a bad dot product in the ray vs tri code, so now things work as expected.
Thinking about the light cubes for prop instances; this will basically be Valves solution for ambience, however with a twist -> I can render a specific light cube for each instance, and also take the radius of the mesh into account. This should give me lighting conditions at the edges of the bounding sphere instead of at the center. Somewhere between the two extremes should give me good results.
00:01:18 ace CLOCK: 00:04 hours
23:57:11 ace TASK: include prop geometry in occlusion
23:57:09 ace TASK: better ray vs tri code
14:09:22 ace TASK: prop placement in hangar
12:27:39 ace TASK: separate hangar editor from regular hangar controller
11:23:32 ace TASK: light placement in hangar
21:46:54 ace LOG
Some good progress on optimizing the lighting calculations. The big deals were:
1) Mapping uvs to world positions and normals. The win is to cache this on disk (pixel cache), as it will never change unless the mesh changes (positions, normals or uvs).
2) High level culling of which lights affect which triangles. The pixel cache retains information about which triangle a certain uv / pixel comes from, and during lighting a stack structure called the LightCull caches the tri vs light information (using bounds sphers for tris and lights).
This is then stored as 32-but flags for each triangle to be lit; hence there is only support right now for 32 lights in the scene. When a pixel goes to calculate lights, the first test for each light is to see if the triangle that pixel belongs to is even affected; a fast early out.
I'm not going to optimize this anymore for the time being, as right now a 1024x1024 lightmap is lit in about 1:30 minutes with 16 lights, many of which have huge radii.
21:46:54 ace CLOCK: 00:05 hours
20:07:42 ace TASK: optimize geometry for intersection, including high level bounding
19:24:49 ace TASK: high level info about which tris are affected by lights, can cull enter batches of pixels this way
15:12:39 ace TASK: disk cache of pixel to world mappings, wont change unless vertices change (pos, normal, uv)
00:50:22 ace LOG
Added "in-triangle" cache when processing lightmap pixels, looks like about a 60 percent hit rate.
00:50:22 ace CLOCK: 00:21 hours
00:27:36 ace TASK: mesh occlusion for hangar lighting
21:53:55 ace LOG
Did some rudimentary experiments with lighting (no occlusion) for the hangar scene.
Implemented some nice code for going from lerping 3d positions and normals from uv space; this pretty much sorts any lightingmap based stuff as long as you have a good unique uv-mapping to begin with.
Will probably need a separate uv layout for the lightmap (different from the albedo mapping).
Considering some kind of cube based (real time HLSL) lighting for objects in the hangar scene. A regular database of samples would even potentially support moving objects.
21:53:55 ace CLOCK: 00:03 hours
23:44:06 ace LOG
Setup proxy hangar scene. Uses the by now "standard" shader with addition ramp and emit textures.
Still need for figure out how to light this. Can probably get away with mapping the lightmaps in an external tool, but that might not be a win since I still need to go from texel space to world space in order to perform the actual lighting.
Placement of props shouldn't be a problem using a fly camera, and we can always enable constant-style exact editing of values.
23:44:06 ace CLOCK: 00:02 hours
23:38:35 ace TASK: rig proxy hangar scene
15:23:06 prio TASK: finish cleaning up input
15:08:00 prio LOG
Serious cleanup, working moving all sql stuff into model.
Got rid of all manual parameter validation; looks like enabling PHP errors deals with this sufficiently.
15:08:00 prio CLOCK: 00:03 hours
14:14:03 ace_art TASK: first pass powerup icon design
14:13:04 ace TASK: fly camera for hangar
10:21:06 prio LOG
Working on cleaning up the codebase, right now moving the database access from input to model.
Thinking about perhaps objectifying certain aspects of the app, with the hottest candidate being the handling of labels in the various controllers.
10:21:06 prio CLOCK: 00:01 hours
17:21:20 ace LOG
Adding ramp / emit to decoy should now also work.
17:21:20 ace CLOCK: 00:00 hours
17:18:01 ace LOG
Powerups how use the data driven shader, with a little twist; albedo and ramp are shared, emits are unique. Using the pulse function for emits here.
Also added emits to explosive roids, using the flicker function at Jonas suggestion.
Adding ramps and / or emits to the medium roids should be straightforward. If ramps are used we can discuss sharing if we find that they are the same across different assets.
17:18:01 ace CLOCK: 00:02 hours
17:15:56 ace TASK: powerups to use data driven shader
12:47:44 music TASK: finish listening to latest 3d party live sets
12:19:27 ace LOG
New data-driven shader options should also work for all medium asteroids (just add _ramp and _emit textures as needed).
All textures are loaded using the following file format extension cascade:
tga, png, dds, jpg, bmp
This means that you can use any of the above state formats (i.e. you don't have to make your ramp textures be png).
Again, the main reason for .png usage is for the skybox textures, as they are very large in uncompressed 32 bit tga.
12:19:27 ace CLOCK: 00:02 hours
12:14:49 ace TASK: data drive shader selection?
12:14:48 ace TASK: evaluate metal shader usefulness
12:08:37 ace LOG
More work on the metal shader.
The following is currently supported for:
-big asteroids (01, 02, 03)
The below cases will probably change very soon (i.e. collapse everything into a single shader).
The base albedo texture can be 24 or 32 bit (ship, bigasteroid01, bigasteroid02, bigasteroid03). If this is the only texture, it will use the staticmesh.fx shader, and the alpha channel will control which pixels are emissive. The formula use ADDS the emissive pixels on top of the shaded albedo pixels, so using a 24 bit texture will effectively make the mesh appear doubly bright (shading should still be visible however).
2) albedo and ramp
The ramp texture (ship_ramp, etc) is used for the metal effect. If this texture is present, the metal.fx shader will be used, and the alpha channel of the albedo texture controls the blending between shaded albedo pixels and unshaded ramp / metal pixels. Note that white alpha means albedo, and black alpha means ramp / metal.
3) albedo and emit
The emit texture (ship_emit, etc) is used for emissive pixels. Having the albedo and the emit texture present (no ramp) is effectively the same as case 1, except that the alpha channel of the albedo texture is NOT used; instead the emit texture is simply added on top of the shaded albedo pixels. This will probably be the future pipeline for achieving case 1, and if so, you can use a 24 bit texture for both albedo and emit.
Not that this is more flexible than case 1, as you are using 2 different textures (in case one it's the same texture). Note also that the uvs are the same for both textures.
4) albedo and ramp and emit
This is the most complex case of course, and is the same as 2 and 3 combined.
-ship and bigasteroid01 use case 4
-bigasteroid02 uses case 3
-bigasteroid03 uses case 2
Experimental animation control of emit texture:
Right now I have hard-coded a few different functions for animating the amount of emissive texture used. The ship currently uses a constant value of 1, bigasteroid01 uses a pulse function, and bigasteroid02 uses a flicker function.
If we use these they will be fully editable per asset.
As mentioned I will probably merge all of this into a single shader instead of using metal.fx and staticmesh.fx (the legacy shader). I will probably also enable all of this for the animated assets which currently use pixelmesh.fx.
If all of that goes well I will probably also merge membrane.fx as well, allowing for even more animation of the ramp / metal / membrane pass.
12:08:37 ace CLOCK: 00:13 hours
18:13:26 ace LOG
Added experimental metal shader:
The normal albedo / diffuse texture be 32 bit, and the alpha channel controls blending between the normal albedo (alpha is white) and a separate ramp-based metal texture (alpha is black). This ramp-based metal uses the same technique as the membrane / deflector stuff.
To retain the feature of "alpha emit", an additional 24 bit "additive" texture is added to the aforementioned blending of textures.
Currently only the ship uses this shader. metal.png is the ramp-based metal texture, and ship_additive.tga is the additional emissive / additive texture for the ship.
If this proves useful we need to figure out how many "types of metal we need", as well as which assets also require an emissive component.
18:13:26 ace CLOCK: 00:03 hours
18:09:11 ace TASK: metal shader
16:42:33 prionews LOG
Time-filtering (month / year) is now enabled for logs as well.
16:42:33 prionews CLOCK: 00:00 hours
16:39:00 prio TASK: some kind of year, month, day links / filtering for submitted logs
13:29:37 prio TASK: label-style layout for month selection