Re: [Arianne-general] Terrain v0.0.1

[Alex S. <sc...@at...>]

Kevin,

   I'm not sure what platform you're running on, but one more thing you 
(and others) may want to note - sinf, cosf, sqrtf are SGI extensions 
and are not ANSI or POSIX compliant, which may cause portability 
problems.

Adding this should work (ANSI and POSIX sin/cos/tan are double 
precision floats, I'm pretty sure):

new file mathext.h
#ifndef sinf
#define sinf sin
#endif
#ifndef cosf cos
#define cosf cos
#endif
#ifndef sqrtf
#define sqrtf sqrt
#endif

in main.cpp, utility.cpp, roam.cpp
#include "mathext.h"

I now get a seg fault, but I suspect there's probably an endian problem 
somewhere (I'm on a big endian machine).  I'll try to figure it out 
later.  fyi I'm getting an EXC_BAD_ACCESS, Could not access memory. 
0x000048a0 in loadTerrain(int, unsigned char**) (size=512, 
dest=0x9b1a4) at utility.cpp:261
   The only strange thing is that endian probs usually end with garbled 
graphics with OpenGL, not segv's.


   I'm not quite sure if I understand your explanation of ROAM but I 
suspect that you're talking about taking either an ARGB and using the 
alpha channel for height, or an RGB file and using R for height and GB 
becomes a 6-6-4 (or similar) RGB scheme (the eye is least sensitive to 
changes in blue light, so it often gets less info).

   I've been interested in looking at the terrain and exercising a 
couple of ideas I've had for a terrain engine in a demo, but have been 
mostly spending my last few weekends and evenings porting to macosx 
(newarianne was easy, some of the supporting libs - like plib - have 
some problems).

   I've written a couple of terrain engines in the past (for pretty 
basic flight sims), but these were all a grid and height map.  I also 
only had 255 heights, but the heights weren't linear - they were hashed 
into an exponential table for their actual heights.  Yes, I said 255 
values - 0 was a special value - it meant an object went on top and to 
skip any polies through there.   This made it possible to put canyon 
walls and other vertical surfaces in, as well as other higher polycount 
objects and concave surfaces - they just weren't part of the core 
terrain engine, they were part of a thing I called the object engine.  
My terrain engine worked pretty good, but I made the mistake of using 
virtual functions in the object engine (I was just learning C++ at the 
time, and didn't know of the nasty speed hit from the table lookups), 
which made that part horribly broken from a speed standpoint.  I may 
have an idea to optimize this to allow non-gridded terrain, but I have 
to think it through more (one restriction in my new idea would be no 
completely vertical surfaces, though, because height would be a key 
value, but other than that it is a meshed surface with no fixed x or y 
values).

   When I was working on my engine, I was using multiple files instead 
of using part of an image file.  Are there any real advantages to doing 
it that way (aside from convenience)?

On Wednesday, April 23, 2003, at 02:11 PM, Kevin Lyons wrote:

> Peter Holko wrote:
>> Hey Kevin,
>> I'm getting a HTTP 404 Page Not Found for the link to the zip file of 
>> the
>> source.  Just wondering if the link is dead?
>
> Heh, no, I just can't type today =P
> Should be fixed
>
> -- 
> "In Ghat they believe in vampire watermelons, although folklore
>  is silent about what they believe about vampire watermelons.
> Possibly they suck back."
>                                - Terry Pratchett, Carpe Jugulum
> Kevin M Lyons - Programmer - Nebrask@ Online <ke...@no...>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Arianne-general mailing list
> Ari...@li...
> https://lists.sourceforge.net/lists/listinfo/arianne-general
>