I think that it is best to view this thread as something to
read in your spare time in your own pace. Although I work on the project daily and log what I have done; you do not need to rush and skim read to catch up with me, please take your time but do read this stuff if you plan to use the software;
the foreknowledge will aid your plans and will help you understand the discussions more easily.
@Mr.Valentine
You seem to be stuggling to grasp the information; most of your questions have been answered in various posts. Be patient, perhaps things will be more clearer with footage later in the year.
Quote: "Rudolphohit the post there I think...
Yeah what exactly will this be used for?
Quote: "
You can sell what you make with DBP, I think Mr.V is aware of that but it his question is not quite clear to me. After reading the thread he will have an understanding.
Apologies for being too bold but my guess is that in the end, the IDE software will be a TGC add on for DBP and AppGameKit, a bit like Visual Studio for C# and VB. But it is way too early for such assumptions.
I will officially make proposals to TGC with a fully working demo, after then we can see how it goes."
What do you mean by
this being used for, (XProd? The plugin? DBP). Stop using vague words such as
this and
the. If you want to ask what X-Producer stands for; ask what does the X-Producer stand for; if you say "what does it stand for" it could mean the engine, the plugin or any of the products metioned.
And how does the question relate to the above quote you made? Or is the question not related to the quote you made ( My head is starting to hurt now ). I hope my answers to Rudolpho will suffice.
@Rudolpho
Quote: "On a side note, I notice the FPS displayed in most of your screen shots look rather low while the rendered scenes doesn't seem to be very complex."
I have placed a low priority on the framerate for practical reasons, to prevent premature optimization and to focus on infrastructure.
I am sleeping engine the loop and locking the FPS at about 30 frames per second to give the UI thread and video capture program some room to breath. I have no time for shutting down my other programs every time I take a screenshot, but if I maxed out the FPS; DBPro would consume too much of my resources I need for my development software running in the background.
I have built a clock system for benchmarking the engine later on when we start dealing with gameplay and cut-scenes.
I just bought an additional PC, something a little faster, so I might boost the FPS a bit more.
I do not mind showing low FPS on the screenshots; I am confident such screenshots will be forgotten this time next year. These images are more about showing people what I am doing and how stuff works.
Just for any curiousity, the engine sleep process uses the Matrix1
Nice Sleep command; and this can be overriden in the configuration file for both products. Compared to the native sleep command, this Matrix1 alternative is CPU friendly.
Quote: "If I understood it correctly I believe MrValentine meant that your work seems to be dependent upon DBPro "
Now that is an interesting rephrase of the question; the answer is relative to the given product.
The answer to whether the X-Producer is dependant software, is YES and NO! It depends what
you are using the X-Producer for.
YES because if you want to use it to manage and deploy your DarkBASIC projects, I am not stopping you. I am doing it to build Sports Fiction, you can do the same to build your products. You still need to buy your copy of DarkBASIC from TGC if you want to build DarkBASIC programs, or AppGameKit from TGC if you want to build AppGameKit programs; or some Java compiler if you want to build Java programs; or some C++ compiler if you want to build C++ programs; it is your choice.
To reiterate
Quote: "The abstraction orientated editor lets you determine the purpose of its tools, which is why the X prefix used to represent what you intend to produce."
Quote: "The X-Producer is the SDK for Sports Fiction modding, a 3D world creator, an IDE for DarkBASIC (and possibly LUA & AppGameKit Basic). It is an editor based on abstraction. You create out of previous creations, and you can create tools which generate such creations for you. A creation can mean anything, for this reason term X is used to represent anything you can think of creating in the production tool."
So you see, it is for producing X out of X; the letter X means something different for everyone. Even if you made your own programming language and compiler, you would define it in the X-Producer and link it up so you can deploy your programs.
This is why I have been doing this:
Quote: "Today's brief session was spent working on the programming language definition class. As you may already know the goal is to create provide abstract classifications in the editor so that you may quickly define what it is you need the X-Producer to define"
So DarkBASIC is one of many languages which could be defined to work in the code editor module, now about the diagram.
Quote: "Still, judging from the presented graphs, it seems that using DBPro with XProducer is actually completely optional (or...?), in which case it can be seen as merely an add-on."
The text below the graph explains it:
Quote: "First the engine, Zero One, is being used to combine Direct X, XML, DarkBASIC, .NET and PhysX for use in the next product; which is the X Producer, the official editor for the engine. The X-Producer is being used to create the gaming content for the third central product, Sports Fiction; a futuristic role playing sports game where players can compete in sports or create interesting sports."
So you see the explaination of the graph deals with what is being used and how. I do not think this paragraph was read or has been misunderstood.
The graph was drawn to show the structure of the software; it has nothing to do with how you deploy applications using the X-Producer; that is something Mr.V may have assumed, but I am sure the text I reposted clarifies things.
I have not even mentioned that DBPro is required to build my EXE files; the software is capable of compiling its own EXE files without DarkBASIC. However this is not my main focus.
Quote: "yep my software can make .EXE's without DarkBASIC"
I built it to work with any windows based tool, however I recommend you do use DarkBASIC with XProd; they will have a much closer relationship than with other tools.
Quote: "using DBPro with XProducer is actually completely optional"
Exactly, you will be able to deploy other EXEs, Sports Ficiton MODs, ZeroOne MODs and other content without owning DarkBASIC; each with their own prerequists and licenses. You will not get a DarkBASIC based EXE out of the X-Producer without owning DarkBASIC yourself.
The ZeroOne runtime engine (that is the thing which SF and X-Prod are made out of) is a .NET based engine which can link up with windows based libraries such as DarkBASIC. As a game engine it will not be good enough to compete in the AAA market for a number of years; so I am not interested in selling it as a serious product at this point in time.
In the future I will be linking it up with DirectX 12 (or the latest version) directly; which is why I have not established this version as a product; it will only be a system to carry the XProd and SF for the first few years which you may use for content creation, modding and deployment through other libraries such as DarkBASIC. It will not be on the same page as CryEngine or Frostbite 3 for years. I'd be lucky to get that far in my lifetime.
Quote: "is the rendering viewport completely separated from the rest of the window interface?"
This is where things get complicated; in some cases yes, and in some cases no. The rendering viewport in some screenshots is a seperate window, but sometimes the whole screenshot is the rendering viewport with windows inside of it. In some cases, there are no windows, just images and sprites. Some windows have been put on 3D planes; but most of the 3D UI stuff is coming up soon, once I finish some important tasks. If the rendering viewport crashes, the X-Producer and Sports Fiction will remain open, and will restart it. A bit like how Dark Shader and Map Scape works.