FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: Proposing new rendering algorithm  (Read 3004 times)

eefano

  • Guest
Proposing new rendering algorithm
« on: June 10, 2008, 08:34:23 am »


(See attached image)

I've decided to go further my 2 cents in previous post
and propose a slightly modified approach to
software rendering:

Imagine to split the static world in a grid
of "screen quarters" (1/4 of a video screen area)

The procedure would be like:
starting from the quarter where the camera
is pointed  (begin game or change view)

- render the quarter where the camera is and the 8 adjacent quarters

- if the camera origin crosses the quarter boundary
  > free the quarters at least two lenghts away from the new camera quarter
  > render only the new adjacent quarters
   
Worst case: 
max16 quarters to keep in memory at the same time (4 screens)
max5 quarters to render only when camera origin hits a boundary
(excluding the 9 quarters at the beginning)

-the final resulting screen is composed
 by fast blitting the portions of visible quarters for every frame.
       
       
Adding sprites/animations:

- a Z buffer must be rendered for each quarter to draw
  sprites according to the layered world.
   
   I suggest a 16-bit z buffer, with 10 bytes used by the depth
   (10^2 = 1024 the height of the best screen resolution around)

   6 bits can be used as some sort of transparency color palette
   (window glasses!!) or   to codify some other effects on the static world.
   
   
- for each sprite that appears visible (Z-sort first!) :
  >save somewhere the portions of quarters involved by the sprite bounding box
  >blit accordingly to Z-buffer and the Z global value of the sprite
 
- the GUI windows,cursors,etc can be considered sprites as well and blitted
  with the maximum Z value.

- before starting a new frame rebuild the messed up quarters' portions


Final Considerations:
         
Pros: surely higher average framerate

-you don't have to do layer culling every frame
-when the camera goes back and forth the same quarter boundary,
   no extra rendering is required.
- the procedure can be adapted to existing rendering routine
  without not too much pain

Cons: memory consumption.

-you'll need to keep at least 4 screens and relative z-buffers in memory.
      You may consider to not go beyond 800x600x16bit resolutions.
     
     
 Let me know what do you think!

eefano
Logged

phoku

  • Developer
  • Full Member
  • *
  • Posts: 102
    • View Profile
    • IZ dev blog
Re: Proposing new rendering algorithm
« Reply #1 on: June 10, 2008, 09:18:18 am »

Sounds interesting and reminds a bit of the original fallout rendering.

Please write a reference/demo implementation :)
Just plain C++/SDL should be enough.

I'm really interested in the impact of having to access the zbuffer.

-phoku
Logged

m64

  • Developer
  • Newbie
  • *
  • Posts: 22
    • View Profile
Re: Proposing new rendering algorithm
« Reply #2 on: June 10, 2008, 01:06:59 pm »

Does SDL support Z-buffer? Or are you thinking about software implementation? I hope it won't be slow like hell.
Logged

Sleek

  • Developer
  • Jr. Member
  • *
  • Posts: 57
    • View Profile
Re: Proposing new rendering algorithm
« Reply #3 on: June 10, 2008, 10:00:17 pm »

About the screen quarters, sure. We will need some kind of scroll buffer. The link http://wiki.allegro.cc/Pixelate:Issue_1/Tile_Maps explains the pre-concept. We have a buffer larger than the screen size, then fast blit the visible portion of the screen surface, and fast blit the new visible rect from our buffer. IMHO we don't even need to split the screen into sectors/quadrants, but it's more organized using your idea.

I agree with reducing the alpha-transparency bit size. We don't need 255 distinct values. Even 10 is enough. Make it 2^4bit : 16. 2^5bit is luxury already. We did think of making terrain fringes that utilizes full alpha-transparency : http://www.gamedev.net/reference/articles/dino/fringe_example.gif.. but for this one we can prerender the required image for each map and convert it to opaque display format.

I might be missing something here about the z-buffer. But isn't that overkill ?
Logged

EonDigital

  • Newbie
  • Posts: 5
    • View Profile
Re: Proposing new rendering algorithm
« Reply #4 on: August 11, 2008, 07:40:44 pm »

Nice idea, but I foresee two problems with it that should be noted.

1. If you have tall objects, they need to exist on the tiles they actually overlap, and may not correspond to the tiles they tower out of.  If you don't do this, they may disappear when their base is hidden from screen.  An example of where this might matter is in fourside from earthbound, where you have buildings many screens tall that you can walk behind.

2. If you have fast moving objects that can clear several world tiles in a single motion (e.g. you fire a missile or something, and want to track it with the camera) it could result in some extra loading that is unwanted.  This was a problem that could be triggered in Morrowind, which used a tiled world for rendering regions of 3D with no loading time/load zones (with the exception of going in/out doors).

Still, breaking a scene into world tiles has been very useful for speeding up a lot of processes like this, and hiding load times in games where the world size can be quite massive.

If you're interested in seeing documentation related to this, do a search for portals with regard to 3D gaming.  This is different from the kind you find in quake and portal, but basically is a limitation of what is rendered on a screen from a certain view.  Will probably get you close to related info.
Logged