I was trying to learn SDL2 and was trying to figure out how SDL_CreateWindow was implemented. All I could find out was this
extern DECLSPEC SDL_Window * SDLCALL SDL_CreateWindow(const char *title,
int x, int y, int w,
int h, Uint32 flags);
and a #define in the code
#define SDL_CreateWindow SDL_CreateWindow_REAL
Is it loaded via a dll or something? Is there a way I can see the definition?
I tried looking around the SDL.sln but didnt get any good matches.
Those *_REAL-suffixed names are an artifact of SDL's dynapi system that lets end-users update the SDL version of programs that statically link against it.
git grep-ing the source for SDL_CreateWindowTexture should lead you to the actual implementation at src/video/SDL_video.c:221
Related
I have problem with display image (I tried to rewrite engine from SDL to SFML 2.0; engine downloaded from:
http://gamedevgeek.com/tutorials/managing-game-states-in-c/
)
I have problem with especially that part of code that is in introstate.cpp.
The program compiles and create window (just for one sec) and then vanishes with no reaction and no render anything (it should display image).
I think it has to do with range of object sf::RenderWindow MarioClone. I mean it was declared in few headers and used in variety methods, so I think there's misunderstanding with pointing to the specific window that is created. Should I use "extern" keyword somwhere or what?
I leave link to github because code is in many files and even one file contains a lot of code and don't want to paste it here (it would be hard to read).
https://github.com/shahar23/MarioClone
(And yes - the code has previous original SDL commented to understand easily what should be put in methods instead)
In your gameengine.cpp file, in your init method, you create a local variable of the same name as the variable declared in your header file. That's not what you want. You want to change the existing variable:
void CGameEngine::Init(const char* title, int width, int height, bool fullscreen)
{
// This line creates a NEW LOCAL variable of the same name.
// Your instance level variable remains unchanged:
// sf::RenderWindow MarioClone(sf::VideoMode(width, height), title, sf::Style::Default);
// instead, change your class level variable:
MarioClone.create(sf::VideoMode(width, height), title, sf::Style::Default);
I am working on a little project in C++ with SDL2. I am trying to create a global window which I can use in my other .cpp files, but I cant figure out how to make a global variable in SDL. And please don't write something like "Don't use global variables", because I have to use them, otherwise it won't work.
In every file you need it just declare it as extern SDL_Window* GWindow; and use it; then in single .cpp file define it SDL_Window* GWindow = nullptr;
What are the rules for painting to the screen?
My end goal is to put the TCanvas into a class and paint from there, but for now I think that maybe looking at a less complicated example might help. Below is some code that compiles and paints to the screen, on my computer.
# include <TApplication.h>
# include <TCanvas.h>
# include <TH1D.h>
# include <thread>
# include <chrono>
//TCanvas canvas ("fCanvas", "fCanvas", 600, 400);
int main ( int argc, char* argv[] )
{
TApplication app ("app",&argc,argv);
TCanvas canvas ("fCanvas", "fCanvas", 600, 400);
//TCanvas* canvas = new TCanvas("fCanvas", "fCanvas", 600, 400);
TH1D h ("h","h",10,0,10);
h.Fill(1);
h.Fill(2);
h.Fill(2);
h.Fill(2);
h.Fill(3);
h.Fill(3);
h.Draw();
canvas.Update();
canvas.Draw();
std::this_thread::sleep_for( std::chrono::seconds(3) );
return 0;
}
You may notice some commented-out lines. If I use either of those definitions of canvas, using the appropriate member access operators on the later-called Update and Draw methods, the application crashes after printing a blank TCanvas-window to the screen. It also crashes if I change app and h to pointers.
If I try to instantiate a class using any sort of ROOT object at all, it crashes the application.
Right now, I'm compiling with MSVC++'s cl.exe and linking with link.exe. I'm working on a 64-bit Windows 7 Enterprise N. I'm trying to port an application that I built in Unix, for which a simple new TApplication("name",0,0); at the start of main made everything work.
So, to reiterate: how can I get my histograms onto the screen in this OS, and maybe others? I doubt that I'll be able to understand the "why", but it might be nice to write something about that for others reading this who can. Otherwise, just a step-by-step description of how to use these objects to paint would be wonderful.
Many thanks for any help on this; I'll gladly provide more information / examples if that should prove useful.
Update: it works in my particular case if I compile with something like
cl -nologo -DWIN32 -W3 -D_WINDOWS -Z7 -MDd -GR -EHsc main.cxx -I %ROOTSYS%\include -FIw32pragma.h /link -debug -LIBPATH:%ROOTSYS%\lib libCore.lib libRIO.lib libHist.lib libGpad.lib
Not sure why.
See https://root.cern.ch/phpBB3/viewtopic.php?f=3&t=3402&p=85329&hilit=Vector+stl+of+TH1F*+Objects#p85329 .
I usually use TApplications like below to have TCanvases really appear as window on the screen.
#include "TApplication.h"
// other stuff
int main(int argc, char** argv) {
TApplication theApp("App",&argc, argv);
// your code
// here you can Draw() things
theApp.Run();
return 0;
}
The program then just stops at Run() and I end the process with ^C.
The title is pretty self explanitory: I'm trying to run a process outside of main.cpp using loadfile.cpp and loadfile.h to handle loading and displaying an image. However, Marmalade keeps throwing build errors when I do this.
At a top level, I am looking for a process that will run in main.cpp, make a call to loadfile.cpp and display an image with the code in loadfile.cpp. Ideally:
in main.cpp:
main()
{
//initialize and setup Marmalade stuff
Img* myImg; //create an image object
while (!s3eDeviceCheckQuitRequest()) {
//More Marmalade stuff
myImg->display(); //display said image
}
delete myImg;
return 0;
}
in loadfile.cpp:
#include "loadfile.h"
Img* myImg; //image object
void Img::displayImg()
//display image
and in loadfile.h:
#if !defined(_LOADFILE_H)
#define _LOADFILE_H
class File
{
public:
void displayFile();
};
extern Img* myImg;
#endif //_LOADFILE_H
Can someone point out what I am doing wrong or write a brief script showing me it? Thanks very much!
P.S. I wrote this following the Stage 2 Marmalade looking at what they do with the input.cpp/.h files and Input class. I have the full code available if that would be of help!
You need to mention all of your source files in the mkb, before you can use them in your project. Look for the mkb's source section to add the files. Once done, reload the mkb to find the newly added file in your project automatically.
In c++, we are used to see that opengl is installed in main function.Such as-
int main(int argv,char **argc){
glutInit(&argv,argc);
glutInitDisplayMode(GLUT_DOUBLE| GLUT_RGB|GLUT_DEPTH);
..............................
}
But without this main function,how can we declare opengl in other sub functions?
Such as-
int main(){
...........}
int installopengl(int argv,char **argc){
glutInit(&argv,argc);
glutInitDisplayMode(GLUT_DOUBLE| GLUT_RGB|GLUT_DEPTH);
..............................
}
Maybe I misunderstood - why cant you directly call the function like below ?
int main(int argv,char **argc) {
installopengl(argv, argc);
...........
}
int installopengl(int argv,char **argc) {
glutInit(&argv,argc);
glutInitDisplayMode(GLUT_DOUBLE| GLUT_RGB|GLUT_DEPTH);
..............................
}
Please get your terminology right. OpenGL is not installed in a program. It get's initialized.
Also the pattern you quoted is GLUT initialization. GLUT is not OpenGL, but a simple windowing framework, that creates a OpenGL context for you to use to draw to the window. But there are several other frameworks as well.
Then you seem to completely misunderstand what the main function does. main is the program entry point, the very first function that gets called in a process after the runtime environment has been set up. main can call any function, and you can simply call a dedicated framework initialization there. If it needs parameters from main you simply pass them along.
While it is defiantly not recommended, you can always do this:
int i = 0;
glutInit(&i, NULL);
The issue with doing it this way is that you won't be able to pass any information to the glut library from the command line.