Game Developement

[Realeg]

Hello!
I've been learning the SDL2 library for graphic development. And here is where i got stuck. I need to load a texture as a *.bmp file from my computer, and the procedure looks like this: "texture:=IMG_LOADTEXTURE(<render>,<path to file>);"
The path to the file is for me the big problem. I don't know how to make the application to load a texture file from the folder where the .exe is. For example, if the aplication is in C:\X-FOLDER\Y-FOLDER, how can i load a texture from Y-FOLDER without writing the whole path?To write instead of 'C:\X-FOLDER\Y-FOLDER\file.bmp\, just 'file.bmp'?

[SilverWarior]

The path to the file is for me the big problem. I don't know how to make the application to load a texture file from the folder where the .exe is. For example, if the aplication is in C:\X-FOLDER\Y-FOLDER, how can i load a texture from Y-FOLDER without writing the whole path?To write instead of 'C:\X-FOLDER\Y-FOLDER\file.bmp\, just 'file.bmp'?

You can extract the executable path from the FileName of your executable file using:

MyAppPath := ExtractFilePath(Application.ExeName);

Also I strongly recomend you don't store your resource files in your application folder but instead create seperate subfolders for this like:
MyAppPath\Data\Images
MyAppPath\Data\Sounds
MyAppPath\Data\Videos
MyAppDataLevels
and so on.
This way you nicely organize your files so you can quickly find specific file manually when you need it.

When dealing with paths it is also good to make use of IncludeTrailingPathDelimiter method to make sure that all your paths are proprly ended with TrailingPathDelimiter character so you don't need to worry by yourself wheter specific API function returns path with or without the TrailingPathDelimiter

[Realeg]

I've tried the the second solution from the very beginning. The error is now that i got a short string instead of pChar. I've tried this solution, but it had the same result.

path:=pChar(ExtractFilePath('grafica.exe'));

EDIT: The fact is that i just realise that by writing the upper instruction, the path variable is empty. Only if you write the whole path it is kept in the variable, the problem i want to avoid. In the problem with the short-string to pChar, i solved, the problem is this thing now. Getting the file path, without writing the whole path

If i write

path:=pChar(ExtractFilePath('C:\Pascal\Projects\grafica.exe');

the variable will keep C:\Pascal\Projects\, otherwise it will be empty.

[SilverWarior]

When you use

ExtractFilePath('grafica.exe');

your program tires to search for file named grafica.exe in your current directory also know as working directory which may not be the folder from which your application was launched and then extract its path. If the file can't be found in current directoy you will get empty path as a result.

So extract your program path using

MyAppPath := ExtractFilePath(Application.ExeName);

as I have suggested to you in the first place.

Now you already know what ExtractFilePath method does right.
And Application.ExeName property returns the full filename of your program executable from which you can extract path to the folder in which your executable resides.

[Anton]

For which operating system do you compile your program? For windows or linux?

About the amount of memory, you should definately be able to get information from the memory manager about the allocated memory size. But when you use external libraries usually they allocate memory using their own memory managers so you cannot catch their memory usage. If you need to monitor you program's memory usage and track for memory leaks and your program is running on windows, i can definately advise you to try this program - VMMap. It can monitor the memory blocks your process has allocated, and it can trace the call stack of each allocation.

About performance, you could measure execution time of your whole program or separate procedures very easily. For example if you want to measure how much time does it take to execute procedure called DoSomething(), then you can do like this:

var 
  T: Int64;
begin
  T := GetTickCount;
  DoSomething();
  T := GetTickCount - T; //Now variable T will hold the execution time of your procedure in milisecond units.
  //Output this value somewhere you can see it.
End;

[SilverWarior]

@Anton
As far as I know the TickCount can be updated more than once per ms. I think that many newer computer already update tckCount every half millisecond.
This means that variable T in your suggested code might not represent time taken in ms. Now it is possible to retrieve information from OS to see how often is TickCount updated so you can then properly calculate the time taken.

Newer versions of Delphi also provides a special record called TStopWatch which tries to use the approach with best percision that is available on your computer. I have use it several times now for time profiling.

But most of the times I simply go and store a time at the start of the process and another at the end and then check how much millisceconds did pas between them.
Now you would probably say SilverWarior that approach doesn't provide good enough accuracy.
That usually doesen't present a problem to me becouse if posible I tend to repeat certain procedure multiple times and check how much time is taken for that.
Why am I doing so? Nowadays all computer support CPU autothrotling which can affect the test performance. Not to mention that you always have bunch of other processes running in the background which can consume veriable amounts of CPU power and greatly screw up your tests.