• Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


Long time, no update.

Progress is being made. So many changes and fixes since the last update, not sure where to begin.

I solved an interesting issue with the portal system today. This has been an issue in the back of my mind for a while, but I finally figured out a solution today.

What you see here is an overview of one of our mayan-themed levels. The blue cubes are cells, and the green quads are portals. In the middle-left of the screen there is a chunk of background mountains.

The problem with these mountains, meant to be seen from all over the level, is that it is not in any cell. The portal culling system works by finding the cell or cells containing the camera, then proceeding through visible portals into other cells, adding them to the visible cell list.

Then the visible cell list is potentially reduced by anti-portals.

During rendering, a chunk of world geometry or an object is tested to see if it touches at least once cell. If not, it is not drawn.

With this scheme, outlying objects not in any cell, or not in a cell connected via a series of portals to the camera cell are culled.

I first considered tagging background meshes such that they wouldn't be portal culled, but that seemed a bit of a hack, and wouldn't scale nicely to other things like entities.

Instead, I was going to define a new class of cell, called a Visibiliy Cell. The idea is that a Visibility Cell would only be tested via the view frustum and anti-portals, and not be culled based on portals at all. Putting a Visibility Cell around the mountain chunks would prevent them from disappearing from view.

Because I'm using the incredibly poor Managed C++ from vs7.1, I dread going into the level editor and making changes needed to make a new cell type, so I thought of a simpler way - simply find any cells with no portals attached, and treat them as the VisibilityCells.

Only took a few minutes to fix once I had the idea...

A partial list of things fixed since last update :

Dual-weapon support
Both the player and enemies can have two distinct weapons at once

Attachment scaling
Weapons can now be scaled to match up to the dude holding them

Better laser-sight jitter

Yet more fixes to the physics lerping system

Physically reactive vines that drive a skeletal vine mesh
(also could be used for cloth, plants, etc. )

Many design items finalized

Code to compute formulas from .csv files for RPG system

In-game UI designed

RPG system semi-finalized

Sign in to follow this  


Recommended Comments

Guest Anonymous Poster



Because I'm using the incredibly poor Managed C++ from vs7.1, I dread going into the level editor and making changes needed to make a new cell type,

I know exactly what you mean! ;-)
I have the same syndrom with a commercial program that we did in managed C++ due the ease of Windows.Forms...

Remarkably its exactly the opposite feeling when I mess around with the other projects (which are all heavily boostified, clean C++).

Share this comment

Link to comment
The rooms are not all square in general, but we are trying a new prefab-type approach to level building to cut down on time by improving re-use.

The cells themselves are bounding boxes, but they don't have to be axis-aligned, although they are more efficient if they are.

Share this comment

Link to comment
Cool, now I saw your update I recalled that I dreamed that I was playing your game. Neat.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement