Only 64x more polys?!?! awwwwww! =))
heheh sounds great....
In my opinion though, textures need the most work in marathon, i dont really
know if its that the data files don't support really high quality textures,
or if its just because no one used higher quality textures because of
"Happiness is in a fast Mac" -Loren Petrich
He'z Right ya know ;) Long live the Macintosh!
> From: Simon Brownlee <simon.brownlee@...>
> Reply-To: marathon-devel@...
> Date: Mon, 21 Aug 2000 11:37:33 +0200
> To: marathon-devel@...
> Subject: Re: [M-dev] A1 Map Tools
> ashnfara wrote:
> Cool, i cant wait for a build... I was scared that there would be no
> aleph one compatible map editor for a LONG time into the future.
> Going back to a question I asked on the official maps thread; will
> we see larger map sizes Simon? I understand now that we will have to make
> do with the 1024 polygons, but still, polygons can be any size and a
> desert scene or an outerspace scene would require a larger map
> The Marathon map format specifies all distances as type
> 'world_distance' which is currently defined as a 2 byte integer.
> Changing this to a 4 byte integer would allow for bigger map sizes
> (4194304 world units), but would completely break backwards
> compatibility with all old maps and map making tools. If we really
> wanted to do this, we could alter the engine so that it uses 4 byte
> ints internally, but could read from map files with the old 2 byte
> specification (we'd just increment the version number in the map file
> spec to specify maps with 4 byte integer world_distance).
> The downside to this would be higher memory requirements, and
> probably slowing the engine down a little. The slow down shouldn't
> be too bad as we're no longer supporting 68k machines, and PowerPCs
> can do 4 byte int operations as fast as 2 bytes.
> As for the polygon count, I believe this could be increased fairly
> easily. The map specs always specify polygon indexes as 2 byte
> integer so would allow 32768 (maybe 65536) polys without breaking. I
> haven't looked for problems with increasing the poly count in the
> actual engine code, but I wouldn't think there was anything that
> couldn't be easily resolved.
> The downsides here would again be loss of backwards compatibility
> with old map tools and original M2/Infinity apps, and slowdowns
> caused by people making maps with 64 times more polys than now ;-)
> Marathon-devel mailing list