VBA-M Forums

If you look at the files on sourceforge (http://sourceforge.net/projects/vbam/files/ ), the linux version is still from 2009-06-13, but the windows version is from 2010-07-10.

yeah?

and?

So any recent changes aren't on the linux version.

So? you expect majority windows developers to care about the minority lunix fans.

Hello!

Apparently the linux interface bug has not changed since the last time.
Is it possible to add at least RTC? I think it is the lack largest.

our only linux dev is busy with real life and zsnes.

Bonjour Squall Leonhart!

Do you know if he is nevertheless aware of the problem? Does he happen to read this topic?

Hi There i wanna know if possible obtain a "deb" file for "X64" machines

and too , yesterday i had installed Ubuntu 10.10 , i Had Nvidia ( GeForce
7025 / n630a ) , but with you emulator ( i386 ) , the OpenGL dont work , i hear the roms , but i cant see anything

But if i select "Cairo" , yes i can see "The Game" , but "Cairo" dont support Filters :=(

Someone can helpme with this ???

Well appart from that , why the "MFC" Version , have much more options ???

because no one give a toss about lunix.

...seriously though, this emulator is primarily developed on windows, for windows.

linux support has always been lacking.

Well that is some injust because VBA-M is the best fork / port / version , of VisualBoyAdvance.

Well , in that case , you dont know if exist some TOOL for Convert the Saved Batterys & Saved States , from VBA/M to Mednafen ???

I dont like use Wine to Runs Windows Applications , i just use WINE , just for Play FF7 under Ubuntu ^^.

As far as I know running the MFC version of VBA-M under Wine works really well.

Anyway, the thing you're having with OpenGL probably has to do with the fact that you're in a 64-bit Linux using the 32-bit binary, you'd need 32-bit libs for that to work.

You can always build the emulator yourself: http://vba-m.com/forum/how-build-vba-svn...t-527.html

Hello,

there has been a request to package VBA-M for our Ubuntu gaming platform PlayDeb.net:
https://bugs.launchpad.net/getdeb.net/+bug/622552

The package now has been packaged by me and is available in our repository:
http://www.playdeb.net/software/VisualBoyAdvance-M

You may want to add a download link to it.

this package is pretty old to be honest, I'll be posting a new binary soon, if you need a maintainer I may be willing to lend a hand.

We do not (or we don't like to) publish precompiled binaries on GetDeb/PlayDeb but we compile everything from source.
In Debian packaging we make use of the watch files to scan upstream for new versions. It would help us if you published source tarballs on sourceforge with a fix file syntax like: vbam-version.tar.gz or something like that. So we can configure the watch file to scan the version and compare it to the package version.
With this way we are notified about a new release and can create a new package for ourselves. You do not need to maintain anything this way.

//edit
I hope you make something useful with my donation

Or you can compile it all and just release the installers for everybody else to use. I've been making the installers as best I can, and so far I've been getting them to work. You will find links to the installers on the 64-bit question thread. I've only updated the x64 versions for Fedora 14 and Ubuntu 10.10. The x86 versions will have to wait.

As for a package maintainer, it might be possible to be able to download the installers and install VBA-M automatically through apt-get/yum, but that would require a file host and other things that are currently above me. Right now I'll just stick with making installers for the latest versions and posting them on my Mediafire account for everybody to use.

Installers are usually used by cloused source projects.
You can of course use them to reach many different distributions with one way but also there the installer has to consider distribution specific settings.
As for Debian or other packages there really is no need to bundle the installer in the package because the package and the packaging system already _is_ your installer.
So as I already mentioned publishing releases in a source tarball with a defined file name is enough to inform us about new releases and then just let the maintainers do their job.

well that could be a problem, most of the guys here mostly do windows release and post the binaries, since we technically don't have a stable available yet (even though it's pretty stable as is)

I'll see what I can do, I'll post maybe a weekly snapshot release either on the vba-m sf.net project page (if I still have upload privies on the project page or not) or on my personal blog which you can monitor (both binaries and source will be posted)

This would really be great.

Publishing on sf would be perfect because there are already scripts which scan
all project related files on sf and lists them. For vbam it would be here:
http://qa.debian.org/watch/sf.php/vbam/

You also don't necessarily have to publish tar.gz tarballs (although this is the most common format of sources). We also accept zip files to make it a bit more Windows user friendly But the format really shouldn't matter.
It is just important that you choose a filename format and stick to it so we can scan for the version number in those files. E.g. choose a filename like: vbam-version-source.zip. Or anything like that. Just make the version number easy distinctable from the prefix (project name, package name) and the suffix ("-source" and file extension).
In this case we would just parse the filenames with this regex:
vbam-([\d\.]+)-source\.zip

Hm, as you said you will publish SVN snapshots instead of real version numbers. (I just see that revision 877 is called version 1.8.0 so maybe you have both). In this case you probably have the revision the source "tarball" is based on in its file name.
So maybe the file name will be like this: vbam-svn970-source.zip
In this case we would just parse for: vbam-svn([\d]+)-source\.zip

These are just some hints for how to name the source archive so we can easily scan for new versions.

It would be great if you could implement this procedure in your team that just each team member (when publishing a new executable) now just also has to put the code of this revision the executable is based on in such a "tarball" or zip file or whatever, name the file properly and upload it on sourceforge.

If you think vbam has reached a stable revision we can also think about getting the project into the official Ubuntu and Debian repositories.
This way it will be of more use to more people than just the users who use our PlayDeb repository (which is a non official project).

//edit
If you publish the files on your blog it is also fine if the filename is directly readable from the link (and not the link text).
E.g. <a href="test">vbam-svn870-source.zip</a> <-- this _won't_ work because the link itself ("test") is parsed and not the text displayed in the browser.

That is a good idea. As for the Ubuntu and Debian repositories, as well as PlayDeb, it would still require a deb file to download and install. That's how they all work. When you download something to install, it downloads the deb files and runs the installers. Since I've been compiling Linux versions of the emulator, as well as taking the time to make the deb files, I can help with the maintaining of the repository on PlayDeb for the average user who doesn't want to compile the source themselves.

How I see it, it's a win-win.