Re: [palito-dev] Re: New renderer

[Tom Barnes-Lawrence]

Hurrah! Someone's looked at it.

On Mon, Jul 07, 2003 at 01:50:16AM -0200, address@hidden wrote:
> 
> good, you are going through an interesting path..
> .. even if this code cant be used in realtime, 
> it can generate the images on the begining of the game.

 Yup, that was the general idea. Whether maps are generated randomly
each time, or put together from tiles, or a combination of both, it
could be included with the game to be run on the heightfields.

 Even if the game comes with its own hand-made heightfields, there would
be an advantage in creating the map images when they're needed: I tried
downloading one of the map packages before I made this renderer, and
realised I had to convert the PNG file to BMP for it to load. It was
HUGE! Now imagine having lots of those BMP files... So generating these
images only when they're needed could be a good idea.

 Also shows, saving *memory* might not be so much reason to use
tiled maps... but saving disk space and *download size* might be.

> i think that it would be nice to have some simple shadows worked on.. 
 Yeah, I'd been thinking about that a couple of days ago. I'd been
thinking of using the heightmap with another program to produce a
simple bitmap- as in one bit per pixel, where on-pixels would be not
in shadow, and off-pixels would be in shadow.
 Then the main renderer could reuse that data- if using tiled maps,
you could bundle tiles as raw heightfield data, and that data could
be rendered with lots of different texturing functions to give the
appearance of different worlds like in TA. The renderings would change,
but having the same heightmaps, they'd also have the same shadows.
Unless it becomes possible to change the lighting direction...

> you know, it can be very simple.. you use an accumulator for the actual height
> of the shadow.. while it is higher than the field height there is shadow,
> and the accumulator is reduced by a factor that should represent the slope 
> of the light source; when the field is higher, the is no shadow, and the
> acumulator is set to the height of the field.
  Ah, I finally get what you mean. I didn't think of it like that. But
I don't know if that's possible when the light direction is a vector.
Maybe it is...

> it can be blended with the normal shading, making the field even darker
> on the most accentuated slope behind a hill.
  I figured that doing serious shadows, with penumbras, would be incredibly
processor-intensive. So I figured plain shadows that are just points where
the *direct* light source is blocked out. So actually, those points would
be exactly the same illumination as where the surface is pointing away from
the light. It would have just ambient lighting, no brighter, no darker.

> maybe it all can be set through parameters (ambient light, diffuse shading, 
> weight of the shadow blending, etc...)
 I was planning to make most of these things configurable to some extent.
Many such things are described in the TODO file.

> btw, i think that the Lua dependence is not a good thing, maybe you can use
> palito's flush-code to implement your parameters..
 Hmm, I thought a bit about using flush, but I figured it wasn't quite
suitable for doing everything (it does seem to do graphics well). For
a start, I need to export C callbacks to the texturer functions. I don't
think Flush can do that without hard-coding the functions in.

 I was initially thinking about using Guile, as Lambda Calculus makes
Scheme programming pretty powerful... but I'd forgotten how stupidly
out-of-date and incomplete its documentation is. So I looked at different
choices, and Lua seemed a good bet.

 Most Linux users have Perl and Python, but most Windows users *dont*, and
they're really big packages for them to have to download to be able to
use IWR or Palito. Lua, OTOH, is *tiny*. Some programs (like Zangband)
include it in their own download packages!

> i tried lua-5.0 and it didnt worked, then lua-4.0.1 and also failed to 
> compile.
> even making symlinks to liblua40 and liblualib40
 Ah. I remember trying to use Lua programs before, turned out that Debian
installed Lua differently to everyone else (I have Debian), so I had to
change the include paths for those programs. But I don't remember where
most other distros put them, so the makefile is likely only right for
Debian systems. This whole issue seems to be the worst part about using
Lua, which is annoying.

 It would help if you said what actually happens when it doesn't compile!
If Lua's headers aren't in /usr/include/lua40/ then let me know where
they are, and change the INCLUDES line in IWR's Makefile to suit it.
 If it's some other problem, then tell me what it is!!!

 Tomble