| Thursday, September 29, 2005 |
  Camera Obscura | 
Posted - 9/29/2005 12:12:42 AM | Camera Obscura
Spent the last couple of days on the camera & controls. Tonight I added several more text-tweakable camera options, such as the camera's distance behind the player, the min & max camera height, etc. I also made the camera position averaging time-proportional so it would feel the same at different fps.
Yesterday I added the option to make the camera always able to see the player. It checks for occlusions with a series of raycasts, then if it finds an occluder, it attempts to rise up until its clear. We may experiment more with this, but right now it seems as if this height adjustment is more distracting
than the character being obscured by something. It's not like you don't know where your character is - he's always near the middle of the screen. Plus, the player can always zoom out, which is much more unlikely to occlude the character. It seems this is best left to the player to deal with, but perhaps we'll revisit this option in the future.
Right now the mouse left/right turns both the character and the camera CCW/CW. One of the new tweaks we tried tonight was making the mouse up/down changing the camera pitch, well, actually not the pitch, but moving the camera look at point towards and away from the character. We don't ever want the view to go parallel to the ground - that becomes a first-person view, and can create board design problems, especially when we don't model ceilings, and don't want the player to see across the entire level.
I added min & max target distance parameters to the render options to play with various pitch options, and it seemed the more tweakable the camera up/down was, the more control you wanted over it. I'm currently thinking that we will just choose a good view point for close-up, and the players will get used to what it can and can't do pretty easily.
Right now it looks like 4 meters in front of the characer lets you see down a hallway a good distance without letting you look through the whole level at once.
Here are three shots, one zoomed out, the other zoomed in, and another with the camera target point set quite far away. I have to say I think the 3rd shot looks the most appealing, other than the black area in the 'sky'. I'm somewhat worried about performance on a larger indoor level, but I suppose we could fog out the world lighting in the distance or some other technique to keep perf up. Perhaps simply dimming lights that are far from the player, and then culling those that are effectively black would work well.
I'd appreciate hearing your thoughts on the 2nd vs the 3rd pic?
I'm preparing to go out of town this week, so I probably won't update again until Wednesday, but I'll probably be on-line a bit here and there.
| |
| Tuesday, September 27, 2005 |
| Camera Motion | 
Posted - 9/27/2005 10:18:07 AM | Camera Motion
First of all, thanks to those of you who responded to my Poll in the last update. If you haven't yet, please respond if you get a chance.
Man, changing the camera has such a huge impact on so many things. One thing that I'd been meaning to fix for a long time was the camera sometimes clipping into the world. This is caused when part of the world geometry intersects the near clip plane, causing a distracting artifact right in front of the viewer, including showing off the wonders of back face culling.
This was something that would happen rarely in the past, but happened much more frequently as I allowed the camera zoom-in feature to move down & behind the character more. This prompted me to fix it sooner rather than later.
So, last night I implemented the first version of a non-penetration camera. I'm sure it will change over time, but so far, I like it pretty well.
I took a two-step approach. The first step was to make it so the camera never penetrated anything, but didn't worry about being smooth or feeling nice. I got this done pretty quickly, but it was about as disorienting as I feared, with the camera snapping around as you turned the character, and objects behind the character that might get clipped forced the camera to snap its position to somewhere safe.
Clearly, to make it more smooth, I'd need to do the second version, which works like so :
1) Save the last camera position. Handle the first frame special case nicely.
2) Create the new desired camera position, ignoring all clipping issues.
3) Simulate a sphere starting 20 meters above the new desired camera position, moving straight down.
4) Make the sphere radius big enough to encompass the viewpoint and near clip plane in world units.
5) Drop it straight down to the desired camera level, stopping at the first collision, if any.
6) Figure out the delta between where the sphere ended up and where it was trying to go.
7) Add a small percentage of this delta ( like 3.5% to the old camera position height ) to the last camera height.
8) Use this moving average as the new camera height.
This system does not actually totally prevent clipping if you turn very fast into a narrow, tall object, but it is quite rare and only lasts for a few frames. There is a clear tradeoff between accuracy and smoothness. For instance, making the sphere radius bigger than needed will detect potential colliders earlier, letting the adjustment be more gradual and less distracting to the player, but it will also have the effect of making the camera move around obstacles that are really not in danger of getting clipped by the camera due to distance.
An alternative involves simulating the camera from where it is, rather than dropping it from above. This could include lateral motion as well.
Another method would start the sphere at the player's back, and move backwards towards the desired camera spot until it hit something. This would allow the camera to zoom into the player instead of climbing over an obstacle.
But, I do like the current system, as moving the camera up & down is what the current zoom system does, so it should feel
quite natural to players.
Something I may add today is the option to keep the player in view. The camera would move up and/or toward the player so that he remained in view. This mode would most likey move the camera target point as well.
Here are the before & after pictures. This is somewhat of an extreme case, as we don't expect to have very tall walls like this that often.
On another note, I cleaned up some of the property text files for the levels, so each level can specify skybox paramters,
and whether post-processing is enabled for that level.
| |
| Monday, September 26, 2005 |
| Afterglow And Poll | 
Posted - 9/26/2005 12:59:45 PM | Afterglow
I have had a post-processing filter in my engine for a long time, but it wasn't very blurry, even though I was using a 5x5 gaussian kernel. Instead, it acted like more of a saturation boost than a glow or blur.
On Sunday I decided to track down the issue once and for all. Turns out I was only doing it half right. A while ago I experimented with the StretchRect() method, where you just take, say, a 1024x768 screen and StrectchRect() it down to a 256x256 texture, then stretch it back over the screen. I found this method wanting, due to the large amount of temporal aliasing. This sort of blinking on and off effect was very apparent in a few demos I'd seen, and even in an earlier build of Guild Wars. Not sure if they've fixed it since.
One way to reduce this while still using StretchRect(), which is nice because it's easy, would be to do 4 offset StretchRects, then blend them all together. This large decimation method definitely thrashes the texture cache, because you are minifying the texture so much that you are pulling in a lot of texels into the cache that are never used. In this example, only 1/2 of the texels horizontally and 2/3 of the texels vertically are re-used, taking bilinear filtering into account.
Instead, I was taking my screen rez, stretch recting offscreen to a front-buffer sized ( 1024x768 ) tetxure ( to work nicely with AA ), and then sampling this front-buffer-sized texture into a 1/5 size texture in width, then filtering the front buffer again, this time to a 1/5 height texture.
That 2nd filter step was the bug. Instead, I fixed it to to go from 1 x 1 -> 1/5 x 1 -> 1/5 x 1/5
Then I take 4 offset samples of the small 1/5 x 1/5 texture, threshold it, then add it back over the scene. This creates a nice glow effect without very much temporal aliasing at all.
I also cleaned up the code a bit, and added more text-tweakable parameters, like the blur kernel width. Right now I support off, 3x3, 5x5, 7x7 and 9x9. I settled on the 5x5, as it gives a nice effect with very minimal strobing.
Here are two shots of the blur without thresholding. It also shows the two camera zoom levels available - one for immersion, the other for tactics :
Poll
I'd like to do a poll of those reading this journal. Please respond in the comment section.
Do you prefer the close camera, far camera, or the option to have both?
| |
| Sunday, September 25, 2005 |
| Lighting & Culling | 
Posted - 9/25/2005 5:33:07 PM | Lighting & Culling
I ran NVPerfhud on the engine tonight, because I suspected some frame-rate dips I was seeing were due to poor frustum culling during shadow passes. Turns out I was right.
This showed up in the indoor dungeon level that I created this morning. It has no directional light, but around 8 point lights, and if shadows were being handled even for off-screen objects, that could be quite a hit.
At one point just turning a bit in the first room, with only 2 point lights clearly visible, caused the frame rate to drop from 200 to 150 fps, with no visible change on screen to the ighting.
NVPerfHUD, btw, is a great free graphics performance and debugging tool, btw, and is made by my good friend Raul Aguaviva at NVIDIA.
Here is a shot of perfhud, during the ambient/emissive pass, after normal map compositing has been performed :
Here is a shot showing a shadow render target for the main character from one of the point lights :
The single-step mode of perfhud lets you step through your draw calls one at a time, and shows you the current rendertarget after each step. By running this, I was able to find out that indeed, shadows were being created for clearly off-screen objects.
Turns out that the code that was collecting shadows wasn't culling aggressively enough. Each chunk of my world is about ~20x20 meters wide, and has ~1500 polygons in it. These chunks are drawn in order to receive shadows.
Each light has a bounding box representing its range, and each material chunk has a bounding box for each light touching it, that contains a tight bounds around all geometry lit by that light in the chunk.
The missing piece was a tight geometry bounds stored with the light. So each light now has an overall bounds, based on its position & range, as well as a tight geometry bounds, which is used for culling geometry for lighting and shadows. After adding that, converting my levels to understand the new light structure, then adding some code to cull world chunks before rendering shadowed objects, I eliminated the frame hitch, and brought the average frame rate up to 220 fps in that area.
There are still sections of the level where the frame rate dips to ~155, when there really are many close-by lights. Some of these aren't visible, but they definitely intersect the view frustum. Since I've been working with a top-down engine for so long, I never bothered with occlusion culling, so there's not an obvious way to fix this.
One approach would be to have the designers add anti-portals or occlusion triggers to the level, that could be tested against to cull more lights based on the camera's position & orientation.
Another approach would have the designers place a box around the light to indicate its potentially visible area. If the player was not in this special box, then the light would not be drawn. This way you could put the box on one side of a wall where you know the player can't see beyond it, even though the light would be in the view frustum.
In other news, I adjusted the post-processing a bit, and re-enabled it. I found that squaring the bloom buffer before
adding it back made things too blinky when the camera panned, and not thresholding at all didn't add enough hotness to the bright areas, so I did both and averaged them like so :
mad_d2 r0, t0, t0, t0
Here is a shot of the post-processing in action :
| |
| Saturday, September 24, 2005 |
| Inside Out | 
Posted - 9/24/2005 9:03:26 PM | Indoor / Outdoor
Yesterday I added skybox support to the game engine. It was a little trick to get right, with the semi-deferred shading system I have in place.
The fact that I had a black background around the level was hiding some problems with anti-aliasing, but after I added the skybox they were quite obviously dark sub-pixel borders around the level when AA was on. I fixed this, and then put the skybox in the level.
Of course it looks out of place on indoor levels, so I made it optional. But that brought up another set of issues we had been discussing for some time - how to draw the edge of the world.
For outdoor levels, we have some ideas, but nothing implemented. Indoor levels didn't have a great solution. We don't want to actually model or render ceilings, because one of the key parts of the game is the ability to zoom out and get a tactical overview of the situation.
One hack I played with a while ago, which some games like Baldur's Gate do, is to render black on top of the walls, and at the map edges. This is what I tried, and it looked ok, but still out of place, and it looked really bad when the majority of the screen was just black at certain angles.
Here is a shot that contains both normally lit wall tops ( the middle island ), and black tops. Also note the incorrect indoor sunlight shadows, and the flat lighting on the character.
So, this morming we looked at a few other games, and decided to try rendering an understated version of a texture, rather than just black. In order to keep in understated, I only light it with ambient light, and it doesn't participate in other rendering. This is key, because often the point lights in an indoor level we be placed at or above celiing level for effect, and you don't want to light up the ceiling tops to distract the player from the action.
Another problem was the overall scene lighting. For outdoor levels, we have a sun or moon directional light that handles most or all of the lighting needs for the level, although you can put point lights around as well.
For indoor levels, leaving in a directional light obviously is wrong, but it wasn't as bad as I thought. We disussed ways to light the level without a directional light, and considered environmental cubemap lighting. I still may try this later on, but due to the very boxy nature of our current levels, I knew this wouldn't work super great.
I decided to just tweak the ambient occlusion term, and combine that with a scalar ambient, and that worked very well indeed.
After averaging that with the ambient bump mapping, I think we have a very good approach, and I'm really happy how it turned out.
Yet another issue that came up in low-lighting scenes was the flat character lighting. Characters typically also got most of their lighting from the sunlight, but without one, they were very washed out, so I adjusted the character ambient based on the y coordinate of the model's normal in world space. This allows the characters to have some depth even in low-light settings.
Here is a shot with all of the tweaks so far :
| |
| Friday, September 23, 2005 |
| Closer And Closer | 
Posted - 9/23/2005 1:48:33 PM | Closer And Closer
For the past couple of days we have been experimenting with various camera, cursor and control schemes. The scheme we have been working with for a long time has been a pretty fixed camera that didn't rotate, but followed above your character. A couple of weeks ago I added the ability to zoom in & out with the mouse wheel in anticipation of adding melee attacks.
This control scheme has some nice properties. One is that it's hard to get lost - the WASD keys naturally match the NSEW cardinal directions. It's easy to aim at the enemy you want by just clicking on them with the mouse cursor. I added auto-aim a while ago, so the engine does a good job of figuring out which guy to attack.
But, the distant camera an unusual perspective seems very disconcerting to almost everyone we showed it to, so I thought
we should at least test out other schemes more thoroughly before we are stuck with something either sub-optimial, or initially unappealing or confusing.
Yesterday I got a system working where there was still a mouse cursor, but your player could rotate the view with the keyboard. This is sort of lame in that keyboard turning tends to have a fixed rate. I added Shift-turn to speed the rate, but it still didn't feel good. The keyboard controls were changed so that WASD was camera relative.
Then last night, I added a scheme so that the camera & player turned when the cursor was near the right of the screen, and left when on that side. This was ok, but felt more like a CAD program than a game, especially when the mouse would leave the right side of the screen and it would leave the camera spinning.
This morning I got FPS-style controls working, and so far, we really like them. So, WASD moves camera relative, and there is no more mouse cursor. Moving the mouse right turns an amount proportional to the # of units you moved. Your player always faces 'up' on the screen, and shoots up also, but still with auto-aim.
I realized that these are almost exactly the controls for Wolf3D or Doom 1, in that up-down aiming is handled automatically. Because this is an action-rpg and not a pure action game, we will leave the left-right auto-aim in there, but may add a bonus for good manual aim, and will probably allow the auto-aim zone to be tweaked, and also tied to the difficulty level.
With the latest scheme, you can still zoom in & out with the mouse wheel. I really prefer playing zoomed in, but zooming out is great for a tactical overview of the situation, and to get your bearings.
This experimentation was made much easier by the decision I made a long time ago to have separate ControlScheme classes that implement various versions of the InterpretInput() method.
| |
| Wednesday, September 21, 2005 |
| Needles & Symbols | 
Posted - 9/21/2005 9:35:06 PM | Needles
The engine is definitely shaping up - now it's to the point where you can make a level, run around & kill enemies, who do a reasonable job of fighting back.
I have been hankering to add some other weapons to the game, so I decided to add a gun that shoots Needles. Basically, it's similar to a laser gun, except that the gun shoots glowing spikes. I gave them a different through the air sound, and made them stick in the wall!
This required a few code changes, so that if the needles hit a character, they do damage & disappear, but if they hit the world geometry, then they stick, and eventually fade away.
Experimenting with this also prompted me to change the way culling works when a bolt or needle hits something.
Earlier in the project, the enemies would move randomly around the level, and shoot if they were near the player, even if they didn't have line of sight. This caused a cacophony of laser sounds & blasts that quickly caused clipping, so I added view frustum culling, so when a bolt was off-screen, it didn't generate sparks, smoke, a decal or a sound.
Now that the AI is a little smarter, they only shoot when they have a clear shot, and have ammo, etc. so this culling doesn't have to be so aggressive.
I tried expanding the bolt bounding box for the purposes of this check, but didn't solve the problems when the needles would go past the player into the wall just out of sight, but wouldn't make a sound or leave a decal behind.
I changed the culling so that sparks & smoke are not generated offscreen, since these don't last long enough to notice, but the sound, decal, and sticking needles remain. Much better.
In the process, I had to make some changes to the sound code. Before today, I had 2D sounds, or 3d sounds with some object as the sound source. In the case of a needle or laser bolt making a hit sound, the bolt itself is dead, so it couldn't be the sound source. The sparks wouldn't be made if offscreen, so they couldn't be the sound source either, and a decal is not always created depending on what is hit, and the angle of the shot ( so the texture doesn't stretch too much ).
So, I added the capability to specify a position & velocity when creating a sound, instead of a sound source. This way I can play the needle hit sound at the right spot without needing a source for it.
I also changed the needle decals so they are smaller than the laser bolts. Perhaps I should change the code so that decal size is directly proportional to weapon damage.
Symbols
I also added a symbol decal. These will provide clues to the player as to the location of other levels, etc.
| |
| Monday, September 19, 2005 |
| Busy Busy | 
Posted - 9/19/2005 1:48:35 PM | Been busy with many game-related things lately, but I thought I'd upload a cool picture I took this morning.
| |
| Friday, September 16, 2005 |
| Up In Smoke | 
Posted - 9/16/2005 10:48:17 AM | Up In Smoke
I got some good feedback from a team member to try a darker smoke. After playing with the blending modes, I went back to an older method that seems to give good results :
SRCBLEND = SRCCOLOR
DESTBLEND = INVSRCOOLOR
The idea is that it darkens more than it brightens. This is a sort-independent mode, very similar to addsmooth, so there is no need to sort the particles before applying it. One could achieve a similar effect by doing INVSRCALPHA in the dest mode, with an alpha that is different than SRCCOLOR.
It looks more like smoke fire, wheras the older whitish smoke looks more like steam. I suppose we'll use the white method for steam or mist.
Also added some more tweakable parameters, including a quantity factor, so you can modify the # of particles spawned without changing code.
| |
| Thursday, September 15, 2005 |
| Smoke Gets In Your Eyes | 
Posted - 9/15/2005 8:40:47 PM | Smoke Gets In Your Eyes
Well, the host is back up, so the pictures are back as well.
Today I spent a few hours fixing up the smoke effect. It's been in there for over a year, but only recently have we decided to
really emphasize the particle effects more, so I started bringing the particles up to date in several areas, starting with the smoke.
The Ancient Galaxy Engine doesn't have a custom particle editor, and is not completely data-driven with respect to particles. Instead, I struck a compromise between artistic tweakability, performance, and customizability.
Many types of particle systems can be modelled in a very uniform manner, with just different parameters, including things like color, texture, particle shape ( triangle, quad, sphere, etc. ), velocity, randomness, lifetime, etc.
However, to do a world-class version of certain particles, you will inevitably need custom code to handle it. An example is water droplets. If they fall on a hard surface, perhaps they should leave a wetness decal behind. If they fall on liquid, maybe they create a splash or more droplets.
So, I have a standard class for each type of cluster of particles. A cluster is a group of particles that is created together, and often represents a bunch of particles that were
created simultaneously. The particles are created, and culled on a cluster by cluster basis. If the cluster's AABB is within the frustum, then each particle in the cluster is simulated with physics & collision.
Each particle cluster class has an associated section of the particles.txt configuration file which specifies tweakable parameters, like initial & final particle sizes, gravity factor, wind factor, lifetime, etc.
Sparks and rocky debris have their physics handled via raycasts, so they use a cheap version of physics, but they do correctly bounce off of all world geometry.
Smoke responds to wind, and rises and expands over time. Each smoke particle is physically a sphere, but drawn as an aligned quad. I was using triangles instead of quads, but they were more obvious when they intersected, so I switched today. The smoke sphere's radius expands over time, which was causing some issues in the collision. I switched from raycasts to a cheap sphere collision model, but was still having occasional problems.
It was possible for some smoke particles to get inside of walls, instead of hugging them. Turns out it was one of the randomness parameters causing this problem. Basically, when laser bolt hits the world, it shoots out sparks, smoke & debris, all created at the collision point.
The position_spread paramter from the text file specifies over how many meters the particles should spread themselves upon creation. Clearly, this should be zero to guarantee a lack of artifacts, because you could end up putting the particles slightly inside the wall where the bolt collided. Once I set this to zero, and changed the smoke sphere collision to use the same collision model as my normal physics spheres, and made sure the collision bounds included both the old & new sphere positions with the radii, all of the embedded smoke issues went away. Whew!
I must say that this is some of the best smoke I've ever seen in real time - it responds to wind, static geometry, and doesn't visually intersect walls or floors, etc.
Later, I may extend it to respond to characters or other movable actors as well.
Here are a few shots of the latest smoke, although it looks way better in action :
This shot shows the smoke conforming to the geometry. The smoke began a bit to the right of the wall opening, at the wall base, right near the debris. Note how the smoke responds to the north-easterly wind and flows through the opening in the wall....
| |
| Wednesday, September 14, 2005 |
| Host Issues | 
Posted - 9/14/2005 10:46:28 PM | I apologize for the lack of pictures - looks like I am having a registrar issue right now with my spies.net domain.
There doesn't seem to be a simple way for me to search & replace my old updates, so I can't easily redirect them elsewhere.
Good progress is being made on many fronts, from art, to physics, to code, and marketing.
Hopefully I can get this problem resolved, and make some more updates soon.
| |
| Tuesday, September 13, 2005 |
| Silver & Gold | |
Posted - 9/13/2005 12:10:28 AM | Silver & Gold
Many months ago I spent several days coming up with a decent way to do specular materials. My old lighting scheme was diffuse only, and things looked quite flat, so I decided to update the material system to support specular, and more specifically, metallic shading.
One interesting thing about metals is they reflect their own light color, rather than the light color coming in, like
plastics would.
So, to get a decent metal, there needs to be some sort of color shift during the lighting computation.
Also, because of the top-down perspective, standard N.H lighting did not look good on the flat surfaces of the floor. Since the floor is 90% of what you see in the game, that wasn't going to work.
Additionally, I didn't want to have to use ps.2.0 hardware in order to do decent looking specular, so I came up with a series of techniques that I feel does a good job with specular materials.
The first thing I did was to change to an N.E lighting model instead of N.H. The N.E model works better on the floor, and
it's also more linear than N.H, so it doesn't wobble as much.
The next thing was to get a stable highlight. The trick here was not to use an exponent, which can't be done well or cheaply
in ps.1.1 hardware, at least if you are trying to do diffuse & specular all in a single pass. The trick was to use the
'bumpheight' scaling of the E vector. A pretty standard tweak to bump mapping allows you to scale the tangent space light
vector ( or in this case E vector ) anisotropically, then renormalize. For instance, you might scale the tangent space Z
direction ( out from the surface ) up to make the surface more flat looking and less bumpy.
Similarly, scaling L.z down then renormalizing, emphasizes any bumps in your surface, because the light more often and
more intensely seems to be coming from the side.
This allows a highlight-type effect with just a simple scale in the vertex shader. I use cubemaps to renormalize my L and E vectors for the lighting.
The next step is to do a color shift necessary to achieve a metallic effect.
I mark the specular sections of the texture in the alpha channel, modulate this by a global reflectivity parameter,
then by half the material's specular color.
Why Half? Well, this is where the color shift comes in. To pass a value to a ps.1.1 pixel shader as a constant, it must
be in the [-1..1] range. If you want a color shift, one way to do it is to do :
color *= { 0.6f, 1.5f, 0.8f };
What this does is to boost the green channel more, while having standard values in the other color channels. In order to
fit values up to 2.0 in the constant, you have to divide your color down by 2, then pass it in, then do an x2 in the pixel shader.
This allows you do to overbright colors in general, and also one type of color shift. A more general solution would have a lookup 3d texture to translate one color to another.
Here are two shots of a statue in silver & gold.
| |
| Monday, September 12, 2005 |
| Small Update | 
Posted - 9/12/2005 1:19:31 AM | Small Update
Just some small tweaks and fixes today. I fixed the entity ambient so it doesn't blink anymore. Turns out I was using one of the functions normally used for the ambient occlusion calculation. Because that function randomized the normal direction for occlusion hemisphere sampling, and this caused blinking. I added an extra parameter than controls the randomness, which the player lighting version turns off.
The randomness is good to add some noise to the sampling in order to break up banding in the occlusion maps with fewer samples.
I also fixed a bug with the decals, and local bounding boxes in general, where the AA bounding boxes would not get recomputed properly after being transformed, but only in the case of an anisotropic scaling.
Tonight I adjusted the spark parameters so that they have less gravity applied and last longer. This helps them show up better.
Additionally, I tuned the glowspheres for explosions and laser bolts to make them brighter.
On the AI front, I added an alertness threshold for the enemies, and now have them pathfind to the last known location of the player if he goes out of LOS. I need to re-write the AI logic for sure, to include sounds, ai->ai communication, etc.
I also turned back on the frame buffer post-processing effect, that really helps to make the screen a bit more alive and colorful, without overdoing it to produce blur-o-vision. It also looks much better with the lasers.
Here is a shot of the post-processing set to a low level :
And a high-level :
| |
| Saturday, September 10, 2005 |
| Sound Sources & Ambient | |
Posted - 9/10/2005 11:13:39 AM | Sound Sources
Yesterday I added static sound sources to the game. The first step was to add them to the editor. I originall had in mind
a fairly complex scheme where each sound was represented by an OOBB. Within the OOBB, a character would hear the sound at
full volume, but outside it, it would hear the sound falloff. Then I realized that this wouldn't give proper panning effects,
and was more complicated than it needed to be.
Rather, I should just allow the level designer to place sound sources as points in the editor. The nearer you are to the point, the louder it is. Large sources, like a river, would need multiple sound sources placed to sound right.
Here is a shot of the 4 sound sources that represent the water.
Once things were working right in the editor, I added the sound sources to the level export process, and added code to read them in to the game engine. The whole thing probably took 4-5 hours of coding & debugging to do, which seems like a lot, and it tempted me to try to make the process easier, but that would undoubtedly take more than 4 hours to change, and chances are I will only need to add one or two more editable objects to the editor and game, and it's not clear how much time another system would save, so it doesn't seem worth the tradeoff.
In the editor, you can scale a sphere that represents the sound range. In the game, however, this value isn't used yet. I'm using FMOD, and treating the sound sources as 3D sounds. This gives the sounds an implicit volume just based on distance. I'm not sure, but I may be able to use the Channel::SetVolume method on top of the default 3D attenuation to adjust it. Another option would be to adjust the position I pass to fmod each frame.
With 3D sounds, you pass in the player location and the sound locations. I update the sound locations every frame, in case they're moving. FMOD does the subtraction to figure out the proper attenuation relative to the listener. If I want to manually force the sound to be quieter, I can move the sound into 'listener space', then scale the position up, then go back into world space, then pass in this virtual sound position.
Ambient Lighting
A while ago I experimented with putting an ambient light grid all through space. This stopped working when I changed my A* implementation, because I was using the 2d grid to store the ambient light info. So, I went back to the old scheme of raycasts, or at least I thought I did. I had a devil of a time getting the latest batch of md2 files into the game such that they weren't too dark. Turns out my ambient was going through the old calculation for the ambient grid and coming up with zero, since the grid was unpopulated. So, I fixed that and put back the old raycast method. Unfortunately, now the enemy characters look washed out.
Here is a shot of my new pillar models, and the washed-out characters :
| |
| Friday, September 9, 2005 |
| Update | 
Posted - 9/9/2005 11:35:30 AM | Lately I've been working on many different aspects of the engine. I tested the new navigation system on the tower level,
to ensure that it could handle the over and under problem. At first it couldn't, but after a few small changes, it started
to work very well.
Here's a shot of my first tower level test :
...and the fixed version :
I'm still having a slight problem at the bottom of stairways. The navigation system often allows AIs to jump off the stairs a bit near the bottom, which is not a problem, but it too often sees this as a two-way link. Making the height tolerance tighter leads to the middle section of stairways getting counted as not walkable. To fix this I might have to take a completely different approach to navigation testing, but seeing how I've already spent way too much time on it, and it does work 99.99% of the time, I may instead be forced to rely on other means.
One option is to have the level editor create the nav map, and optionally display it, and optionally have the ability to edit it. I think an easier option would be to have the editor able to generate & display it, but not directly edit it, instead you can modify the level a bit so that it's not ambiguous.
For instance, one could add a pillar, or post, or some other object or wall to the bottom of a ramp or stair that was large enough to impede walking through. That way, one doesn't have to edit the navmesh itself, which would seem hard to manipulate manually as well as track changes to programmatically.
I've also been working on the AI, which is a bit more of a challenge than perhaps other games, since you can see the enemies all around you, which makes it more obvious than say, a FPS, if they do anything stupid.
I've made a few more fixes to the level editor, like having it track when you've made changes to the level without saving. The physics continues to be a struggle, but progress is being made.
In other news, we now have a talented modeller & animator on board, and my coding partner has signed up to handle the animation system, so we're all very excited to have real artwork in the game.
Here is a shot of the enemies properly persuing me all around the tower level :
| |
Page: 1 2 »»
All times are ET (US) |
|
| S | M | T | W | T | F | S | | | | | | 2 | 3 | | 5 | | 7 | 8 | | | 11 | | 13 | | | | 17 | 18 | | 20 | | 22 | | | | | | | 29 | 30 | |
OPTIONS
Track this Journal
ARCHIVES
December, 2009
August, 2009
July, 2009
June, 2009
June, 2008
May, 2008
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
September, 2005
August, 2005
July, 2005
|
