VisualBoyAdvance-M

Yes I know it's bad. But it's currently done to make it easy to launch gvbam from the source folder. I'll change that when the port is more mature.

To install in /usr, you have to launch cmake with :

cmake -DCMAKE_INSTALL_PREFIX :P ATH=/usr -DDATA_INSTALL_DIR :P ATH=share/gvbam .

And to install in a chroot you have to launch :

make DESTDIR=/location/of/chroot install

 

I'm currently working on the graphic output system. I've made it possible to add other output modules in addition to the plain GTK one, and I've written an Xvideo output module. It gives a nice speed boost when compared to Gtk, thanks to the hardware scaling and filtering support. It also features freely modifiable window size.

The Xv output module can be enabled by setting use_Xv=1 in the config file (~/gvbam/config). I'm sorry, there is no menu for the moment. Can you please test it and tell me if it works on your system ?

If that question was meant for me, then yes - Xvideo output seems to work.

Will you add soundShutdown() to Window destructor, cause it should be there anyway ?

I think that right after vOnFileClose(); is the correct place.

If that question was meant for me, then yes - Xvideo output seems to work.

Will you add soundShutdown() to Window destructor, cause it should be there anyway ?

I think that right after vOnFileClose(); is the correct place.

 

Thanks, that's commited.

Anybody interested in my copy/paste from src/win32/OpenAL.cpp to a file that I successfully use instead of sndPortAudio.cpp ?

 

I'll attach it here. There are a few changes.

oalBufferCount is constant for now as I would have to at least add a new config key to make this configurable

three commented ASSERT_SUCCESS macros are due to the issue I mentioned before (call to alGetError invalid, when current context == NULL)

added for g_new0 and g_free

changed ASSERT_SUCCESS macro to print error number instead of simply assert

 

BTW, why does the board reject this file while it's not packed ?

<

Because the board only accepts certain file types.

 

 

It's nice to hear that my code is useful even for non-Windoze.

 

The ASSERT_SUCCESS macro and LOGALL are not really necessary anymore. They were however, when I was developing this code because the OpenAL documentation was very poor and I had to find out the voice's state under certain circumstances.

mnk > thanks for your OpenAL code. However, it can't be integrated into the port yet, because the sound output code it not yet modularized.

 

I've added a very simple OpenGL video module and enabled it by default. The speed is great when compared to the GTK video output. It's even faster than Xv on my computer. Please tell me if you find bugs.

i can allow such files to be uploaded to the board but i won't because i prefer they are zipped (or any other archive format) with a valid CRC generated to prevent both virus's and corrupt files.

Well, I don't see any outstanding bugs, but it probably should clear screen on init, so it's simply black, instead of black with random color pixels.

 

On an unrelated note: does adding -Wall to CFLAGS mean you're planning to silence at least some of the warnings, that are produced during the build ?

 

In the gtk part it's only two on_configure_event, that return neither true nor false (in screenarea-xvideo.cpp and screenarea-opengl.cpp : control reaches end of non-void function) and something that probably only gcc 4.3.0 bitches about:

src/gtk/screenarea-opengl.h: In constructor ‘VBA::ScreenAreaGl::ScreenAreaGl(int, int, int)’:

src/gtk/screenarea-opengl.h:50: warning: ‘VBA::ScreenAreaGl::m_puiDelta’ will be initialized after

src/gtk/screenarea-opengl.h:47: warning: ‘int VBA::ScreenAreaGl::m_iScaledWidth’

src/gtk/screenarea-opengl.cpp:29: warning: when initialized here

(that's a trivial one, simply swap order to match the one in header, similarly for src/gtk/screenarea.cpp)

 

But the vbacore part has a lot of warnings, mainly suggest parentheses around and

unused variable, one significant exception is:

src/bilinear.cpp: In function ‘void Bilinear32(unsigned char, unsigned int, unsigned char, unsigned char*, unsigned int, int, int)’:

src/bilinear.cpp:266: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false

src/bilinear.cpp: In function ‘void BilinearPlus32(unsigned char, unsigned int, unsigned char, unsigned char*, unsigned int, int, int)’:

src/bilinear.cpp:351: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false

Yeah, I've seen those colored pixels too. It's probably some uninitialized memory ...

 

And, yes, I'm planning to fix the GTK related warnings, since they sometimes hide bugs. Thanks for the hints. Fixing the warnings in the core is clearly out of my scope, as I mostly don't understand what happens there.

Yay ! I got SVN rev 500 :banana:

 

More seriously, I added fullscreen support to the GTK port today. It was one of the biggest lacking features.

It's now time for a bit of bug hunting. A package for Ubuntu Hardy ca be found here : http://bgkweb.googlepages.com/vbam_0.svn500-1_i386.deb

A screenshot for those who didn't get a chance to see the GUI yet is attached to this post.

 

Please report bugs here.