Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
47 user(s) are online (32 user(s) are browsing Forums)

Members: 0
Guests: 47

more...

Headlines

Forum Index


Board index » All Posts (BSzili)




Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
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.

Go to top


Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
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.

Go to top


Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
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.

Go to top


Re: Why call to or any "empty" functions can cause different results of the code in which you insert it?
Quite a regular
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.c
In this case it would be good to know at which point CompileShaderProgram returns FALSE.

Go to top


Re: Why "prinfs" or any functiosn can cause different results of the code blocks ?
Quite a regular
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".

Go to top


Re: Is anyone have readdir_r() implementation for aos4 ?
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: Is anyone have readdir_r() implementation for aos4 ?
Quite a regular
Quite a regular


You can just do this:
int readdir_r(DIR *dirpstruct dirent *entrystruct dirent **result)
{
  *
result readdir (dirp);
  return *
result != NULL : -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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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#L396

edit: 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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top


Re: EasyRPG Player
Quite a regular
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.
Go to top



TopTop
(1) 2 3 4 ... 35 »




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project