Jump to content
  • Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

1210 Excellent

About SimmerD

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. SimmerD

    ndotL environment mapping?

    The idea here is twofold : 1) there is a tradeoff between diffuse & specular reflected energy.  more diffuse reflections mean less energy available for specular and vice versa.   2) when N dot L is zero, N.H ( or R.L ) should be zero too
  2. There is Marmalade, which has great Windows Emulation Testing, but even its samples are crashing on Android for me right now. Marmalade has both high & low-level interfaces, including in app purchaes, etc. For android, I am using the free nvidia tegra development kit, which has native visual studio debugging on android devices!  This is only low-level graphics and input. I have also used libcinder on windows, which is low-level also.   I made my engine so I can just write three files, System.cpp and Render.cpp for each platform, and then a main.cpp to drive the update,input and rendering.
  3. SimmerD

    When you realize how dumb a bug is...

    This one is old-skool.   My buddy Brad and I were making an Ultima-style RPG in 1983 or 1984.  It had world maps, dungeons, temples, catacombs, towns, etc.  We were at his place working on the tactical combat.  I was trying to add the fireball spell, and every time I typed in the section of code to handle the fireball hitting an enemy, the entire program would be wiped from memory!  This was sooo bizarre.  Our code was a mix of AppleSoft Floating Point Basic and assembly.   We even went so far as to call Apple to try to report the bug in the Basic code.   While trying to make a smaller repro case than our entire game, we realized the bug.  In AppleSoft Basic, only the 1st two letters of a variable are used, and it's interpreted, so commands are executed as they are parsed.  One of our variables was called FP, which was the command to re-initialize basic, and clear the program from memory.  
  4. My dad brought home an Apple ][+ ( 48k of ram! ) christmas 1982.  He knew COBOL, and taught himself BASIC, and taught my sister and I when I we were 13 & 12.  He made a program with 'for loops' that cleared the screen horizontally.  Then I changed it to make it vertical, then diagonal.  Then I made a sort of tron-light-cycle game.  The next year I met another kid at my school who knew basic.  I had started learning assembly, so we hooked up and made some very innovative half-finished games. We even did digital audio recording through the cassette port & playback through the speaker. We each made flood-fill routines, and also fast 14x14 sprite renderers, and a complete Ultima 3/4 type RPG engine.   I got an austin computers 286 16mhz pc in 1988, and taught myself x86 assembly & EGA/VGA low level rendering.  I made a 3d voxel engine in 1992 all in assembly.  All assembly was really hurting my productivity but MS Quick C was confusing as hell to me.  When a friend taught me Turbo Pascal, I was in heaven, and I shipped my first complete game, Hubie in 1996 using Borland pascal & inline assembly.  That same year I saw a 3dfx voodoo prototype, and started to learn more 3d.  Soon after, I learned Direct Draw, Direct 3D 1 & 3, then started at nvidia, learning direct3d 5/6 and gpu programming in general.  Over the next few years I was in the right place, time & role to innovate in a number of graphics areas, such as per-pixel lighting, attenuation maps, shadows anti-aliasing, etc.   One thing that I did a lot was to lurk in game & graphics programming forums.  I've found need a long gestation period to really grok something, so that helps me by seeing something repeatedly over a long time period.  Then I can connect new ideas with old things I've read about or done.  Another thing I'm learning about myself is that my most innovative periods are tied to meeting and working with new people, so I recommend meeting with like-minded folks. 
  5.   So I am so glad you mentioned this - this means they made a grid that constantly evaluates probes along the viewer's camera? So it is not dependent on probes being constantly used...but rather in the direction the dynamic character faces?   Considering Far Cry 3 is a 1st person game - how does it work when say a 3rd person character walks into a set?   It's not based on direction, but rather position.  One or more nearby probes are read and blended together, depending on the XYZ of the object being rendered.
  6. SimmerD

    Screen-space shadowing

      I like this line of thinking.   You probably don't need 1024 vertical voxels, so it's possible to spend more on horizontal ones, or to store, say a 8-bit distance instead of a 1 bit solid/empty flag.   You could keep two separate voxel structures, the static one, then a dynamic one that is based on slices.  You could sample both of them when required ( when a surface is near a light and a dynamic object ).   You could also do some tricks so that highly dense but noisy things like leaves could be faked and not traced directly, just with an appropriate noise function, say.
  7. This reminds me of Polynomial texture maps.  You can store the coefficients of a quadratic function at^2 + bt + c such that at any time t you can calculate a sunlight value.  This works perfectly as long as you have only two transitions, from dark->light->dark or light->dark->light.  More transitions require more terms.  But for terrain without holes ( like a tunnel or a building with translucent windows ), this should work.   http://www.hpl.hp.com/research/ptm/papers/ptm.pdf
  8. Blade of Darkness was amazing!  I finished that game like 7 times...
  9. SimmerD

    Render Loop Problems DX10, C++

    There could be a ton of things wrong when you get the dreaded black screen. Your cube may be there, but it may be stencil culled frustum culled away from the camera's pos away from the camera's view on another render target the same color as the render target ( ie black ) alpha tested alpha blended fogged ( black )      Things to try : Render the cube, then present(), then immediately render again after changing now state, then present() again. If it's not there, then it may be that your geometry is getting destroyed, or a constant your relied on is gone. If it is there, try adding in parts of the state setting until it disappears again.
  10. Discard only applies after Present() or PresentEx(), not if you copy the back buffer into a rendertarget.   Stretch rect only does a filtered copy, not blending. You will need to write a shader or draw alpha blended quads with the screen buffer applied with DrawPrimitive().
  11. I have made many changes since my last post, mostly in two areas, sound tracing, and NPC crystal usage. The sound tracing is a system whereby I trace sounds from their source, through portals, towards the listener ( usually the player, but sometimes the camera ). When the listener is in a different cell than the source, then the sound appears to come from the portal, rather than the actual sound source. The volume is also attenuated based on the linear distance from the source, to portal -> portal -> listener. There were latent bugs in the sound tracing system that were only exposed when we expanded the 1st level of the game - issues where there were multiple paths from the source to the listener, each one of similar distance. There were some overly aggressive optimizations not to re-consider a cell already considered which were causing shorter sound paths to sometimes not be considered. This caused a sound to be heard when touching the portal, but not heard ( due to being culled ) when just outside the portal. Very distracting. For a while I experimented with disabling the system, and just leaving the sounds at their true source positions, but since the sound tracing feature has been around so long, the levels sounded really bad without it. I ended up making several fixes, each of which would solve another issue, which would expose another bug, some of which were recently introduced. Anyways, right now I believe the sound tracing system is close to bug-free. Another small change I made was to make closed doors muffle sounds, in proportion to how closed they are. A nice effect when you are opening a door into an area. There are many, many gotchas when doing a sound tracing system. Perhaps I will write them up one day. The other change was pretty minor in terms of code, but seems to add proportionally more to the game is the ability of NPCs to use power-up crystals if they have one in inventory. They don't always use them, however, so the player can find some on NPC corpses. At this point, we're just making some minor adjustments and fixing any remaining issues that come up, and then we will release the next version.
  12. SimmerD

    1.2 Almost ready...

    Every time we add a new level, it exposes latent bugs in the code that didn't show up in other levels. We are adding another area to cavecity2 ( the last area of the shareware levels ), and in it is a winding ramp. Going down this ramp caused the camera to jump around in an unusual way that didn't happen anywhere else in the game. Turned out it was the code added a few weeks ago to make sure the player wasn't obscured by something. In this case, the code just snaps the camera to a safe place near the player. It was getting triggered b/c going down the ramp, you tended to get your arms sort of through the wall while your physics capsule was in the right place. This caused enough of the raycasts to fail, triggering the safe area re-set. Just outside the ramp were some black triangles only meant to obscure the mini-map, but that material was set to physically impede the camera, which was causing more issues. Fixing the material and also making the raycasts more bunched towards the capsule rather than the character's visual bounds fixed the issue. The new AI code is working great - the Patrol state, which previously would get put off track rather easily, is working, and we added some debugging to give context when it fails. I added a character speed adjustment to make the walk & run cycles more realistic. Now one of two sine waves are mixed into the movement speed of each character, making for a better looking and more rhythmic movement. Then, I added a bit of camera up/down bob to match for the player, which is subtle but feels better.
  13. As I'm wrapping up the 1.2 Ancient Galaxy patch, I think back on some of the challenges I've had with the AG Engine and why it can be somewhat of a cumbersome codebase to work with - similar to other complex software systems. A largish piece of it is the fact that so many data and logic dependencies in the engine and game become implicit, and not articulated in any sort of manner that can be automatically checked ( like by the compiler, for instance ). I been thinking one way to improve things would be to add explicit dependencies into the core of an engine, as a fundamental concept. A limited version of this would be ref-counting, where you at least prevent pulling an object away from another that's using it, although there are no guarantees w.r.t what state the object might be in. Rather than ref-counting, which only tells you how many folks care about you, you might do reference linking, where you have a pointer back to the interested parties. With this you can create a rudimentary subscription ( or signal/slot ) model. The next step would be to have an all-seeing, all-knowing subscription manager class that could manage subscriptions, something like this : struct Subscription { enum NotifyType { ntNone = 0x0, ntRead = 0x1, ntWrite = 0x2, ntConnect = 0x4, ntDisconnect = 0x8, ntFrame = 0x10, ntPause = 0x20, ntUnPause = 0x40, ntCreate = 0x80, ntDestroy = 0x100, ntUpdate = 0x200, ntSceneAdd = 0x400, ntSceneTraverse = 0x800, ntSceneRemove = 0x1000, ntContact = 0x2000, ntTrace = 0x4000, }; enum NotifyWhen { nwPre = 0x0, nwOn = 0x1, nwPost = 0x2 }; uint32 _datum_id; uint32 _scope; uint32 _flags; uint32 _subscribee; std::vector< uint32 > _subscribers; // can hold history here, rather than in subscriber or subscribee Datum::Value _history[ 16 ]; class Mgr { std::map< uint32, Subscription > _subscriptions; public : typedef void (__cdecl* Notify )( ( const Datum* const pDatum, const Subscription* pSubscription, const uint32& notify_type, const uint32& notify_when, const int32& datum_age ); One potentially interesting idea possibly beyond a standard signal/slots mechanism is the history, which can include the previous values of the data, for weapon trails, interpolation, etc. It could also be useful for futures and reading 1-frame behind data. You would subscribe to history -1 for the last frame, choose 0 for this frame, etc. I also like the separation of the Pre/On/Post flags from the subscription type. That way any subscription type can be combined with the Pre/On/Post flags to allow you to hook in where you need to. The scope value is there as a differentiator, for instance, an object may get added to multiple scenes, so you could have different scopes that would have separate subscriptions. It seems this would allow things to be more data-driven, which can be good, but also places a larger burden on having tools to display & manipulate these dependencies...
  14. SimmerD

    AI & Camera Tweaks

    Made some more AI tweaks. The AI NPCs now will investigate a suspicious sound, and track the average location of various dangerous sounds they hear over time. This is known as the 'seeking' state. This makes them gang up on the player, sometimes way too much, so I added a quota so that only so many guys can be seeking the player at one time - right now this is set to 4. Now, other NPCs can be attacking the player at once, but only 4 can be seeking him out. Also, the enemies are more apt to detect the player's disguise when in Seeking state. In addition, I added a little bit more camera physics. There was one case where the camera wasn't acting like a physical sphere, and it rarely caused the camera to move outside of the level. The camera now acts like a ~1.5 meter radius sphere that tries to stay at an ideal user-tweakable player-relative position. It moves around physically, except if the player is completely hidden from view, in which case it 'cuts' right behind the player, then resumes it's physical sphere status. This is cut behavior very rare, but prevents much worse cases of the camera sphere getting stuck somewhere on the level and the player's character just wandering off.
  15. SimmerD

    Sound Paths

    Ran some in-game profiling over the past couple of days and found sound pathing tracing taking more time than I'd like. Ancient Galaxy has a system to trace sounds from their source through portals into other cells, and then to the listener itself. This has the effect of making sounds appear to come through portals rather than a straight shot from the sound source if the listener is at least one room away from the sound. It works really well most of the time, but can be a bit expensive to trace the sound paths from room to room every so often. I was considering adding a precomputed data structure to speed this up. Basically the sound path goes SoundSource->Portal->Through Cell->Portal->Through Cell->Portal->Listener The paths are re-computed every so often, if the sound source moves or the sound is a looping sound. I realized, though, that only the SoundSource->Portal and Portal->Listener parts need to be recomputed. The interior part, which could be 7-12 rooms longin some cases, doesn't need to be recomputed, and could actually be cached or completely precomputed. Each Cell or Portal could store its potentially connected portals, up the the limit of some level-specific sound distance cut-off. That way, only the ends of the sound path would by dynamic. It turned out, though, that looped sounds were getting recomputed every frame, rather than only several times per second, so after fixing that, it doesn't look like I will need to speed things up any further in this regard. In the future, I'd like to revisit this part of the engine and add environmental effects. Also sped up the particle system, a couple of camera tweaks, and confirmed that the re-factored AI is still working well...
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!