>OK, just did a quick test and I could reproduce both >results. So pointing at the Return gave me the correct >shadow, but I could also add the shadow of an other object >by pointing to that code. Hi Arno,Thank you for confirming the "second possibility". Unfortunately I stopped, for a while, my FS experiments and I can not make or reproduce any tests at the moment. So, I was looking to Dick code and mine posted here. There are 2 differences:- the obsolete Perspective is in my example- the ShadowCall() is just after the PerspectiveCall() in Dick example; is that a condition for it to behave as a switch?- I remember to see ShadowCall() called before PerspectiveCall(); does that make difference?Regards, Luis

Hi Luis,I used a code like this for my test:

PerspectiveCall( :L1 )ShadowCall( :L2 )Jump( : ):L1RotatedCall( :R1 )Return:R1RefPoint( )Points(....Return:L2RotatedCall( :R2 )Return:R2RefPoint( )Points(....ReturnEndA

A code like the one above gave me the shadow of the second object for the first one. When I changed L2 in the ShadowCall to L1 I got the correct shadow. But also when I let the ShadowCall point to a Return command I got the correct shadow.And about the last question, the ShadowCall must be after the PerspectiveCall. Otherwise you can get strange problems with for example transparant textures. I think it was VOD that had the ShadowCall before the PerspectiveCall but since Fs2000 it is important to have the correct order to prevent the problems I mentioned above.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

>It would be very interesting if we really >could draw a simplified shadow, or even a shadow of a >different object (such as a static version of a rotating >sprite), but Dick and Arno's tests seem to show that this is >not possible.Little correction :), maybe I didn't state it clear, but I could reproduce the results of Luis. So I could couple a completely different shodow to my object (which really looks funny). But also Dick's results I could reproduce and that is what confused me a bit.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

So, ShadowCall() does use the label and it can be pointed at a different object to create the shadow. As we said before this has two uses1. Using a simpler model for the shadow, as suggested by Christian and tested by Luis. It seems that Luis' test and its frame rate results were releiable after all ... and the simpler model halved the frame rate hit of the shadow. The really great thing here is that if you have LOD models anyway then it is simple as making the ShadowCall() for the highest resolution model point to a lower res one, with no extra work.2. We can now create correct shadows for rotating sprite models such as the monoplane tree.Glad you persisted with this guys - it started off as crash detection and confirmed that we don't need Crash or CrashIndirect any more, and now we have made this 'new' discovery about ShadowCall() as a 'side effect'. That's what I call value for money!CheersGerrish

I agree, these threads are really helpfull in understanding how the code works :).The only thing I don't understand yet is that you also get the object shadow when you let the ShadowCall point to a Return (as Dick found). Then the ShadowCall doesn't call any object code but still gives the correct shadow.Arno

---

Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Hi ArnoYes, it seems a bit strange at first sight, doesn't it. But if we assume that the 'compiled' code is really only p-code tokens that are interpreted at runtime by the "scenery engine", then the engine must be tolerant enough to understand that it is to use the current object if the ShadowCall() label is an address anywhere within the code for the object, but if the label lies outside that range then to use the code for the object that the label points to. Why Microsoft would have written it like this I don't know, but there are all these other examples too where people can write bad code (such as missing Return's) and the scenery engine still manages to understand (sometimes) what is required.I think that M$ have tried to make the engine as fault-tolerant as possible, but perhaps they won't do that as much in the future and will make us be more accurate in our programming ...? Who knows, just speculation!But it doesn't always recognise the mistakes anyway - you have seen hang-ups in FS2002 because of missing Return's and I have dealt with cases where people miss Return's or Jump's so that they draw the same object several times and get really bad frame rates as a result, so the engine clearly is executing the code literally in these cases.RegardsGerrish