Object Library droping the frame rate below 0!

[Guest Claviateur]

Actually I will email Architect2002 author about it so he can at least fix the missing "return" in the generated code otherwise a beginner scenery designer using Architect would think that it is a normal frame rate. CheersMichel

[Guest Claviateur]

Hi Arno,This code was generated by Architect automatically, I just edited the sca and added return and removed the noobj as you suggestedCheers!Michel

[arno 1]

OK, and the origional source compiled without errors?? With that missing label it shouldn't even compile. And the rest is also a bit strange (but I think we have solved it now all together :)).Arno

---

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

[Guest Claviateur]

Yes it compiled without errors. I used FreeSC actually it is the official Architect compiler. Now the Return made the frame rate back to normal :)CheersMichel

[Guest luissa]

>I know GMax still uses PerspectiveCall (called different in >BGLC of course), but you still need it. Otherwise you can >get strange effect in the scenery (sky visible through the >object for example). >Thank you Arno,And the Perspective before the RefPoint()? Do the PerspectiveCall() and ShadowCall() point to the same label? Or Perspective is obsolote?Regards,Luis

[Guest]

Hi Arno you are one of the few people to have framerate problems withour scenery(see our site) try removeing the .bgl "ThunderBay9jk7NT.bgl and see if that helps. Dan

[arno 1]

Dan, it can also be that it is my PC I have here in Brussels. It's only a Celeron 433, with 192 MB RAM and a TNT2 video card.I haven't tried the scenery yet on my normal PC (AMD1333, 512 MB, GF2Ti). I think it will work much better there.Now I get around 3 frames at the airport, but that is without setting the density back (don't want that, because I am also testing my own scenery on it and want to see everything, I am not flying on that machine anyway :)).Arno

---

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

[arno 1]

Yes, PerspectiveCall is still after the Area command and in front of the other commands (ShadowCall, RefPoint, etc).Here is the code in BGLC commands:OBJECT_0_START label wordIFIN1 OBJECT_0_FAIL, image_complex, 2, 32767ADDOBJ OBJECT_0_SCALESHADOW_CALL OBJECT_0_SCALEOBJECT_0_FAIL label BGLCODEBGL_JUMP_32 OBJECT_0_END OBJECT_0_SCALE label BGLCODESCALE_AGL OBJECT_0_RETURN, 10000, 575, 131072, 0005A98C9h, 0AB7Fh, 0FB8FA5F2h, 0DCCAh, 0, 0INSTANCE_CALL OBJECT_0_BEGIN, 0, 0, 02AAAhOBJECT_0_RETURN label wordBGL_RETURNI think you will notice the different commands. First there is a check on the density, then the PerspectiveCall (ADDOBJ) and the ShadowCall (SHADOW_CALL) (both calling the same label). After that is the jump (BGL_JUMP_32) to the end of the file (just like the normal Jump( : )).Then you get the RefPoint (SCALE_AGL) and a jump to the actual code of the object (INSTANCE_CALL). I don't know yet what the exact difference is between the INSTANCE_CALL a normal call (so I don't know what the parameters do).Arno

---

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

[wsieffert 0]

FreeSC hasn't been updated for awhile. Have you tried taking your source file and compiling it with SCASM 2.88 - http://www.scasm.de/ to see if it gives a better build. I would also add:Set( FSVERS 0x800 ) --- This makes it use FS2002 commandsHeader( 1 -45.12500 -44.87500 -45.12500 -44.87500 ) - Your header vice thisLatRange( -44.87500 -45.12500 ) - Your LatRange vice thisset( areamx 64 ) ----- May or may not be necessary, can't hurt!!!

[Guest]

Dan, every so often one of the discussions around frame rate has evoked your message of the value of GMAX. While we've learned from you, this thread is a neat indication that its also important to keep an open mind and consider the implications of well written code. A missing return is fixed and code works well independant of tool! This possibility wouldn't have been considered if we quickly dismissed issues based on a general perception of tools. Indeed, as I read the thread, the library objects was constructed in gmax, so it really wasn't a precise consideration in the first place.I love GMAX and agree with its value, but I also love understanding the details of problems and solutions.Bob B

[Guest]

Hi Bob point well taken!! I did read in the original post that they were done with Architect(I like architect BTW). And I do understand about always having clean code!! I am sorry if I offended anybodywith my somewhat flippant reply(I was not trying to be!) My point ofview is that of a modeler and from that point of view I need tools that work and thus allow me to do what I do best model and design scenery! I do read the posts in this forum every day and I see peoplepulling their collective hair out trying to fix things that shouldnot need fixing in the first place. If any given program gives me good results then I will pass what I know on to the next person thatmight need it just like you do(and I owe much to people like you,ArnoChristian,Gerrish and may others). Anyway enough said. Dna

[Guest GerrishGray]

Hi Michel & allApart from the other errors in the FS Architect code that Arno etc. have pointed out, of which the missing Returns is the really serious and fundamental error that completes corrupts the operation of the code and leads to the drop in framerates, there are a couple of other things you can/should do to get best framerates etc.1. For this simple call of an object, you can use a type 4 Area() call instead of type B. It creates smaller, faster, code.2. The v2 value in RefPoint() should be set to a much smaller, realistic, value. It is meant to represent the radius of a sphere based on the RefPoint that encloses the object. Values that are too large result in the scenery engine wasting time trying to draw objects that aren't visible on screen anyway! The v1 value being used is also probably too high - a maximum visibility range of, say, 10kms, is probably much more realistic.Including the missing bits of code, and assuming that you want your objects to be visible at Normal scenery complexity settings and above, but not at Sparse or Very Sparse, the code should look something like

-----------------------Area( 4 33:50:7.753636 35:29:20.333310 20 )  IfVarRange( : 346 2 32767 )  ; tests Scenery Complexity setting  PerspectiveCall( :obj )	  ; calls a subroutine to draw a 3D object  ShadowCall( :obj )		   ; calls same subroutine for shadow generation  Jump( : )					; jump to EndA to exit from object:obj  RefPoint( rel :endobj 0.500000 33:50:7.753636 35:29:20.333310 v1= 10000 v2= 100 )  RotatedCall( :rot 0 0 0.00 ) ; calls a 'second level' subroutine:endobj  Return					   ; from the 'first level' subroutine:rot  CallLibObj( 0 C545A270 11D2E2EC 1000849C 2AE60C5A )  Return					   ; from the 'second level' subroutineEndA-----------------------

Note that both Return's are necessary for correct code structure. Using a Jump( : ) instead of the first Return only 'appears' to work - it actually causes a mistake behind the scenes that is apparently tolerated by the scenery engine without leading to a fatal error, but probably causes more work in the process!As regards the gMax issue, gMax creates faster code than older macros because it uses the new DirectX friendly 'floating point' commands, as does FSDS2 and the forthcoming NovaSim from Rafael Sanchez.But what you are calling here is a default MS library object, so this question doesn't arise.There is no difference in this example between using FS Architect's default FreeSC compiler or the current version of SCASM - they should both produce identical compiled BGL code. SCASM is needed, however, if you are using 'floating point' code or some of the more complex macros that are not compatible with FreeSC.Hope this helpsGerrish

[Guest]

Again thank you Gerrish you just may have found something that a "dumb" animatormodeler like my self just plain missed when someone like me looks at the code output by Architect. It is in all probably the cause of the framerate hit with the macro built by Architect that has caused me some greif. Dan

[arno 1]

>1. For this simple call of an object, you can use a type 4 >Area() call instead of type B. It creates smaller, faster, >code.Gerrish, do you know what the limitation of the type 4 RefPoint then is? I can't remember I have read about it anywhere. If it is smaller and faster, but not justed widely at the moment there must also be some disadvantages (smaller allowed Area size or so). Do you know what those are?Arno

---

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

[Guest GerrishGray]

Hi ArnoA type 4 Area() is limited to just 256 bytes of compiled BGL code, including the object header, so it's only usable for something like a single library object call (plus the usual surrounding code). Using type 4, when possible, reduces the load on memory resources because only a single 256-byte page is assigned to it in memory.In BGLC syntax, the type 4 object header is

NEAR_SMALL_OBJECT_HEADER lat,lon,object_end,power

The compiled code is

opcode	db	4	dd	lat,lon	db	power		; image power (0-100%)	db	object_end-opcode

Types 7 and A are similar, but are for FAR and NEAR_FAR objects respectively.See pp.26-7 of the FS2000 Scenery SDK.CheersGerrish