VisualBoyAdvance-M

http://vba-m.com/vbam/vbaotherbuilds/vbam_qt_dlls.rar

Thanks Mudlord =)

 

Nice. Hmm it seems it can't save any options yet. But it looks good sofar.

Some planning/ideas by me:

 

• Do not use any internal filters anymore, instead extend the Kega Fusion plugin support (15, 16, 32 bit filters) and port one or the other filter to it.

 

• Completely support 7z files with multiple ROMs in them, save & load them to/from the recent files list in Form "...\ROMs\Advance Wars 2.7z\Advance Wars 2 [EUR].gba"

 

• Always use tr("") from the beginning to ease later translations.

 

• Use as much eye candy as possible. The MFC build only has ONE icon, now THAT's boring

 

• Use Phonon for Audio/Video Recording. (I'm not sure if Phonon is just a decoder or more).

 

• Maybe use phonon for sound output as well, so we don't need a platform specifiy audio plugin?

 

• Make sure from the beginning that as much usage of threads as possible is made. Maybe we have to rewrite the current interface to the core using callbacks for that. I think it would be good to create a new branch on the SVN (even though I don't exactly know how that works). if we have to make some changes to the core for making the Qt build work better, it would be awful if we had to change all the other GUIs all the time or they would be broken. All of the current source code for the different GUIs will be obsolete as soon as Qt takes over anyway, so maybe we should just archive the current state as a branch or something like that.

- Do not use any internal filters anymore, instead extend the Kega Fusion plugin support (15, 16, 32 bit filters) and port one or the other filter to it.

 

So your saying, port the Kega Fusion filter functionality to Linux? Well, KF plugins are just Win32 DLLs...so......

 

Always use tr("") from the beginning to ease later translations.

 

Thought I already did that with my options box [img]<fileStore.core_Emoticons>/emoticons/ohmy.png[/img]/emoticons/ohmy@2x.png 2x" width="20" height="20" />

 

- Use as much eye candy as possible. The MFC build only has ONE icon, now THAT's boring

 

Thats what I am doing: Oxygen icons to me look pretty sexy. And TCOS is planning (IIRC) a new VBA icon that we can use. We could use a icon artist....[img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" />

 

Use Phonon for Audio/Video Recording. (I'm not sure if Phonon is just a decoder or more).

 

Seems to be just a decoder framework. Not entirely sure though.

 

Make sure from the beginning that as much usage of threads as possible is made. Maybe we have to rewrite the current interface to the core using callbacks for that. I think it would be good to create a new branch on the SVN (even though I don't exactly know how that works). if we have to make some changes to the core for making the Qt build work better, it would be awful if we had to change all the other GUIs all the time or they would be broken. All of the current source code for the different GUIs will be obsolete as soon as Qt takes over anyway, so maybe we should just archive the current state as a branch or something like that.

 

Sounds like a perfect topic for IRC discussion.

About Phonon. I am not a developer, so anyone who knows more can correct me. But as far as I understand, Phonon is a generic API for multimedia which makes use of so called backends, like VLC (not with GUI and everything), Gstreamer, Xine, Mplayer, DirectShow, etc. If there's a new hyper 1337 replacement for these backends, just use that instead (If Phonon supports it), and no modification is necessary for the individual programs that use Phonon. So as far as I know, if you developed multimedia for either of these backends before, it's better to use Phonon instead, so the user can easily choose what backend to use.

 

How did recording work before? Did it use DirectShow? If so, I think Phonon is a good idea.

 

BTW (maybe offtopic): Will you still develop the SDL version? I would like to continue using your emulator on Haiku, but there is no Qt there. (Even though I prefer GUIs and love Qt and enjoy it on Unix-like systems) VBA-M SDL version is still much better than BoyCottAdvance SDL version.

The current AVIWrite class uses the Video for Windows (VfW) API, the thing back from the 16 bit Windows days ^^

 

EDIT:

OK, since the Kega Fusion system does not work directly for Windows, maybe we can port it? After all, Linux does support shared objects, so you would have to recompile the plugins for diferent systems.

 

Another possibility would be to use only OpenGL shaders for pixel filtering. I don't know much about that yet, but maybe it is possible to put them in OS-independant files and compile them at runtime before usage? Even though there might not be many of them around, I'm very sure many interested people will write them once the architecture for them stands.

 

 

Another vision:

• Do not internally work with VIDEO_1x/2x/3x/4x or whatever, just use either windowed or fullscreen mode, probably fullscreen being non-exclusive to make switching faster and to keep widgets.

Ok, I don't know much about Video for Windows, sorry.

 

If you improve the filter approach so it's more portable, why not? Just make sure it's not x86-specific either please. The shader approach sounds fine to me too.

 

Ohh yeah. Please don't use Esc for exiting fullscreen. I prefer the Esc key make the menu bar appear/disappear, and switching to fullscreen with Ctrl + F. If you make it configurable though, that's also fine.

OK, I just created a new branch of the /trunk directory in /branches/qt

 

http://vbam.svn.sourceforge.net/viewvc/vbam/branches/qt

 

When using TortoiseSVN, I had to run the SWITCH command from the right-click menu on my current /trunk dir and point to /branches/qt, so now my trunk is actually the branch.

 

 

In this branch, I will first remove everything not related to the Core or Qt, then I will do some restructuring. We can then finally go wild in there and do all the necessary changes to the core layout without having to worry about compatibility to CMake, GTK, SDL, MFC and whatever. Creative minds need some freedom, don't they?

Another possibility would be to use only OpenGL shaders for pixel filtering. I don't know much about that yet, but maybe it is possible to put them in OS-independant files and compile them at runtime before usage? Even though there might not be many of them around, I'm very sure many interested people will write them once the architecture for them stands.

 

In MuNES (my own NES emulator), I have a rock solid pixel shader implementation in OpenGL 2.0. It uses ZERO outside dependancies apart from opengl32.dll itself.

 

Krom, from GBAdev.org, made some very nice shaders we could use. Sure, they aren't quadratic resamplers and stuff like that, but they are quite cool.

 

I am interested in redoing the shader support in VBA-M, if people want it.

only if they are SM2 compatible.