VisualBoyAdvance-M

You probably have something set up wrongly with your OpenGL library:

 

http://dri.freedesktop.org/wiki/libGL

I recently compiled it in GNU/Linux with latest SVN. Most of it looks good. But selecting Input Keys is hard, if possible. And the options aren't saved.

Well, it's still a WIP.

I'd actually love to play with this port for a bit (seeing as it's the only one I can even compile as I CBA to get any version of MSVC) but right now we'll just have to wait and see what's being done with it.

I know, I wasn't complaining [img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" /> More like, reporting.

Speaking of reporting, you guys might've already done something about this (last SVN I got was 595), but anyway I noticed this in the MainWnd.cpp:

 

// 1000 / 60 = 60 fps, but only results to 40 fps in reality.

// possible workaround: call timer more often and return or wait if too early

 

After tinkering with it for a bit, I found that the timer Qt provides has a granularity of 1ms, but only if you set it to a repeat of less than 10ms; above input of 10ms, it first skips to slightly over 15ms real time, and input of 16ms and above it waits 25 real milliseconds every time (hence the 40 FPS). Constantly changing the timer causes some delay as well; on my PC the Qt port runs at almost exactly 60 FPS when first setting the timer to wait 7, then 8 ms, before every repaint, even though that should be 1000/(7+8)=67 FPS.

 

Using a QBasicTimer object with a period of 1ms in the GraphicsOutput object (with timer.start(1, this); in the constructor) and the following timerEvent function:

 

void GraphicsOutput::timerEvent(QTimerEvent * event)
{
const int tickms[3] = {16,17,17};
static unsigned char curframeof3 = 0;
static int counter = 16;

counter--;

if (counter <= 0)
{
	counter = tickms[curframeof3];
	curframeof3++;
	if (curframeof3 > 2)
		curframeof3 = 0;
	repaint();
}
}

 

The FPS seem to converge to 60 or at least something very close to it (60.005 or 59.995 or something)

I think we'll use a seperate emulation thread, that gets a QTimer with an Overflow time of 0 (idle time processing or something like that). But for now, the Timer is in the Main Application thread until we get some basic IO.

Looking forward to it.

 

Wouldn't idle time processing cause 100% CPU load by the way?

Yes it would, but if you use techniques like Audio Sync or VSync, it won't. Well, this are just some ideas, it is possible to change in the actual code. I learn Qt by developing this, so of course I can't plan far ahead [img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" />

I don't really know anything about Qt myself. [img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" /> (well, besides what I learnt from the first few tutorials, some experiments and the manual)

Seems Qt at least has full threading support. If using that the Qt port ends up running as smoothly as the Win32 VBAM does right now that'd be great.

I would like to suggest that the gameboy player (gamecube) would be emulated and somehow merged within the emulator (QT Gui) to show different borders that you can choose when playing games without borders and have it function similarly to the gameboy player. When some key is pressed, an overlay will appear over the emulator and this is when you would choose which border to pick (while rom is active [similar overlay formula like zsnes's overlay when you switch to the emulator options while playing]).

 

Would function like: [video=youtube]

<div><iframe width="459" height="344" src="https://www.youtube.com/embed/Uy3SDPz3W ... ure=oembed" frameborder="0" allowfullscreen="true"></iframe></div> @6:17 

Will overlay similarly while functioning like: