Aleph One: Marathon Open Source

That's not RC1.

Gregory

On Apr 22, 2006, at 6:08 AM, Bill Catambay wrote:

> In switching from one level to the next, I got an unexpected crash  
> right after the chapter screen of the following level but before  
> the level began loading.  Crash log is below:
>
> Host Name:      Bills-Starbase
> Date/Time:      2006-04-22 03:03:59.015 -0700
> OS Version:     10.4.5 (Build 8H14)
> Report Version: 4
>
> Command: AlephOne
> Path:    /Volumes/Camelot/GM4/EMR OS X/EMR 3.0b8.app/Contents/MacOS/ 
> AlephOne
> Parent:  WindowServer [58]
>
> Version: Aleph One 0.15.0 (3.0)
                                        ^^^^^^

Well, it was either RC1 or one you sent me, which was based on RC1. 
Date is 4/9/06.  The only reason the Version stuff is wrong below is 
because I replaced the Info.plist file.


At 8:34 AM -0400 on 4/22/06, Gregory Smith wrote:


>That's not RC1.
>
>Gregory
>
>On Apr 22, 2006, at 6:08 AM, Bill Catambay wrote:
>
>>In switching from one level to the next, I got an unexpected crash 
>>right after the chapter screen of the following level but before 
>>the level began loading.  Crash log is below:
>>
>>Host Name:      Bills-Starbase
>>Date/Time:      2006-04-22 03:03:59.015 -0700
>>OS Version:     10.4.5 (Build 8H14)
>>Report Version: 4
>>
>>Command: AlephOne
>>Path:    /Volumes/Camelot/GM4/EMR OS X/EMR 3.0b8.app/Contents/MacOS/AlephOne
>>Parent:  WindowServer [58]
>>
>>Version: Aleph One 0.15.0 (3.0)
>                                        ^^^^^^


-- 

Bill Catambay                
The Marathon Map Makers Guild
mailto:trex@...                  
http://excaliburworld.com/emr/

See if it happens with the real, unaltered RC1, from my site. The  
crash report should be more useful.

Gregory

On Apr 22, 2006, at 2:09 PM, Bill Catambay wrote:

> Well, it was either RC1 or one you sent me, which was based on RC1.  
> Date is 4/9/06.  The only reason the Version stuff is wrong below  
> is because I replaced the Info.plist file.

On 4/21/06, Larson, Timothy E. <TELarson@...> wrote:
> How about compiling with aalib graphics?  Would that help get framerates
> up?  :D
It would, actually, but try reading terminals that way. :P
-:sigma.SB

Uh, should we fix that?

Or should it stay that way for compatibility...

Gregory

On Apr 18, 2006, at 10:46 PM, Forrest Cameranesi wrote:

> So, a long while back I wrote in reporting that "texture"  
> replacement for the HUD elements via MML wasn't working, and was  
> giving very strange results that I couldn't for the life of my  
> decipher (non-random garbage images clearly derived from my  
> replacement images showing up where the proper replacements should  
> be).
>
> I just figured out what the cause of that was. Apparently,  
> replacement images for the HUD must be flipped horizontally and  
> rotates 90 degrees counterclockwise in order to appear as they  
> should in the HUD.
>
> Just thought everyone would like to know...
>
> -Forrest Cameranesi, Geek of All Trades
> "I am Sam. Sam I am. I do not like trolls, flames, or spam."

I think it should be fixed.  I think that Forrest is probably the 
first (and only) one who figured out the "trick" to make it work. 
Fixing it now would only mean that Forrest would have to undo the 
trick (and he probably hasn't done them all yet).

I tried to do HUD replacement textures last year, but when they 
didn't appear to work, I gave up.

At 10:52 PM -0400 on 4/18/06, Gregory Smith wrote:


>Uh, should we fix that?
>
>Or should it stay that way for compatibility...
>
>Gregory
>
>On Apr 18, 2006, at 10:46 PM, Forrest Cameranesi wrote:
>
>>So, a long while back I wrote in reporting that "texture" 
>>replacement for the HUD elements via MML wasn't working, and was 
>>giving very strange results that I couldn't for the life of my 
>>decipher (non-random garbage images clearly derived from my 
>>replacement images showing up where the proper replacements should 
>>be).
>>
>>I just figured out what the cause of that was. Apparently, 
>>replacement images for the HUD must be flipped horizontally and 
>>rotates 90 degrees counterclockwise in order to appear as they 
>>should in the HUD.
>>
>>Just thought everyone would like to know...
>>
>>-Forrest Cameranesi, Geek of All Trades
>>"I am Sam. Sam I am. I do not like trolls, flames, or spam."
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Marathon-devel mailing list
>Marathon-devel@...
>https://lists.sourceforge.net/lists/listinfo/marathon-devel


-- 

Bill Catambay                
The Marathon Map Makers Guild
mailto:trex@...                  
http://excaliburworld.com/emr/

On Apr 18, 2006, at 8:00 PM, Bill Catambay wrote:

> I think it should be fixed.  I think that Forrest is probably the  
> first (and only) one who figured out the "trick" to make it work.  
> Fixing it now would only mean that Forrest would have to undo the  
> trick (and he probably hasn't done them all yet).

Yeah, I have, but it took all of one minute to do and would take  
another minute to undo. I say fix it if no one else objects.

-Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."

On Apr 15, 2006, at 9:03 PM, Bill Catambay wrote:

> At 4:48 PM -0700 on 4/15/06, Forrest Cameranesi wrote:
>
>
>>> If you are using "double-wide" landscapes, that may be the  
>>> problem. Your ogl_asprat_exp is "0", which means your aspect  
>>> ratio is 1:1--so your landscapes better be square. This code  
>>> changed a lot, and I may not have replicated any old broken  
>>> behavior. I didn't realize people were using all those exp  
>>> settings and things.
>>
>> Ok, maybe you can tell me what that MML code should be then,  
>> because honestly I don't remember what any of that does now. I've  
>> got 2048x540 landscapes, which I want to wrap around 360 degrees  
>> (i.e. not repeating at all), and have the same proportions as a  
>> 1024x540 landscape usually would (i.e. I want what is square in  
>> the image to appear square in game).
>>
>> Here's the MML I've got now again:
>>
>> 	<landscapes>
>> 		<landscape coll="27" horiz_exp="0" vert_exp="0"  
>> vert_repeat="false" ogl_asprat_exp="0"/>
>> 		<landscape coll="28" horiz_exp="0" vert_exp="0"  
>> vert_repeat="false" ogl_asprat_exp="0"/>
>> 		<landscape coll="29" horiz_exp="0" vert_exp="0"  
>> vert_repeat="false" ogl_asprat_exp="0"/>
>> 		<landscape coll="30" horiz_exp="0" vert_exp="0"  
>> vert_repeat="false" ogl_asprat_exp="0"/>
>> 	</landscapes>
>>
>> What needs to change to make it work with the new code you've  
>> implemented?
>>
>> Also, a couple of things you said I should submit to SF bug  
>> lists... whereabouts do I begin doing that? I'm completely  
>> unfamiliar with SourceForge.
>
> It appears that we're all guessing a little on how to use the MML  
> for landscapes.
>
> I also use a few landscapes which I prefer to wrap around once  
> (rather than doubled) and have the proportions in the 2048x540  
> image appear accurately in the game.  However, I took a different  
> (and easier) approach which appears to work quite well for me.  I  
> take my 2048x540 texture, size it to 1024x540 (losing aspect  
> ratio), and install into the Shapes file.  Then I use MML to tell  
> it to stretch all the way around.  For an example....
>
> Under <opengl> I have:
>
> <texture coll="28" bitmap="1" normal_image="emrtextures/landscapes/ 
> double-space1.jpg"/>
>
> And under <landscapes> I have:
>
> <landscape coll="28" horiz_exp="0"/>
>
>
> The above gets me the results I'm looking for.
>
> I'm not sure why you are using the vert_exp and vert_repeat args,  
> and I have no idea what the ogl_asprat_exp arg does.
>
> As far as the external image referenced in the MML above, it is  
> stored as 1024x540 (the 2048x540 scrunched), but it could probably  
> be stored as 2048x540 with the same results.  I'm not really sure.

I tried the approach you gave first, back when I first figured out  
that this was possible, but played with it more to get it so I could  
keep square pixels and higher resolution instead of getting the loss  
of scrunching and stretching that you'll be getting with your method.

What vert_exp does it adjust the vertical proportions of the image in  
accordance with the horizontal proportions (i.e. they should be the  
same to keep the image proportional and not stretched, like you  
intentionally have yours). ogl_asprat_exp does something with  
proportions as well. With a 2048x520 texture, setting both horiz_exp  
and vert_exp to "0" and ogl_asprat_exp to "2" will get you wrap- 
around well-proportioned textures. And you're right, I don't need  
vert_repeat in there at all.

-Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."

At 12:34 AM -0700 on 4/17/06, Forrest Cameranesi wrote:


>
>>>And another question... after it finishes loading on that screen, 
>>>it goes on to show the default loading box for a little while 
>>>afterwards too. Is there any way I can make that go away, or use 
>>>the custom loading screen again?
>>
>>Hmm, it shouldn't display it. At least, I don't see it here. Maybe 
>>that's another bug?
>
>In the old NIBs, I would get one progress bar, and then another 
>progress bar after that one finished. In the new NIBs (the one we're 
>testing now) and the new SDL, I get the custom loading screen and 
>then the default loading screen (a progress bar in NIBS, or just 
>"loading" in SDL). I just figured there were two stages of loading...

I thought you were only talking about SDL, but since you are 
mentioning NIBs, I'm not getting the same results that you are 
getting.  I get the custom loading screen, and that's it.  There is 
no progress bar that follows.  So if we're both using rc1, why are we 
getting different results?

Are you sure you are getting both the loading screen and progress bar in NIBs?


-- 

Bill Catambay                
The Marathon Map Makers Guild
mailto:trex@...                  
http://excaliburworld.com/emr/

On Mon, 2006-04-17 at 00:34 -0700, Forrest Cameranesi wrote:
> In the old NIBs, I would get one progress bar, and then another  
> progress bar after that one finished. In the new NIBs (the one we're  
> testing now) and the new SDL, I get the custom loading screen and  
> then the default loading screen (a progress bar in NIBS, or just  
> "loading" in SDL). I just figured there were two stages of loading...

The old first progress bar is always hidden; the second only appears if
you're not using a custom load screen. At least, that's the way it
should work.

You're not using 3D models are you? I can't think how you'd be getting a
load screen *and* a dialog...

Gregory

At 12:39 AM -0700 on 4/17/06, Forrest Cameranesi wrote:


>I tried the approach you gave first, back when I first figured out 
>that this was possible, but played with it more to get it so I could 
>keep square pixels and higher resolution instead of getting the loss 
>of scrunching and stretching that you'll be getting with your method.
>
>What vert_exp does it adjust the vertical proportions of the image 
>in accordance with the horizontal proportions (i.e. they should be 
>the same to keep the image proportional and not stretched, like you 
>intentionally have yours). ogl_asprat_exp does something with 
>proportions as well. With a 2048x520 texture, setting both horiz_exp 
>and vert_exp to "0" and ogl_asprat_exp to "2" will get you 
>wrap-around well-proportioned textures. And you're right, I don't 
>need vert_repeat in there at all.

This is good to know.  I'll have to experiment and see if I get 
better results with this method.  Thanks for the info.
-- 

Bill Catambay                
The Marathon Map Makers Guild
mailto:trex@...                  
http://excaliburworld.com/emr/

Quoting Bill Catambay <trex@...>:

> I thought you were only talking about SDL, but since you are=20
> mentioning NIBs, I'm not getting the same results that you are=20
> getting.  I get the custom loading screen, and that's it.  There is=20
> no progress bar that follows.  So if we're both using rc1, why are we=20
> getting different results?
>=20
> Are you sure you are getting both the loading screen and progress bar i=
n
> NIBs?

I will try again tonight to confirm. I think you're right about the new N=
IBs=20
build (RC1), cause I was refining my loading screens last night and using=
 the=20
NIBs RC1 and didn't see the progress bar after the loading screen. I was=20
probably just confused when I wrote that last message.

I'll double-check with SDL again when I get home tonight, cause that=20
definitely was giving me a "loading" message after the custom loading scr=
een.

-Forrest

On Apr 17, 2006, at 10:21 AM, forrest@... wrote:

> Quoting Bill Catambay <trex@...>:
>
>> I thought you were only talking about SDL, but since you are
>> mentioning NIBs, I'm not getting the same results that you are
>> getting.  I get the custom loading screen, and that's it.  There is
>> no progress bar that follows.  So if we're both using rc1, why are we
>> getting different results?
>>
>> Are you sure you are getting both the loading screen and progress  
>> bar in
>> NIBs?
>
> I will try again tonight to confirm. I think you're right about the  
> new NIBs
> build (RC1), cause I was refining my loading screens last night and  
> using the
> NIBs RC1 and didn't see the progress bar after the loading screen.  
> I was
> probably just confused when I wrote that last message.
>
> I'll double-check with SDL again when I get home tonight, cause that
> definitely was giving me a "loading" message after the custom  
> loading screen.

Yep, just confirmed. The new NIBs version works properly, with just a  
loading screen (although it fills the screen, unlike chapter screens  
and the main interface do in NIBs). The SDL version not only gives me  
a second loading screen, but I just noticed that it's drawing the  
custom load screen in 256 colors.

-Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."

On Apr 17, 2006, at 10:38 PM, Forrest Cameranesi wrote:

> Yep, just confirmed. The new NIBs version works properly, with just  
> a loading screen (although it fills the screen, unlike chapter  
> screens and the main interface do in NIBs). The SDL version not  
> only gives me a second loading screen, but I just noticed that it's  
> drawing the custom load screen in 256 colors.

OK I'll play with it. But I don't see any way in the world to get 256  
color load screens, since those are rendered through OpenGL, and I  
don't think OS X even supports 8-bit OpenGL.

Are you using a JPEG load screen?

3D models?

Gregory

On Apr 17, 2006, at 8:11 PM, Gregory Smith wrote:

> OK I'll play with it. But I don't see any way in the world to get  
> 256 color load screens, since those are rendered through OpenGL,  
> and I don't think OS X even supports 8-bit OpenGL.

Yeah, that was confusing me as well. It looks perfectly fine in the  
NIBs build by the way.

> Are you using a JPEG load screen?

Yes.

> 3D models?

Nope, but lots of hires replacement everything.

-Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."

On 4/17/06, Gregory Smith <wolfy@...> wrote:
> I don't think OS X even supports 8-bit OpenGL.
It doesn't, and never has. :(
-:sigma.SB
</ot>

On Mon, 17 Apr 2006, Forrest Cameranesi wrote:

>> Are you using a JPEG load screen?
>
> Yes.

Do you get the same results if you use a BMP or PNG?

Gregory

On Apr 18, 2006, at 11:17 AM, Gregory Smith wrote:

> On Mon, 17 Apr 2006, Forrest Cameranesi wrote:
>
>>> Are you using a JPEG load screen?
>>
>> Yes.
>
> Do you get the same results if you use a BMP or PNG?

Yes.

-Forrest Cameranesi, Geek of All Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."