Who's Online |
47 user(s) are online ( 32 user(s) are browsing Forums)
Members: 0
Guests: 47
more...
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
|
Quite a regular 
|
@kas1e For example something like:
static int linenum = 0;
static SDL_bool CompileShaderProgram(ShaderData *data)
{
(...)
if (!something)
{
linenum = __LINE__;
return SDL_FALSE;
}
(...)
linenum = __LINE__;
return stuff ? SDL_TRUE : SDL_FALSE;
}
static SDL_bool InitShaders()
{
(...)
if (!CompileShaderProgram(...))
{
printf("failed at line %d\n", linenum);
}
}
Basically you add a linenum = __LINE__; before return statements to track where it returned.
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
|
Quite a regular 
|
@kas1e Yeah, it's probably not a compiler issue, but likely related to something going in inside the opengl library. Did you try adding a global variable for CompileShaderProgram? Just set it to __LINE__ before every return, and print it in InitShaders. This way you'll have a better idea of which point it fails.
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
|
Quite a regular 
|
@kas1e I don't necessarily mean printfs, but for example commenting out returns or setting a variable to the line number that you print later.
|
|
|
|
Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
|
|
Quite a regular 
|
@kas1e Aha, so you had to introduce a small delay before compiling the shaders, I was completely off the mark. Is this is the program in question? https://fossies.org/linux/SDL2/test/testshader.cIn this case it would be good to know at which point CompileShaderProgram returns FALSE.
|
|
|
|
Re: Why "prinfs" or any functiosn can cause different results of the code blocks ?
|
|
Quite a regular 
|
This can be a sign of the optimizer doing something funny. Try to compile this file with -O0, or if the compiler supports it add __attribute__((optimize("O0"))) to the affected function. If that fixes the problem you can either leave that function unoptimized, or you can try to make problematic variables "volatile".
|
|
|
|
Re: Is anyone have readdir_r() implementation for aos4 ?
|
|
Quite a regular 
|
@trgswe I stand corrected, it's from Chromium. It still works in most cases if you have readdir.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
|
Quite a regular 
|
Ah, I see. The player only uses the C library for file I/O, so it's hard to guess which function allocates some system object down the line. The leak could also affect other platforms, so hopefully it'll be fixed in 0.7.1.
|
This is just like television, only you can see much further.
|
|
|
Re: Is anyone have readdir_r() implementation for aos4 ?
|
|
Quite a regular 
|
You can just do this:
int readdir_r(DIR *dirp, struct dirent *entry, struct dirent **result)
{
*result = readdir (dirp);
return *result != NULL ? 0 : -1;
}
This is taken from glibc: https://chromium.googlesource.com/chro ... 961001/dirent/readdir_r.c
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
|
Quite a regular 
|
@broadblues That makes sense, but I'm still none the wiser why RunCommand appeared in the Player, which AFAIK doesn't start any other executables. All I did way replacing the pixman library with the static version, and backported a fix to the filesystem code.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 11/30 19:25
#10
|
Quite a regular 
|
Same here, but I have no idea where it's coming from. The Player never used RunCommand, and I certainly didn't add it now either.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/29 17:49
#11
|
Quite a regular 
|
I applied the ZIP fix from upstream, and replaced pixman with the static library and uploaded a new archive.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/16 20:38
#12
|
Quite a regular 
|
I think BeWorld fixed some issue with ZIP files, I'll check it later.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/16 15:02
#13
|
Quite a regular 
|
It didn't even occur to me that he could be missing the library, since the Player worked sometimes. I never though libraries can phase in an out of existence, but I guess only Amiga makes it possible *shrug*
edit: For the next version I'll check if I can link a static version of pixman to the executable to avoid confusion. It looks like shared libraries work in mysterious ways.
Edited by BSzili on 2021/11/16 15:33:59
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/15 14:26
#14
|
Quite a regular 
|
That's too bad indeed. If the library auto init stub is broken on your system, then it's not very likely a new version will fix anything, as it's not part of the Player but the library's SDK. We'll see.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/14 19:42
#15
|
Quite a regular 
|
Probably, but as the comment says it's quick & dirty code. It does the job well enough to have the Player run at full speed even in WinUAE. If someone makes a measurably faster version I'm happy to merge it, I just didn't see the point of spending more time on it.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/14 14:18
#16
|
Quite a regular 
|
I mean there's not a lot to it, for every pixel from the source surface you write two in the destination surface, and you write lines twice. This is how it looks in the EasyRPG Player: https://github.com/EasyRPG/Player/blob/master/src/sdl_ui.cpp#L396edit: Feel free to send me any programs.
Edited by BSzili on 2021/11/14 15:01:07
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/14 11:38
#17
|
Quite a regular 
|
Great to hear it works better now! In theory game data shouldn't affect library auto-open stubs, but if the scripts work that's fine. The SDL 1.2 version doesn't use SDL for scaling the graphics, it has a simple 2X scaler written by me, while the SDL2 version uses the SDL2 software renderer for scaling which will always be slower as it's generic.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/13 16:04
#18
|
Quite a regular 
|
Sorry I forgot to mention, I already updated the original archive with the SDL1.2 exe.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/12 7:23
#19
|
Quite a regular 
|
For once I took my own advice and rebuilt the Player with SDL1.2. This should offer much better speed than the SDL2 software renderer, and hopefully be compatible with a wider range of machines.
|
This is just like television, only you can see much further.
|
|
|
Re: EasyRPG Player
|
Posted on: 2021/11/11 19:53
#20
|
Quite a regular 
|
Unfortunately there's not much I can do about that, it's part of the library auo init code.
|
This is just like television, only you can see much further.
|
|
|