Suppose I have written a game engine in c++. It was functions such as adPlayer(Vec3f position, Model playerModel), addExplosion(Vec3f position, Size explosionSize).
Now, those functions can be called in some sort of test class and then the projcet can be compiled and run. This takes forever.
What would be ideal is to have some basic text editor where i can type these functions, press ctrl+u and then this somehows calls the precompiled functions of the game engine. E.g, it doesn't recompile the game engine.
How would this be done?
Usually you would compile your engine into a .dll and link it to your project. Then you can just link the function and don't have to compile it if you just want to use the functions.
If you are asking about design iteration, you create a data format that is read in and converted to entities in your scene graph. You need to use the factory pattern. You can use a serialization library where each object knows how to read/write/persist itself.
By having a data format that represents a "snapshot" of your game state, you can read/save it from both a game and an editor. Later you can make design changes to a running game instance by having functions that re-read the data during runtime
It seems like right now you might have hardcoded/mixed client code with engine code, which might be hard to seperate.
If you are asking about compilation, then you will want to compile to a library (either .dll or static .lib/.so). Then compile your client/specific code against your engine lib(s). They should be in seperate projects.
Related
I'm looking into making some changes within the source code of the engine
so I looked at the source code on github but I'm absolutely clueless to how it's actually made up.
and on the web I couldn't find anything on how the engine itself is made, only what it can do.
Several questions come to mind:
Where does the main script start from? is it from the Main::setup()?
What would be the flowchart of how the engine operates?
How is the engine UI built? (from a web dev point of view, what is the equivalent HTML for it?)
I'm no advance expert in c++ so even a general abstracted overview would be really helpful to get started
Godot build is orchestrated from python using SCons as you can read in the documentation Introduction to the buildsystem. It is different for each platform (e.g. you need the JDK for Android).
As you are aware, you can find the Godot source code on github. Before going further I need to point out that at the time of writing the master branch of the repository corresponds to the development builds of Godot 4. You might want to change to a different branch depending on the version you want to work on.
Disclaimer: I'm more familiar with Godot 3 code base.
Now, not only the build process different for each platform, also are the API bindings, and the entry point. You want to see inside the platform folder for operating system specific code.
For example, the entry point for Windows can be found in godot_windows.cpp and it looks like this:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
godot_hinstance = hInstance;
return main(0, nullptr);
}
You can follow the logic from there, you will find that ultimately they do some initialization and call the methods setup and start of the Main class. You can find the Main class in the aptly named main folder. Afterwards the platform specific code will enter its main loop, and after it finished it will call the method cleanup of the Main class, and then release any platform specific stuff.
By the way, when I say a class is in a folder, I mean there are both the .cpp and .h files.
The main loop might do other things, but it must call the iteration method of the Main class. You can see the code computes time, calls into different "servers", dispatches input among other things.
We don't a flowchart. Sadly we have to piece together the overarching processes. For example, I've written about what happens when you instance an scene elsewhere. I did also look into queue_free which you can find elsewhere.
I'll talk a little further about the main loop below. But first I want to point you to the the diagrams we do have:
Architecture diagram.
Inheritance tree.
Now, the more familiar part of the main loop is that there must be an instance of the MainLoop class. It defines initialization and finalization methods, and also methods to be called on each iteration of the main loop. By default it will be an instance of the SceneTree class (which extends the MainLoop class), but you can change that in project settings. You can find the MainLoop class in the core/os folder and the SceneTree class in the scene/main folder.
The SceneTree class has the means to propagate calls of _process and _physics_process on the… scene tree, among other things. The SceneTree has a root object of type Viewport (in Godot 4 it is a Window, which is a type of Viewport). And, as you know, Viewport is a type of Node, and can have children. The children of the root are the autoloads, the current scene, and whatever else you put there… Thus from there down it is Nodes which I expect you to be more familiar with.
On the other side you have sigletons (actual signletons, not autoloads) including the "servers" and some other static utility classes. If you recall Godot has different rendering backends, which are all behind the façade of a "server" (the VisualServer in Godot 3, the RenderingServer in Godot 4). In Godot 3 we had a choice of GLES2 and GLES3 for rendering backend. And the backends also require bindings which you can find back again in the platform folder.
Here is where my familiarity with Godot source code runs out: I don't know how the shader pipeline works.
The UI? Just like everything else, it is rendered with whatever rendering backend is being used. On the web? It will be on a Canvas HTML element (on a WebGL context). The HTML? The HTML code of the web build template is configurable too (The Custom HTML shell option on the build export settings) see Custom HTML page for Web export. The build process for the web? it uses Emscripten (to webassembly). No, there is no Node.js stuff in Godot, just to be clear.
As per making changes, you probably can work on the relevant class. For example if you want to work on the AnimationPlayer you can find it on the scene/animation folder and make your changes there without much worry about how the rest of the engine works.
To build the engine, as I said at the start you need SCons. Please see Compiling and follow the steps for your platform from the documentation.
And about getting your changes merged into Godot, you want to start with an issue or a proposal (written by you, or somebody else). Followed by a pull request. Please refer to Contributing for the overall process and guidelines to get your changes merged into Godot.
Finally if you are having trouble modifying the engine, you can try the Godot Contributors Chat.
I want to build an C#/Wpf Packer.
I am using a C++ application which will start the packed/crypted C# application.
Currently I have to build this C++ app everytime I want to release my Main-App.
(C#/Wpf-App is included as external Array of Bytes)
Now I want to build a simple tool to do this work, but I dont want to build the "launcher" all the time!
So my idea is just to modify the launcher.
For that I need a way to modify this executable and I need to be able to use this modified data inside the launcher, like it would be compiled.
I dont want to reserve a static sized array inside the launcher, cause I dont know what could be the biggest data-size.
There are different ways to do that. Unfortunately none of them is straightforward nor standard except one: use a makefile that automatically builds the launcher. IMHO, unless you have special requirements such as building the launcher on a system with no development environment, it is probably the most simple and robust way.
As you explicitely ask for other solutions, I will give 2:
on Windows, you could store the c# app as a resource. Once that's done, you can use a resource editor to change it on the fly or build a custom editor using the WinAPI functions BeginUpdateResource, UpdateResource and EndUpdateResource. You later load the resource with LoadResource in the launcher.
you could make the laucher program know its real size and just seek behind that size and load what follows as the C# app. To build it, you just need to copy the actual C++ executable and whatever you want it to process. The hard part here is that there is no portable way to identify the size or the end of an executable at compile time. You could try a two pass build:
first pass, you set the size to an arbitrary value. You build and look at the real size
second pass, you set the size to what has been observed in first pass. As you only modify a size_t value, the size of the executable should not change. But I strongly urge you to control that size twice. Repeat if it is not the same (it could happen if the compiler was too clever and merged identical constants).
But as I already said, my choice would be to use a makefile to automatically generate the launcher each time the C# app is rebuilt
I am a game developer working on a serious game. I have some data simulation taking place as a result of a MATLAB (Simulink) model, that was created by someone who left the team now. All this data simulation generates useful data and allows me to query and check variables when needed. I needed to build a game using this model. So I used the Simulink Code generator to generate the code for my model in C++. This is native C++ and is procedural. The volume of code is high for me to rewrite it, hence I am refraining from doing that. I need to use this code in Unity3d, the engine I am developing the game on.
Long story short. I need to load a native C++ dll (generated by Simulink) in Unity3d.
What I tried:
I tried using the Unity3d's native plugin API. I have pro version and it doesn't seem to detect the dll, and just throws exceptions. I am using the extern keyword to make the required variables public, still no luck.
I tried following this tutorial (http://blogs.abo.fi/alexeevpetr/2011/11/18/simplified-building-simulink-generated-c-code-in-visual-studio/) , but it throws errors and doesn't build, maybe that's because of the version of MATLAB.
I also considered using a wrapper, however that would imply me rewriting most of the code again.
I've never used native dlls in Unity, but you could always try one of the several code bridging methods to call C++ code from C#, I guess. So how about writing a C++/CLI wrapper? It won't force you to rewrite anything. It gives managed access to your unmanaged code, and it's a useful technique to learn anyway.
You should be able to load your native plugin into Unity3D, even if it requires MATLAB libraries (Just make sure they're also in the plugins directory). I recently answered a similar question around this, as it can be fairly tricky to get right. I would suggest you check it out HERE, and modify your question with specific errors and problems you're having trying to loading the native code.
From Geomorillo on U3d forums:
Before anything,
1) install Visual C++ Studio Express 2010 we need the sdk from .NET for compiling, (NOTE:Maybe you can use visual C# express instead for compiling because it require the .NET sdk but no sure )
2)You must setup matlab with the command "mbuild - setup", and choose the compiler Microsoft Visual C++ Studio Express 2010
3) you must have a function already created and saved to a ".m" file mine is called mycos.m here is its contents:
function a=mycos(b)
a=cosd(b);
end
where "a" is the return parameter and "b" the input parameter, it is important to know how many return parameter you have in this case 1 (see step 12)
4) use the "deploytool" command, a window should open, name the project "simplelibs" any name should do, choose a location c:\matlab\simplelib, choose in type .NET Assembly, OK
5) After that new options int form of tabs should appear to the right of your window, the Build and Package Tabs.
In the Build tab you should add a class with the Add class option, it will automaticly was named Class1, but i changed it to Myclass, here you can add your functions to your class using Add files, i've added mycos.m
6) You should have noticed 3 buttons next to the project name, click the 3rd one with the shape of a nut, go to Settings a new window should appear, go to .NET tab and in the Microsoft Framework choose 3.5 to make sure you are using .net 3.5 for compiling(required for unity3d)
7) we are ready to compile, do so with the 1st button, it should take a while....
8) After compiling without errors, the files are in the distrib folder inside your project path , open unity and create a new project. copy the 2 dlls into the root inside unity.
9) Locate de directory "dotnetbuilder" inside "c/.../matlab/../toolbox" copy or drag it all its contents to your unity project.
10) We need the a dll MWArray.dll because when compiling our libraries matlab wraps our function in an Array and it use its methods to access our functions im not gonna explain this, google it please, normally it can be found inside matlab installation dotnetbuilder/bin/win32/2.0/ but since you have copied it to unity dont copy again, when using this mwarray i found a bug with monodevelop in this library so i had to decompile it and fix the bug i've to recompile it again :) you you can download this file here https://dl.dropbox.com/u/6716823/MWArray.dll and replace the one found inside unity project (do not!!! replace the original from matlab directory)
11) create a c# script and asign it to main camera or any object in scene
here is its contents
using UnityEngine;
using System.Collections;
using System;
using MathWorks.MATLAB.NET.Arrays; // import from MWArray.dll
using simplelib;
public class myMatlab : MonoBehaviour {
void Start () {
simplelib.Myclass g = new simplelib.Myclass();
Debug.Log(g.mycos(1,95).GetValue(0));
}
}
12) g.mycos(1,95); // remember when i said it wraps your function !!! the first parameter is the number of parameters returned from our matlab function in this case 1, the 95 is the parameter we want to send to our function, we get an array we can access it with .GetValue(0)
13) play and enjoy
This is an example with a simple function so i dont know if it will work with a more complex program
i hope this works for you
I'm pretty new to WinAPI programming, and have written a Win32 application for screen capture. When I run the program, the cursor immediately changes to a crosshair and I can click and drag to capture a portion of the screen and save it to file.
However, I'd now like to modify my program so that it doesn't contain a main method (WinMain) and essentially turn it into an object class rather than an application class so I can call functions from other programs. I haven't been able to find a good resource on how to do this, as I believe WinMain carries out special functionality under the hood so I can't simply change the name of the method.
Can anyone suggest some good resources or tutorials that address this?
There are many ways to do that, but you have fist move one step back:
How do yopu expect your "program" (let us continue to call that way) to be called?
With which parameters and what return type?
Then, what kind of API do you want to expose? A C++ class in header? a C++ class from a static library?
A C function exported from a DLL? an COM object?
There are many sample on how a library or a DLL or a COM library looks like (just try google those keywords).
The simple way is most likely to set up a library or a DLL project (most IDE have wizard that provide empty skeletons), than paste in it the relevant code that you require to leave there, letting it be called from the exposed function or class method.
A more precise answer can be given only after you decided which "form" your "object" should have.
So at work I have been working for a few months on a OPOS driver for a few different things. I didn't create the project, but I have taken it over and am the only one developing it. So today I got curious about the way that it was done and I think that it may have started off on the wrong foot. I had to do a little bit of digging to find out that it uses the OPOS drivers from a company called MCS (Monroe Consulting Services) I downloaded 1.13 and installed the MSI version. I fired up VS created a new mfc dll. I then went to add a class. This is where I am confused.
It doesn't matter if i choose Typelib or ActiveX it usually gives me the same list of interfaces that I can add/extend from(with one exception that comes to mind with MSR it has an events interface that I can extend) And they both make the same header file (in the case with msr it is COPOSMSR.h) but one extends CCmdTarget, and the other extends CWnd. This is my first question. Which should I choose? what is a typelib/ what is a ActiveX component and how do they differ from one another.
The one i've been working on extends CCmdTarget. For the life of me I can not figure out how the driver knows to use one of the files (USNMSRRFID) but that is where all the development went into. (I broke it up a bit so it wasn't just one huge file) But that file doesn't extend COPOSMSR..it extends CCmdTarget as well. The only time i see anything mention the USN file is in MSRRFID.idl (which confuses me even more) Any one have clarity for this?
Part of me thinks this could make a very big impact when it comes time to deploy. A few of the test apps that have been written that make use of this driver require a somewhat confusing setup process that involves registering different drivers, copying files into a specific folder, setting up the registry and so forth. I think that if i can get a grip on what this all means and how to make a nice application that extends one of these OPOS devices properly that I could save my self further grief in the future.
Any tips or pointers??? Sorry if it is a newb question..but i am new to C++. I started with Java then moved to C# so some of this stuff is WAY over my head....
Well so I've done TONS of digging, and it is like searching for dinosaurs. Not easy, and hard to find. I will end up writing a nice little how to on this, but for now I will put up my findings. Although I still don't have this 100% i know I am close.
Turns out the typelib and activeX things are not a big concern but come into play after you've gotten started. ActiveX is for Control objects, and Typelib is for the Service Object. The most important thing is to get started correctly. I found a article on some Chinese website that offers some OK tips after figuring out the translation errors. To start with you will want to make a C++ project with Automation. It can be ATL or MFC. My preference is MFC. In the UPOS 1.13 pdf (or newer) in Appendix A section 8 it describes the responsibilities of the Service object. It has the main methods you need to implement. There are 16 methods you have to add, and at least 4 methods that get/set the properties for your OPOS device.
So to get started you will need to open up the add class wizard (for MFC classes) and click Add MFC class. You wil want your base class to be CCmdTarget. Come up with a classy Class name (I chose PinpadSOCPP) Then in the automation radio buttons select Creatable by type ID. It should fill in your type id as [Project Name].[Class name] so mine was PinpadSO.PinpadSOCPP. hit finish. This makes a nice interface file that you can use Class view to add methods and so forth to it.
As for adding the methods there are 2 things to note about this, and one of them I haven't figured out 100% yet. The first is that you have to implement all the methods in that section with the correct parameters and return values. Most of them return LONG (32bit signed number). and the 2 most common parameters are LONG and BSTR. (there is the occasional pointers for when you have "out" parameters) This is the part that I think that I am currently failing as I don't know if I have them all implemented correctly and that is why I am getting error 104/305 (which from the Chinese article says that I am missing something from my methods) I'm not sure if it is case sensitive, and I'm not sure of the 7 properties that look to need to have get/set which ones need to be implemented because the MSR SO that i am working on from work doesn't use them all and that SO is working. The other is that after you implement the base OPOS methods you have to also implement the extra methods from your specific OPOS device. Since I am doing PINPad there are 6 additional methods I have to implement.
Now this is a lot of time consuming work because you have to open up class view, navigate to the name of your project class. Expand it and go to the Interface portion. My Project name is PinpadSO, and the file that I am implementing this in is PinpadSOCPP (which means the interface name is IPinpadSOCPP) right click on IPinpadSOCPP and click add > add method. This brings you to a 2 step process. You fill in your return value, name of your function, add in all your parameters. Hit next and fill out some help string info (if you want) and hit finish. Now after you do that 20+ times it gets old and slow...and if you are like me you type Computer instead of Compute and flip flop letters, or forget to hit add on all your parameters. A person could make a nice little program to edit the 3 files that get changed each time you add a method and that would speed it up considerably. If you make a mistake you will need to open up [project name].idl, [class name].h, and [class name].cpp those are the 3 files that get the methods added to it directly. I recommend not making a mistake.
so now that all that hard work is out of the way. Compile your program. If you want to save your self an extra step you could turn on Auto Register in the linker project settings (NOTE: if you do that you'll need to run Visual Studio as admin if you program in vista or higher) this would save you of having to open a command window (admin) navigate to your DLL and use the command regsvr32 on that DLL. Nice thing is that you don't have to do that over and over again, just the once will do. I have no hard facts that it works like that every time but the MSR SO that I am working on, I'll make changes to it, compile it, then open up my OPOS tester program and the changes have taken affect.
After that you need to make your registry additions. navigate to HKLM\software\OLEforRetail\ServiceOPOS
(NOTE if you have a x64 machine you'll do this twice. One there, and again at HKLM\software\Wow6432Node\OLEforRetail\ServiceOPOS )
You'll need to add a Key for whatever OPOS device you are working with. I am making a pinpad SO so I made a Key called PINPad (check your UPOS document to see what name you should give it) Lastly choose a name for your device. I chose the model type of the from the vendor as my device name (C100) and made a sub key in PINPad. The default REG_SZ value needs to be your registered SO Device TypeID. in my case it is PinpadSO.PinpadSOCPP
if you don't have a OPOS test program (which I just made my own as a console program) then you can use the Microsoft OPOS test app (I couldn't get it to work on my x64 machine...but maybe you'll have better luck with it) If you do decide to make your own OPOS test app make sure you compile it for x86 machines (even if you have x64) OPOS does not like x64 for some reason (probably the pointers length I'd assume)..at any rate. Once you got it all setup run your test app (for my case I am just running OPOSPinpadClass pin = new OPOSPinpadClass(); Console.WriteLine(pin.Open("C100")); and hope for 0 :)
I am currently getting 104 (E_NOSERVICE)..and like i said before i think it is because I don't have all my methods correct. If that turns out to be the case I'll edit this response, or I'll report back and say what it really was.
Anywho, i hope this helps anyone else who decides they want to make their own SO. Good luck
UPDATE
OPOS checks a couple of properties when you call the Open command. One of the properties that is a must to implement is the in the GetPropertyNumber, and it is PIDX_ServiceObjectVersion. You will need to set this number to return (1000000 * majorVersion) + (1000 * minorVersion) + revision since I am making a OPOS 1.13 compatible SO my returned ServiceObjectVersion is 1013000. You will also want to implement 3 properties in GetPropertyString:
PIDX_DeviceDescription
PIDX_DeviceName
PIDX_ServiceObjectDescription
For all other values you can return a empty string or 0 until you start hooking all those things up.
As a side note if you don't want to make it in C++ you don't have to. You can make it in any language that you can write a ActiveX object in (such as a COM visible .NET class library)