Jump to content
Sign in to follow this  
arno

Frames - FSDS1 vs FSDS2

Recommended Posts

I think it is time for a nice discussion about the influence of different SCASM command on the frames :).I made a remark about a little optimalization test I have done in another thread and Gerrish made the good suggestion to make a separate thread for it, so here it is.The test I did was with some hangars from Schihpol. These had been designed by a collegue from the NL2000 team and they seemed to have a bigger framehit then the parts I had handcoded in SCASM (or now in GMax).So I had a look at his files and I noticed he had a lot of separate parts. Therefore I asked him to join as much parts as possible, as that would reduce the amount of points in FSDS1 (and thereby make the source more efficient). Another benefit of this is that the amount of Call commands in the source reduces. This is what I call the optimized objects in the list below with the frames.After that we also loaded the objects in FSDS2 and created again two APIs (one as origional in FSDS1 and one for the optimized version). Due to the way the new FP commands work (for example with the texture mapping) the point list is the same for the origional and optimized version. So, compared to FSDS1 there should be no big difference in that part. The main difference between the optimized and the origional version is the lower number of Call commands at the start of the file.After that I made a test file where I placed 5 different hangars each a couple of times (so that I had enough objects to see a framerate influence). I did this for all four macros I had by now. The resulting frames are giving below.FSDS1: 19 framesFSDS1_opt: 29 framesFSDS2: 21 framesFSDS2_opt: 38 framesThe first thing it shows is that joining parts in FSDS makes the source a lot more efficient. For FSDS1 this is what I expected, as it reduces the amount of points a lot. But for FSDS2 the influence surprised me (as the VertexList and DrawTriList should not be really influenced by the optimalization). So I think here the main difference is that the amount of Call commands in reduced a lot, making the code more efficient to read for FS.A second thing that is visible is that the FP commands are indeed faster then the old SCASM commands (as is already known by now). But when the design in FSDS is not made really efficient the difference is very small. This is something I already noticed before when I converted some objects from FSDS1 to FSDS2. I had not joined the parts there as the airfield I was working on was small and not in a dense area. After converting to FSDS2 I actually got lower frames then before.OK, I think this is enough information for a nice discussion, if you have not given up reading it by now :D.


Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

This is very interesting. I always join parts and "snap to scale" to reduce points, but I never thought it would improve framerates - I was only trying to make the project "cleaner". Now that I think about it, what you say makes perfect sense.But just to clarify what you mentioned about the Call commands - are you saying that even if points aren't reduced, we should still join parts together? If I have a bunch of strange parts in my object, so that the points don't line up, will I still see some improvement if I join all these into one part?Well, I'm already thinking of some objects that I have made that could benefit from this, so I better get to work. Thanks for the info Arno.- Martin

Share this post


Link to post
Share on other sites

Well, that is something we need to discuss here I guess. In FSDS2 there is not reduce in the amount of points due to the way the floating point commands work. Snap to scale should also not be needed there, as they are floating point, but I don't use FSDS anymore, so I have no idea if it works that way.When you compare the code for the FSDS2 API and the FSDS2_opt API the main difference is that, due to the fact that there are less parts, there are less Call commands at the start. This is the only reason I could find for the increased framerates after optimizing. But if someone else has other suggestions they are welcome of course :).


Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites
Guest GerrishGray

HiFrom what you are saying, it looks as though one of the main problems here is the inefficiency of Call() commands generally in FS. FSDS has always taken the approach of generating separate code blocks for each 'part' and then calling the blocks as separate subroutines via a Call(). This is largely unnecessary with FP coding, where the correct approach is to establish single, amalgamated, Texture, Material and Vertex lists, and then a series of SetMaterial/DrawTriList sequences in a simple linear flow as far as possible. I know that structuring the code in modular form with subroutine calls is nice and neat and has all those theoretical program design advantages that I have spent large parts of my career teaching to students, but the overhead of the Call()'s is too great in this particular case.A structured style was necessary back in the days when we had to give the correct drawing order for viewing from different directions with lots of VectorJump's, but that is no longer the case.It should be noted that MS themselves introduced the Transform Matrix structure to replace RotatedCall and TransformCall because of the performance improvements to be made by avoiding Call's when possible in FS programming.FSDS is not the only tool to adopt a nicely-structured approach with each part as a self-contained subroutine, but it seems as though we would do better to use a more old-fashioned style with a straightforward unstructured linear program flow when possible to get the best performance in FS. Those long enough in the tooth to remember how we used to code in assembler for optimum performance before modular/structured programming, and then OOPs, became 'de rigeur' will know what I mean! Interestingly, this simplified linear style is used by NovaSim and this could explain why NovaSim models seem to give the best frame rates.CheersGerrish

Share this post


Link to post
Share on other sites
Guest luissa

Hi Arno,Thank you for this report. It is surprising the numbers you gave. I often merge all parts n a single one and I allways "SNAP TO SCALE". This is important even with Floating Point representation because most of the time, there are repeated points in the separated parts. Once you join the parts, you can have a shorter Points list by "SNAP TO SCALE". When I have parts without common points I also leave them separated for better manual editing in SCASM. But even in this case I delete manually the Calls that appear after the VertexList. What really surprises me is the amount of gain in frames!Regards, Luis

Share this post


Link to post
Share on other sites

Hi Gerrish and Luis,Gerrish, if you look at the source of FSDS2 it has one big VertexList, MaterialList and TextureList. But still the Call commands are used after that to draw the parts.If you look at MakeMDL it does put everything in a big DrawTri list as well, when you check the optimize option. Otherwise there are some TransformMat commands around it if I remember correct. But this indeed seems to be the most efficient way to work with it.And Luis, with the new floating point commands the snap to scale should have no difference. Because the texture mapping is also in the VertexList, even if the coordinates of the point are the same, it will still get two entries (each with the texture mapping for one polygon). So I don't expect that should shorten the point list (with the old commands it certainly does). That is also way I was that surprised by the big frame gain :).


Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites
Guest GerrishGray

Hi ArnoYes, as I said before, it is the Call() commands that are the problem and cause the hit on frame rates. As Luis said, for those that use FSDS2 the best idea is to manually remove the Call's from the SCASM code and it is also a good idea these days to replace RotatedCall's and TransformCall's by TransformMat's whenever possible.Also, if one is manually editing FSDS code one should also do something about the incorrect crash detection that uses eye position instead of aircraft position. In many cases just removing the crash detection altogether is a sufficient solution, otherwise, if the object is going to be in the immediate vicinity of an airfield or is tall enough to be a flight hazard that someone might actually crash into (!?), one can replace the FSDS crash box with a much more efficient, and correct, one using the CrashOctTree construct - a single node will suffice to make a straightforward box.CheersGerrish

Share this post


Link to post
Share on other sites

Yes, you are right.The crash detection is also a good point, we are now beta testing our new NL2000 scenery and we indeed have a few bugs with FSDS crash detection that gives a crash if you use spot plane view.When our scenery is ready I think I will write a little article for my site about what we have disccused here. Collection all these suggestions for FSDS designers in one tutorial or so.


Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

>And Luis, with the new floating point commands the snap to>scale should have no difference. Because the texture mapping>is also in the VertexList, even if the coordinates of the>point are the same, it will still get two entries (each with>the texture mapping for one polygon). When you use snap-to-scale, it will remove duplicate points in any single part, so there will be fewer points. This is what I was trying to get to when I mentioned it my post. From what you were saying, I thought I thought removing extra points would help in the optimizing process.For example, I've joined two boxes together, and then snap-scale-scale which deleted 4 co-located points. What I'm wondering is if FSDS2 will still count those points twice when it creates each polygon? If this is true then I agree it wouldn't help at all to snap-to-scale. I think this is what you were trying to say above, but I think I need a little clarification since I admit that I don't completely understand the FSDS2 code all that well. :)It would be good to have a optimization tutorial like you mentioned. I use a few tricks like removing hidden polygons and orphaned points. But if there was a guide to manually editing the compiled API files for optimization, that would be great.- Martin

Share this post


Link to post
Share on other sites

Sometimes being a relative newcomer to FS design has it's disadvantages. I've only done scenery design in earnest in for a little over a year now, so I don't have the depth of knowledge of pre-Gmax 3D authoring that many of you seem to have. Can you illustrate how this discovery affects those of us who do purely Gmax scenery? Or does it affect us at all? I've been very curious to learn more about SCASM, and my understanding of modeling is progressing to the point where I'm feeling the need to understand optimization much better, but I'm still on the upward-facing side of the learning curve.

Share this post


Link to post
Share on other sites
Guest GerrishGray

Hi MartinRemoving duplicate points won't normally do much, if anything, to improve the performance of a model. It's the amount of 'work' to be done that determines speed of execution, not the length of the code. Time saved by quicker loading of the slightly shorter code will normally be insignificant.This is also the basic reason why floating point code is SO much quicker than old-style coding - floating point code requires US (or our scenery design programs!) to do all the work of triangulation etc. etc., whereas the old style code left the scenery engine do all sorts of extra, time-consuming, work for us, such as triangulating polygons.CheersGerrish

Share this post


Link to post
Share on other sites

Hi Bill,Does not influence SCASM users at all. The code GMax (or MakeMDL I should say) produces is very efficient compared to the FSDS code when one designs without caring about the frames. The things discussed here allow FSDS users to get code as efficient as GMax makes it.


Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...