You are not logged in.
Pages: 1
Hello, my aim is to improve the gtk frontend, to reach (or at least approach) feature parity with the windows one. I have submitted a first small patch (http://sourceforge.net/tracker/?func=de … tid=832293) with a few changes, I'd be happy if someone would like to take a look at it.
I have a bigger one almost ready implementing support for filters (and enabling cool stuff like HQ2X + Bilinear, for people who are after the best possible quality). To add support for filters, among the other things I had to copy video.h from the windows directory and edit it a bit, as I use VideoInfo in a different way (that is, I pass to the filter surfaces which have already been rotated/moved aside etc.). Is this ok or is it envisageable to have a single video.h working for all frontends (and thus out of specific directories)?
Offline
kbios, for your video filters code, could you take cocoa/videofilter.cpp and cocoa/videofilter.h for a spin? It's some code that I've wanted to make cross-platform someday, but I am not a Linux programmer, so I haven't had a chance to test it on that platform. I think you'll find that it's superior to windows/video.h in every possible way.
Last edited by rogerman (2013-01-10 19:38:18)
Offline
we do most of our discussion on irc. the linux port admin doesnt read this forum, so discussion would best be in the bugtracker thread. or on irc.
i think its fine to use your own video.h. that architecture is obviously not great. desmume is only built to have the raw nds output in the portable code. I doubt that will ever change, and filters are considered a frontend's responsibility. That's not ideal, but changing that code in the windows side is not really gonna happen any time soon.
Offline
@rogerman
Wow, if I had noticed that before I would have avoided lots of headaches! Porting my patch to the videofilter API was a breeze, however I needed to do the following small changes to make it compile under Linux:
1) Add
#include <stdint.h>
#include <string.h>
to videofilter.h
2) Comment out
int scanline_filter_a = 0;
int scanline_filter_b = 2;
int scanline_filter_c = 2;
int scanline_filter_d = 4;
(they don't seem to be used?)
from videofilter.cpp as they collide with another file.
Everything is working now, but there is a performance problem: fps dropped from about 60 to 46 in my reference test (Pokemon White 2 with HQ2XS).
The core code that does the filtering is
gpu_screen_to_rgbx((u8*)video.GetSrcBufferPtr(), imgW*imgH*4);
u32* fbuf = video.RunFilter();
guchar dsurf24[video.GetDestWidth()*video.GetDestHeight()*SCREEN_BYTES_PER_PIXEL];
gint k=0;
// Convert to 24-bit
for (gint i=0; i<video.GetDestWidth()*video.GetDestHeight(); i++)
{
*(u32*) &(dsurf24[k]) = fbuf[i];
k+=3;
}
drawPixbuf = gdk_pixbuf_new_from_data(dsurf24, GDK_COLORSPACE_RGB,
FALSE, 8, video.GetDestWidth(), video.GetDestHeight(), video.GetDestWidth()*SCREEN_BYTES_PER_PIXEL, NULL, NULL);
Do you think I'm using the API in a silly way?
@zeromus
Thanks! I will post to IRC as soon as this is sorted out. BTW, could you tell me the IRC name of the Linux port admin, please?
Last edited by kbios (2013-01-10 23:35:34)
Offline
uhh its xmrx but i realize i mostly just lied, he doesnt show up on irc anymore. irc is where almost everyone else talks. we have some other linux devs on there too though, probably enough to warrant a quorum
Offline
Hey, kbios! Thanks for trying it out! I've got a few things to mention about your results:
1) I'll be sure to add that soon, thanks!
2) Those int values are absolutely necessary, as they are extern variables from scanline.cpp used to control the scanline filter. I put these variables here because I couldn't think of a better place to put them. Now that I think about it, this could be implemented better. I'll have to think some more about the proper placement and changing of these variables.
The performance numbers are very interesting... I would've never expected that much of a difference. However, there are some multithreaded hoops that the code jumps through that the Windows code doesn't. Whenever you retrieve a state using functions like GetDstWidth() and GetDstHeight(), they go through mutex locks.
One other thing... GetDestWidth() and GetDestHeight() are the names of old functions. The new names are GetDstWidth() and GetDstHeight() respectively. There were recent changes to the code that greatly improve the performance in single-threaded mode.
Try updating to the latest code, and also retrieve state as little as possible. That should improve your performance.
Offline
rearchitect whatever you want in this area, to work for the both of you, as long as the same features remain, and ill clean up what needs to be cleaned in the windows port. dont worry about stepping on my toes, im outnumbered.
Offline
Hey, kbios! Thanks for trying it out! I've got a few things to mention about your results:
1) I'll be sure to add that soon, thanks!
2) Those int values are absolutely necessary, as they are extern variables from scanline.cpp used to control the scanline filter. I put these variables here because I couldn't think of a better place to put them. Now that I think about it, this could be implemented better. I'll have to think some more about the proper placement and changing of these variables.
The performance numbers are very interesting... I would've never expected that much of a difference. However, there are some multithreaded hoops that the code jumps through that the Windows code doesn't. Whenever you retrieve a state using functions like GetDstWidth() and GetDstHeight(), they go through mutex locks.
One other thing... GetDestWidth() and GetDestHeight() are the names of old functions. The new names are GetDstWidth() and GetDstHeight() respectively. There were recent changes to the code that greatly improve the performance in single-threaded mode.
Try updating to the latest code, and also retrieve state as little as possible. That should improve your performance.
Hey!
I've updated to latest svn and I seen you already added the includes, great!
Note: the current svn is broken for linux, because utils/AsmJit/Config.h and utils/AsmJit/AsmJit.h are named uppercase and included lowercase. Renaming them to config.h and asmjit.h fixes the problem.
Regarding performance: there is a day and night difference, up to 58 fps with one thread and up to 62 with four. Wow! I also minimized the calls to GetDstWidth() and GetDstHeight().
For the int values, the problem is that they are defined also in src/commanline.cpp, maybe they could be moved in a common place?
Offline
Alright, kbios. Try out r4487, which adds new methods for getting and setting filter parameters. You should delete the scanline filter's global variables from commandline.cpp and use the new methods instead.
Here's some example code to set the scanline parameters using the new methods.
{
VideoFilter *vf = new VideoFilter(srcHeight, srcWidth, VideoFilterTypeID_Scanline, 0);
vf->SetFilterParameteri(VF_PARAM_SCANLINE_A, 0);
vf->SetFilterParameteri(VF_PARAM_SCANLINE_B, 2);
vf->SetFilterParameteri(VF_PARAM_SCANLINE_C, 2);
vf->SetFilterParameteri(VF_PARAM_SCANLINE_D, 4);
memcpy(vf->GetSrcBufferPtr(), srcBuffer, sizeof(srcBuffer));
vf->RunFilter();
}
Offline
Alright, kbios. Try out r4487, which adds new methods for getting and setting filter parameters. You should delete the scanline filter's global variables from commandline.cpp and use the new methods instead.
Here's some example code to set the scanline parameters using the new methods.
{
VideoFilter *vf = new VideoFilter(srcHeight, srcWidth, VideoFilterTypeID_Scanline, 0);
vf->SetFilterParameteri(VF_PARAM_SCANLINE_A, 0);
vf->SetFilterParameteri(VF_PARAM_SCANLINE_B, 2);
vf->SetFilterParameteri(VF_PARAM_SCANLINE_C, 2);
vf->SetFilterParameteri(VF_PARAM_SCANLINE_D, 4);memcpy(vf->GetSrcBufferPtr(), srcBuffer, sizeof(srcBuffer));
vf->RunFilter();
}
Awesome. I've finalized my patch against the latest code and posted it (https://sourceforge.net/tracker/?func=d … tid=832293). Sorry for the delay!
Offline
Pages: 1