The Day After The Night Before
Well guys and gals, I spend a good few twilight hours working on my little instance stamp system, taking it from a DrawMesh call to exploding the code out so I could control the whole process again at the DirectX level.
The process took many hours because you have to deal with vertices, indices and draw calls very carefully. Your only evidence that it works is when you see polygons, and when you don't see polygons it could be for a hundred reasons. To this end I used a technique of swapping out one bit at a time the stuff I could run and see polygons, with the new code that was untried. The final step was to recreate and fill the buffers themselves which was a lot of code and a leap of faith, and after one or two false starts managed to get my polygons back!
What We Have
What we have now is a function that collects data from the reference map (populated by adding instance stamps as the user adds objects to the level) and a second system populates a newly created vertex and index buffer with this transformed data to something that can be rendered. It's only one buffer and one FVF format, and a hacked in way to populate the data, but it is rendering and in the general shape of the final implementation.
As A Bonus
I also changed the index buffer from 16bit to 32bit for instance stamp renderings so we are no longer limited to 65535 vertices per buffer as well. Once upon a time (five years ago) older graphics cards could not cope with this, but all graphics cards handle 32 bit vertex indices fine now so we can cram a lot more stuff into a single buffer. This will mean better performance and less code to manage fragmented data sets.
Signing Off
It's about 4PM now and the sun is shining, so going to spend two hours baking myself in the garden, then return after dinner to move the chess pieces further. My hope is to manage the buffer so that as I add more polygons, it creates a second and third buffer to keep up with demand. I also plan to sort out the mesh transformations properly so they take into account the frame matrix as well as the instance properties passed in for the particular object to be rendered. Should not be too hard, except that matrix math is not my strong suit (even after 15 years working with 3D engines).
A couple of questions :
ReplyDelete1. Seeing how you needed to modify the DirectX level to add instancing, will you add the possibility for developers to work with the pure native level as well? It would be very very helpful in the long run, in my opinion.
2. This one came to my mind when you wrote about the 32-bit index buffer. It`s not really related, but will we be able to choose between LDR and HDR image output?
3. Will we be able to modify shaders directly, such as adding more render targets for ourselves?
4. This one arose at the matrix part. I really think that we should be able to access two math layers : one working with vectors only (for beginners) and one exposing the whole algebra of the classes (for cameras,meshes, shaders, everything), such as matrices and quaternions as well.
4+1 : IF the answer to the first question would be affirmative, would we be able to decouple the DX renderer from the rest of the code? For porting to OpenGL, for instance?
By the way, I have to congratulate you sir, I know how massive the amount of work you are doing, similar projects are handled by dozens of people. With that being said, thank you for blogging about your process, it`s very motivational to see your progress.
All this would be too advanced for a typical glace user and I don't think the development cost of adding lots of advanced users only features is in the service of Shipping this year. We can get by very well authoring shaders for fpscr in dark shader and there is really no need for things like opengl support. I would be quite happy with the instance approach that was previously planned as it was considerably more efficient than the current engine but you have to draw the line somewhere. very happy with the progress here
ReplyDeleteThese things I mentioned would all be available by handing out the source. :) So you can't really talk about added development cost here, end-user cost, maybe.
ReplyDelete@László Füleki:
ReplyDeleteHave you ever USED DBPro?? Do you even realise FPSC-R is created in DBPro??
With regards to question number 1: In what way would we get access to native code? Seriously, how? This is DBPro we're talking about, not C++. FPSC-R will include NO C++ code whatsoever, and even if the source is released it will be written in DBPro.
Question number 2: I can only speculate on this, but let me suggest that in all likelihood, there will be no HDR support AT ALL.
Question number 3: In FPSC Classic, we had full access to the actual shader files. I see no reason this might change for FPSC-R, but just bear in mind that even if we do end up with access to the shaders, it'll be hard (if not impossible) to modify them because they'll be tightly integrated into the engine.
Question number 4: Again, what language do you think FPSC-R will support for scripts? Your questions astound me. There is no advanced scripting language in FPSC-R.
Question number 4+1: WHAT?! SERIOUSLY?? DBPro IS DirectX. It would have to be rewritten from the ground up, from scratch, to support OpenGL. That would be a mammoth task that would take at least a year to complete! You do realise, don't you, that FPSC-R will be Windows-only, right?
Having said all of that, it occurs to me that you may know perfectly well that DBPro is DirectX-only and Windows-only, and that your first question may refer to DBPro itself (although I cannot work out what you mean by "pure native level"). Even so, I sit here shaking my head as I read and re-read your other questions. Perhaps you could clear this up for me.
Well hopefully the source wont be handed out at all.
ReplyDeleteOne product, one source, one set of tight control on the quality of FPSCR. If the source is given out then it should be given only to select users chosen and veted by TGC any any modifications to the source as to be released as a derivative of the FPSCR product should have to meet the same stringent quality control tests that TGC have now to go through and no modification of FPSCR released into the public domain as a representative of the product which may do it an injustice until its inspected for quality by TGC and release is authorised by them as being approved.
At least if anyone seriously wants to Mod FPSCR then TGC should charge a fee to license the source to them and still hold sway over the quality of anything thats produced before being released publicly for sale or otherwise.
That would provide a number of safeguards and benefits to the product and TGC.
Giving out the source freely with no control of what is done with it may in some instances at least do FPSCR more harm than good for obvious reasons which if not aware of then theres no point in my spelling them out.
The success of FPSCR depends largely on it quality and maintaining that as a reputation for it as far as I can see.
Not that its anything to do with me just my opinion.
I have to disagree with Peter, easy access to the source is key to me and a lot of other developers. Being able to add your own features to your own games is essential.
ReplyDeleteWith regards to the continual development of stock FPSCR, then I tend to agree. The inclusion of.mod features into FPSC has not been overly successful and maybe a stricter process would help.
But I'll say again that allowing the community to create their own mods can only encourage FPSCR development and help produce better games.
The source code should definitely be released. Peter, I see no harm in doing so and if you believe there's a problem maybe you could tell us what it is.
ReplyDeleteIf it's simply a matter of TGC integrating supposedly damaging community mods into the official code, then that problem is best solved in ways other than removing source code access. It's up to TGC as to whether mods are integrated; releasing the source code freely does not inherently mean that mods will be integrated into the main code. The problem of breaking stuff by merging mods can be solved, very easily, by simply not merging mods.
Here's a question for you: Do you believe FPSC X9 would be where it is today if the source code had not been released? (My answer would be "No!")
For the record, I love the fact that TGC allowed so many mods to be integrated into the main code. It made FPSC so much better. In my experience the mods have fixed a great deal and broken nothing.