This is a portion of the code for the application below. Blitz3D is stating that the CreateWindow, CreatePanel, and SetPanelImage functions do not exist. Am I missing a library or something?
Global ResWidth% = 910
Global ResHeight% = 660
Global VersionNumber$ = "1.5"
Loadingwindow=CreateWindow("", GraphicsWidth()/2-160,GraphicsHeight()/2-120,320,260,winhandle,8)
panelloading = CreatePanel(0,0,320,260,Loadingwindow,0)
SetPanelImage(panelloading,"Assets\map_logo.png")
; create a window to put the toolbar in
WinHandle=CreateWindow("Map Creator SCPCBR v"+VersionNumber,GraphicsWidth()/2-ResWidth/2, GraphicsHeight()/2-ResHeight/2,ResWidth,ResHeight,0, 13)
Global MainHwnd = GetActiveWindow();User32.dll
HideGadget WinHandle
There are two different versions of BlitzBasic which you have to distinguish:
Blitz3D
BlitzPlus
Blitz3D supports many functions for 3D game development. BlitzPlus provides many functions for GUI design. However, there is no BlitzBasic version which supports both features at the same time.
In any case, you have three options:
"I don't need 3D features": use BlitzPlus instead of Blitz3D to compile your program
"I need 3D features, but my GUI does not have to look like Windows style": use a community plugin for Blitz3D to create GUI elements (e. g. Draw3D)
"I need 3D features and Windows like GUI elements": Implement your game menu(s) in BlitzPlus and the actual game in Blitz3D
Related
I'm trying to write a simple machine learning application in Ada, and also trying to find a good framework to use. My knowledge of one thing is extremely minimal, and of the other is somewhat minimal.
There are several nifty machine learning frameworks out there, and I'd like to leverage one for use with an Ada program, but I guess I'm just...at a loss. Can I use an existing framework written in Python, for instance and wrap (or I guess, bind?) the API calls in Ada? Should I just pass off the scripting capabilities? I'm trying to figure it out.
Case in point: Scikit (sklearn)
https://scikit-learn.org/stable/tutorial/text_analytics/working_with_text_data.html#
This does some neat stuff, and I'd like to be able to leverage this, but with an Ada program. Does anyone have advice from a similar experience?
I am just researching, so I have tried finding information.
http://www.inspirel.com/articles/Ada_Python_Binding.html
https://scikit-learn.org/stable/tutorial/text_analytics/working_with_text_data.html#
The inspirel solution is based on python2.7. If you're using anything from python3.5 onwards a few mods need to be made. On Linux, changing to say python 3.7, you'd just change
--for Default_Switches ("Ada") use ("-lpython2.7");
for Default_Switches ("Ada") use ("-lpython3.7");
but on windows, the libraries aren't dumped in a community lib so gnat doesn't know where to find them. All the packages are kept separately. The -L has to be added to tell the linker where to find the library. Alternatively, you can use for lib_dir. In my case, I did a non-admin install of python, so it looks something like
for Default_Switches ("Ada") use ("-L\Users\StdUser\AppData\Local\Programs\Python\Python37-32\libs", "-lpython37");
Note that on windows, the library is called python37: not python3.7. Use gprbuild instead of gnatmake -p, which has been deprecated. If you do all your mods correctly
gprbuild ada_main.gpr
should give you an executable in obj\ada_main.exe if it builds. If a later version of python is used, some edits need to be made
python_module.py
#print 'Hello from Python module'
print('Hello from Python module')
#print 'Python adding:', a, '+', b
print('Python adding:', a, '+', b)
ada_main.adb
-- Python.Execute_String("print 'Hello from Python!'");
Python.Execute_String("print('Hello from Python!')");
Some routines have been deprecated so the linkage has to change
python.adb
--pragma Import(C, PyInt_AsLong, "PyInt_AsLong");
pragma Import(C, PyInt_AsLong, "PyLong_AsLong");
--pragma Import(C, PyString_FromString, PyString_FromString");
pragma Import(C, PyString_FromString, "PyUnicode_FromString");
Running the build and executable should give
C:\Users\StdUser\My Documents\ada-python>gprbuild ada_main.gpr
Compile
[Ada] ada_main.adb
Bind
[gprbind] ada_main.bexch
[Ada] ada_main.ali
Link
[link] ada_main.adb
C:\Users\StdUser\My Documents\ada-python>obj\ada_main.exe
executing Python directly from Ada:
Hello from Python!
loading external Python module and calling functions from that module:
Hello from Python module!
asking Python to add two integers:
Python adding: 10 + 2
Ada got result from Python: 12
we can try other operations, too:
subtract: 8
multiply: 20
divide : 5
Remember to put the pythonxx.dll somewhere on your path otherwise it won't be able to find the library when it starts executing.
I have an issue working with DiagramBuilder and ManipulationStation classes.
It appears to me, that c++ API and the python bindings work differently in my case.
C++ API behaves as expected, while the python bindings result in the runtime error:
DiagramBuilder: Cannot operate on ports of System plant until it has been registered using AddSystem
How I use C++ API
In one of the ManipulationStation::Setup...() methods I inject a block of code, that adds an extra manipuland
const std::string sdf_path = FindResourceOrThrow("drake/examples/manipulation_station/models/bolt_n_nut.sdf");
RigidTransform<double> X_WC(RotationMatrix<double>::Identity(), Vector3d(0.0, -0.3, 0.1));
bolt_n_nut_ = internal::AddAndWeldModelFrom(sdf_path, "nut_and_bolt", lant_->world_frame(), "bolt", X_WC, plant_);
I inject another block of code into the method ManipulationStation::Finalize:
auto zero_torque = builder.template AddSystem<systems::ConstantVectorSource<double>>(Eigen::VectorXd::Zero(plant_->num_velocities(bolt_n_nut_)));
builder.Connect(zero_torque->get_output_port(), plant_->get_actuation_input_port(bolt_n_nut_));
With these changes, the simulation runs as expected.
How I use python bindings
plant = station.get_multibody_plant()
manipuland_path = get_manipuland_resource_path()
bolt_with_nut = Parser(plant=plant).AddModelFromFile(manipuland_path)
X_WC = RigidTransform(RotationMatrix.Identity(), [0.0, -0.3, 0.1])
plant.WeldFrames(plant.world_frame(), plant.GetFrameByName('bolt', bolt_with_nut), X_WC)
...
station.Finalize()
zero_torque = builder.AddSystem(ConstantValueSource(AbstractValue.Make([0.])))
builder.Connect(zero_torque.get_output_port(), plant.get_actuation_input_port(bolt_with_nut_model))
This triggers a RuntimeError with a message as above; The port, which causes this error is nut_and_bolt_actuation.
My vague understanding of the problem is the (in) visibility of nut_and_bolt System, due to having two distinct DiagramBuilders in a process: 1) a one is inside ManipulationStation 2) another is in the python code, that instantiates this ManipulationStation object.
Using ManipulationStation via python bindings is a preference for me, because that way I would've avoided depending on a custom build of drake library.
Thanks for your insight!
I agree with your assessment: you have two different DiagramBuilder objects here. This does not have anything to due with C++ or Python; the ManipulationStation is itself a Diagram (created using its own DiagramBuilder), and you have a second DiagramBuilder (in either c++ or python) that is connecting the ManipulationStation together with other elements. You are trying to connect a system that is in the external diagram to a port that is in the internal diagram, but is not exposed.
The solution would be to have the ManipulationStation diagram expose the extra nut and bolt actuation port so that you can connect to it from the second builder.
If you prefer Python, I've switched my course to using a completely python version of the manipulation station. I find this version is much easier to adapt to different student projects. (To be clear, the setup is in python, but at simulation time all of the elements are c++ and it doesn't call back to python; so the performance is almost identical.)
I am looking at some old MetaEditor4 / MQL4 code, where a local variable was declared twice:
......
1 int start()
2 {
3 if (1==2)
4 {
5 double myVar = 1;
6 } else
7 {
8 double myVar = 2;
9 }
10 return;
11 }
.......
The compilation process in MetaEditor, version 5.00, build 1601, fails with:
'myVar' - variable already defined in line 8.
If I remove the line 8, the compilation goes well.
My questions are:
1. Is there any option in MetaEditor that tolerates the multiple declaration of a local variable?
2. In previous versions of MetaTrader Terminal 4 / MetaEditor and .MQ4 code: was it possible to declare a local variable more than once in such a situation?
3. The MetaEditor has the version 5.00, build 1601, but the extension of the code is .mq4 and it was installed together with the MetaTrader Terminal software MetaTrader4 ( from FXCM ). Therefore I assume I can still use .MQ4 code with it. Is there any chance to get a pure MQL4 installation from somewhere?
Whenever I install mt4 ( from e.g.: mt4 download), it ends up
with the mt5 installer.
Prologue:
The worlds of MQL4 evolve. One may try to circumvent this fact, but finally, at one's own disappointment, attempts to avoid evolution will sooner or later go in vain.
Having been thrown into a need to re-engineer code-base spanning a few man*decades in size, I can tell you many stories about what worked and what did not.
An "Old code" v/s a New-MQL4.56789
If just one thing ought be taken from this, never try to "circumvent" New-MQL4, but rather review the code and refactor the "Old code" - this is a way safer way to survive ( way longer ).
Yes, there are chances ( zero warrants, just a few chances left temporarily on the table ) the new compiler version will remain able to generate an executable version of the code, but given a new set of rules have already come in the city, the game will not last long.
Ad 1 + 2 )Compiler still tolerates multiple declarations, but not in one scope
If new version of a compiler defined that any variable is declared only relative to it's scope of validity, the serious programmer ought take this as a general principle. The code above actually has other problem, right nailed to the scope-of-validity:
2 ...
3 if ( 1 == 2 ) {
4 ...
5 double myVar = 1; // myVar declared & known |since HERE >
6 ... // masking any other,|known HERE :
7 ... // |known HERE :
8 } else // |till HERE . Undef further
9 {
10 ...
11 double myVar = 2; // myVar declared & known |since HERE >
12 // masking any other,|known HERE :
13 ... // |known HERE :
14 } // |till HERE . Undef further
so, if there were any _global_ scope'd variable with the same name myVar, it will not be "visible" during an existence of locally declared variable, wearing the same name.
Finally, having the code-execution escaped from any of the lines 8 or 14 further, the locally there declared variable double myVar simply ceased to exist anymore and this behaviour is principally correct ( and the "older" compiler releases were tolerating a sort of dangerous habit of side-effects, during years of tolerating scope-of-validity spillover(s), so it was the high time to clean the rules, so as to meet a fair level of C/S standards.
Ad 3) language receives a lot from MQL5, even if not used in MQL4
Yes, MetaEditor will correctly compile a MQL4 code into .mq4 code-execution format, no problem here. Even an auto-update process started to go independently from MT4 Terminal platform (auto-)updates ( so you will quite often see new Help file coming and enforced re-compilation of all your localhost visible .MQ4 assets into updated .EX4 format, so "Do not panic."
Better never install a Broker-agnostic MT4, always go to your Broker's Support and get installation package & help from your Broker. This is business relation you have signed in a contract, so keep these strings as you are going to trade your money on a table they operate under the set Terms & Conditions. Some Brokers have means of platform customisations, so rather benefit from their custom settings that will match their Server-side automation.
It is more a question of economy of R&D efforts. ( May read a lot about language components injected from the MQL5 domain in the IDE Editor MQL4 Help ). This is a natural will of the product design strategy, not to double efforts on a dual-line. Without doubts, there are many details the Help file could be improved and better maintained, the common sense here is to live with the facts and re-learn what newly introduced features remain neutral for the MQL4 code base and what new things may actually help one a lot in aspects, where older compilers were short in powers.
If one objects that some compiler / platform re-design steps were bad, I would agree on a single-thread, platform-critical, potentially blocking, concentration of executing all the CustomIndicator-s in just one SPoF-thread.
But C'est La Vie, until system architects will not review this SPoF, the platform will remain susceptible to crashes from this feature, but the ball is on the other side of the court and a change will have to be implemented there.
the code might be run with 'strict' or non-strict mode.
strict means that variable must be declared within its scope, non-strict - all the mess that you have now.
so put #property strict at the beginning of the file
open a demo account somewhere and install mt4 there. demo can be valid for 30 days only with registration via web-site of a broker or with unlimited and demo opened from mt4 (example - Alpari)
I am developing a Firefox add on, I pretend my add on to be able to run in both desktop and mobile devices. I think more or less everything is compatible with both environments, however there are pieces of code that I would like to run depending on whether the current device is mobile or desktop, so the question is if there is something like system.isMobile() that can be used in the following way:
var system = require("sdk/system");
if(system.isMobile())
console.log("firefox for android");
else
console.log("normal firefox");
As you can find at the system api documentation, there is a variable telling the operating system.
code:
var system = require("sdk/system");
console.log("system platform = " + system.platform);
output:
system platform = linux
disclaimer: I didn't tested on mobile environment.
You can use the System High-Level API. system.platform will contain the information on the type of OS the user is running.
You can use it like so:
var system = require("sdk/system");
var platform = system.platform // Will contain platform, i.e. Windows, Linux, etc.
// You can log this data to the console
console.log("System Platform = " + platform);
When you call system.platform, it will usually return one of the values listed on this page, converted to lowercase
I want my application to always run using the real gpu on nVidia Optimus laptops.
From "Enabling High Performance Graphics Rendering on Optimus Systems", (http://developer.download.nvidia.com/devzone/devcenter/gamegraphics/files/OptimusRenderingPolicies.pdf):
Global Variable NvOptimusEnablement (new in Driver Release 302)
Starting with the Release 302 drivers, application developers can
direct the Optimus driver at runtime to use the High Performance
Graphics to render any application–even those applications for which
there is no existing application profile. They can do this by
exporting a global variable named NvOptimusEnablement. The Optimus
driver looks for the existence and value of the export. Only the LSB
of the DWORD matters at this time. A value of 0x00000001 indicates
that rendering should be performed using High Performance Graphics. A
value of 0x00000000 indicates that this method should be ignored.
Example Usage:
extern "C" { _declspec(dllexport) DWORD NvOptimusEnablement = 0x00000001; }
The problem is that I want to do this using Delphi. From what I've read Delphi does not support export of variables even though some hacks exists. I did try a few of them but couldn't make it work.
In the same nvidia document I read that forcing the proper GPU can be accomplished via linking statically to one of a handful listed dlls. But I don't want to link to dlls I'm not using. (Why the opengl.dll is not one of them is beyond me.) A simple exported variable seems much cleaner.
From what I've read Delphi does not support export of variables.
That statement is incorrect. Here's the simplest example that shows how to export a global variable from a Delphi DLL:
library GlobalVarExport;
uses
Windows;
var
NvOptimusEnablement: DWORD;
exports
NvOptimusEnablement;
begin
NvOptimusEnablement := 1;
end.
I think your problem is that you wrote it like this:
library GlobalVarExport;
uses
Windows;
var
NvOptimusEnablement: DWORD=1;
exports
NvOptimusEnablement;
begin
end.
And that fails to compile with this error:
E2276 Identifier 'NvOptimusEnablement' cannot be exported
I don't understand why the compiler doesn't like the second version. It's probably a bug. But the workaround in the first version is just fine.
I'm not a Delphi expert, but AFAIK it is possible to link to static libraries implemented in C from Delphi. So I'd simply create a small stub library, just providing this export, which is statically linked into your Delphi program. This adds the very export you need.