Aleph One: Marathon Open Source

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
computer requirements....


Later,
-Crusher4

--------------------------------------
"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
> boundary.
> 
> 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
> Marathon-devel@...
> http://lists.sourceforge.net/mailman/listinfo/marathon-devel

>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).

	Actually, some of the geometry calculations are already being 
done in 4-byte form; that's why the distance restrictions are now 
gone.

>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.

	I agree. it's a somewhat arbitrary limit, which could easily 
be increased if desired.
-- 
Loren Petrich -- petrich@...
http://www.petrich.com/home.html
Happiness is a fast Macintosh
And a fast train

>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
>computer requirements....

	The data files support 8-bit indexed-color textures only, 
with lots of color ramps. That's because lighting effects are done by 
sliding down those ramps.

	However, OpenGL mode frees us from those constraints, and it 
is certainly possible to store textures as image files, read them in, 
and substitute for shapes-file textures.

	Would you people wish for me to try to implement that?
-- 
Loren Petrich -- petrich@...
http://www.petrich.com/home.html
Happiness is a fast Macintosh
And a fast train

> 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 ;-)

    Yeah, but 64 times more polys...  aalllughaululahgahh... (my best Homer
impression....)  I couldn't wait to see some maps with an increased count
like that...

David

In a message dated 8/21/00 6:30:10 AM, petrich@... writes:

<<  The data files support 8-bit indexed-color textures only, 
with lots of color ramps. That's because lighting effects are done by 
sliding down those ramps.

    However, OpenGL mode frees us from those constraints, and it 
is certainly possible to store textures as image files, read them in, 
and substitute for shapes-file textures. >>

also to up the quality a tad bit, you could use custom color tables like in 
the landscape and guns collections...

/X\--MX--/X\
Don't triffle with me. I have a shotgun, a shovel and 6 acres behind the house
...
∞~~§¥§† xßÅÿxƒ~~∞

>	The data files support 8-bit indexed-color textures only, 
>with lots of color ramps. That's because lighting effects are done 
>by sliding down those ramps.
>
>	However, OpenGL mode frees us from those constraints, and it 
>is certainly possible to store textures as image files, read them 
>in, and substitute for shapes-file textures.
>
>	Would you people wish for me to try to implement that?

Hell yes! what would the upper limit on texture dimensions and bit 
depth be if we did this? And would they apply to the same spaces, or 
be stretched so that they appear at the same resolution? I vote for 
applying them to the same spaces, although this might look very funny 
if you have a 512x512 texture next to a 128x128 one....
-- 

Mike Melvin - mailto:eleven38@...

"There are obviously many things which we do not understand,
and may never be able to."
[Leela, Ship Operations AI, UESC Marathon]

on 8/21/00 2:59 AM, Crusher 4 at crusher4@... said:

> 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
> computer requirements....

It is because Anvil and Forge force the texture designer to 256 colors for
the whole game and 128 X 128 pixel images. I have managed to use a custom
color table making the game have more than 256 colors and create a map with
it, but it requires two versions of the shapes files and two versions of the
textures more or less just to be able to see which texture is which in
Forge. I got tired of struggling with it. We need a map editor that doesn't
force the textures to 256 colors.

-- Candy
___________________________________
      sherriff@...
       shebob@...
     
    http://www.shebob.com
___________________________________

Shebob wrote:
> 
> on 8/21/00 2:59 AM, Crusher 4 at crusher4@... said:
> 
> > 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
> > computer requirements....
> 
> It is because Anvil and Forge force the texture designer to 256 colors for
> the whole game and 128 X 128 pixel images. I have managed to use a custom
> color table making the game have more than 256 colors and create a map with
> it, but it requires two versions of the shapes files and two versions of the
> textures more or less just to be able to see which texture is which in
> Forge. I got tired of struggling with it. We need a map editor that doesn't
> force the textures to 256 colors.
> 
> -- Candy
WOW! how did you do that?!  I mean you put 16 bit bitmaps into the
shapes file and used a 8 bit counterpart shapes file to texture stuff in
forge?  Thats a great tepomory fix for the texture quality issue, howd
you do it!
-Sean

>
>	Would you people wish for me to try to implement that?
>
Yes!!

At last!!
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

In a message dated 8/21/00 5:00:39 AM, crusher4@... writes:

<< 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
computer requirements....
 >>

Maybe if more than 72X72 PSI textures were supported, you could have high 
quality textures. That sound feasable?

maybe Alpha channels as well, instead of the chromakey stuff?

could save the images as PNG format, maybe? (that way you don't need to have
two files for every texture)

> From: Loren Petrich <petrich@...>
> Reply-To: marathon-devel@...
> Date: Mon, 21 Aug 2000 03:29:54 -0700
> To: marathon-devel@...
> Subject: Re: [M-dev] A1 Map Tools
> 
>> 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
>> computer requirements....
> 
> The data files support 8-bit indexed-color textures only,
> with lots of color ramps. That's because lighting effects are done by
> sliding down those ramps.
> 
> However, OpenGL mode frees us from those constraints, and it
> is certainly possible to store textures as image files, read them in,
> and substitute for shapes-file textures.
> 
> Would you people wish for me to try to implement that?
> -- 
> Loren Petrich -- petrich@...
> http://www.petrich.com/home.html
> Happiness is a fast Macintosh
> And a fast train
> 
> _______________________________________________
> Marathon-devel mailing list
> Marathon-devel@...
> http://lists.sourceforge.net/mailman/listinfo/marathon-devel

A number of other files have alpha channels as well... The one I remember
best is TARGA (Which is used in a few games I know of one is ID Software's
Quake 3) though I don't know what is best I do hope that texture size and
color are upgraded in the near future.

Later,
-Crusher4

--------------------------------------
"Happiness is in a fast Mac" -Loren Petrich
He'z Right ya know ;) Long live the Macintosh!


> From: Alex Montgomery <traxus@...>
> Reply-To: marathon-devel@...
> Date: Tue, 22 Aug 2000 01:24:45 -0400
> To: <marathon-devel@...>
> Subject: Re: [M-dev] A1 Map Tools
> 
> maybe Alpha channels as well, instead of the chromakey stuff?
> 
> could save the images as PNG format, maybe? (that way you don't need to have
> two files for every texture)
> 
>> From: Loren Petrich <petrich@...>
>> Reply-To: marathon-devel@...
>> Date: Mon, 21 Aug 2000 03:29:54 -0700
>> To: marathon-devel@...
>> Subject: Re: [M-dev] A1 Map Tools
>> 
>>> 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
>>> computer requirements....
>> 
>> The data files support 8-bit indexed-color textures only,
>> with lots of color ramps. That's because lighting effects are done by
>> sliding down those ramps.
>> 
>> However, OpenGL mode frees us from those constraints, and it
>> is certainly possible to store textures as image files, read them in,
>> and substitute for shapes-file textures.
>> 
>> Would you people wish for me to try to implement that?
>> -- 
>> Loren Petrich -- petrich@...
>> http://www.petrich.com/home.html
>> Happiness is a fast Macintosh
>> And a fast train
>> 
>> _______________________________________________
>> Marathon-devel mailing list
>> Marathon-devel@...
>> http://lists.sourceforge.net/mailman/listinfo/marathon-devel
> 
> 
> _______________________________________________
> Marathon-devel mailing list
> Marathon-devel@...
> http://lists.sourceforge.net/mailman/listinfo/marathon-devel

>>	However, OpenGL mode frees us from those constraints, and it 
>>is certainly possible to store textures as image files, read them 
>>in, and substitute for shapes-file textures.
>>
>	Would you people wish for me to try to implement that?


>Hell yes! what would the upper limit on texture dimensions and bit 
>depth be if we did this? And would they apply to the same spaces, or 
>be stretched so that they appear at the same resolution?

	The bit depth could be full 24-bit, and the size could be as 
big cas can reasonably fit.

	The texture would extend over the same extent, however; a 
bigger texture will have higher resolution, but will still spread 
over 1 WU * 1 WU.
-- 
Loren Petrich -- petrich@...
http://www.petrich.com/home.html
Happiness is a fast Macintosh
And a fast train

Sounds Great! I for one think that will make Aleph One really shine over
Marathon oo.  Approximately how long do you think this will take to
implement?

Later,
-Crusher4

--------------------------------------
"Happiness is in a fast Mac" -Loren Petrich
He'z Right ya know ;) Long live the Macintosh!


> From: Loren Petrich <petrich@...>
> Reply-To: marathon-devel@...
> Date: Mon, 21 Aug 2000 23:29:38 -0700
> To: marathon-devel@...
> Subject: Re: [M-dev] Custom Textures!
> 
>>> However, OpenGL mode frees us from those constraints, and it
>>> is certainly possible to store textures as image files, read them
>>> in, and substitute for shapes-file textures.
>>> 
>> Would you people wish for me to try to implement that?
> 
> 
>> Hell yes! what would the upper limit on texture dimensions and bit
>> depth be if we did this? And would they apply to the same spaces, or
>> be stretched so that they appear at the same resolution?
> 
> The bit depth could be full 24-bit, and the size could be as
> big cas can reasonably fit.
> 
> The texture would extend over the same extent, however; a
> bigger texture will have higher resolution, but will still spread
> over 1 WU * 1 WU.
> -- 
> Loren Petrich -- petrich@...
> http://www.petrich.com/home.html
> Happiness is a fast Macintosh
> And a fast train
> 
> _______________________________________________
> Marathon-devel mailing list
> Marathon-devel@...
> http://lists.sourceforge.net/mailman/listinfo/marathon-devel

on 8/21/00 1:41 PM, ashnfara at ashnfara@... said:

> WOW! how did you do that?!  I mean you put 16 bit bitmaps into the
> shapes file and used a 8 bit counterpart shapes file to texture stuff in
> forge?  Thats a great tepomory fix for the texture quality issue, howd
> you do it!
> -Sean

Not really 16 bit, I just have more than 256 colors. I created new ramps
with M2/Mƒ CLUT Modifier and installed that set of color tables into one
shapes file and left the color tables as they are for the Forge version of
the shapes. Forge is really ugly and it is hard to see what sort of shading
is going on.

--Candy
___________________________________
      sherriff@...
       shebob@...
     
    http://www.shebob.com
___________________________________