Dev questions

colbsure · Post by **colbsure** » Thu Oct 16, 2008 11:59 am

Hi,

Â

I'm new here but have used VBA in numerous incarnations over the years.

Â

Programming is both my job and my hobby and I'm wanting to build up the sources of VBA-M to take a look to see if the core is really as unstructured as is often described!

Â

I'm curious about a few things:

is all of the front end work now focused on the QT version?

on a related note, is VBA-M currently cross-platform or is that the drive of the QT version?

Â

I ask because I'm a Win32 dev with lot's of MFC experience and, if the MFC GUI is deprecated then I won't bother looking at that.

Â

Cheers,

Col

mudlord · Post by **mudlord** » Thu Oct 16, 2008 12:17 pm

MFC is not exactly deprecated. You might want to talk to Spacy about this...

spacy51 · Post by **spacy51** » Thu Oct 16, 2008 2:03 pm

Hi there!

Â

Qt has been suspended (at last by me, and I don't know of other devs [img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" /> ).

Instead, I'll look into making the GTKmm build compile on Windows.

Â

However, since the MFC build is most comfortable and feature-rich as of now, it will probably be supported for a long time, until something else is better.

Â

It would be great if you could further improve the MFC build with your experience, as I am sure Forgotten did not have too much knowledge of good programming style when he started this emu.

Â

You can get the source via SVN: http://sourceforge.net/svn/?group_id=212795

Â

For your convenience, here is a zip file containing all the current code (SVN756): http://www.mediafire.com/?dtmijmttpsm

colbsure · Post by **colbsure** » Fri Oct 17, 2008 6:37 am

Thanks very much for the source: I've just grabbed it and added in latest versions of zlib and libpng, then grabbed SDKs for OpenAL and DirectX SDKs.

Â

Quickly got myself a debug version built, linked and working - I'll have a proper look when I get home later. Is there a wishlist for the UI?

Â

I guess I'd better start brushing up on ARM assembler if I'm going to be of any use... I did lots of 6510 at one point (C64 demoscene... showing my age).

Â

Col

spacy51 · Post by **spacy51** » Fri Oct 17, 2008 9:26 am

That's nice to read.

Â

I don't have many wishes for the MFC GUI part itself, I only think a code review might be a good idea.

Â

More issues:

add maximum "fast forward" speed setting

add support for compressed archives with multiple ROMs in them (currently the core takes care of opening & uncompressing ROMs, this should be ported to the GUI, so there can be an interactive selection of files inside of compressed archives. There also has to be a way to adress files inside of comrpessed archives for the recent files list)

strongly improve audio/video recording, add audio compression support

review architecture for the logging window/system (global variables)

verify selected BIOS files by checksum and warn the user if different

add more multi-threading

remove hack for 16 bit filters, maybe fully concentrate on supporting Kega Fusion filter plugins and port some filters to it.

further merge HQ3x/4x code into HQ/LQ2x code (it is possible)

add GBA cheat editing (I already added it for GB, but had some issues when trying it for GBA cheats.)

strongly improve cheat dialogs for easier user interaction, maybe an option for importing/detecting cheats form a text file

add stereo upmixing to OpenAL

improve Windows integration (better file associations, maybe even a shell extension for reading ROM headers)

add high-level graphic rendering support, enabling to apply pixel filters more effectively

improve pixel filter speed by only applying them to parts that have changed

64 bit CPU support for the core if it can increase the speed

EDIT:

re-enable the possibility to not stop VBA-M from running when the window is inactive

hard: let VBA-M continue running even if the menu is opened (MFC enters menu modal loop or how it is called) or the window is moved.

Â

That's about all I can think of currently :angel:

As you can see, VBA-M is working pretty good in the current state, but there is always room for improvement.

Just taking care of some of the points is enough. Maybe you already did some work in one of these areas on another project.

bgK · Post by **bgK** » Fri Oct 17, 2008 3:59 pm

Qt has been suspended (at last by me, and I don't know of other devs [img]<fileStore.core_Emoticons>/emoticons/tongue.png[/img]/emoticons/tongue@2x.png 2x" width="20" height="20" /> ).

Instead, I'll look into making the GTKmm build compile on Windows.

Â

Great, the GTK+ port could really use some more love !

I acually managed to build it on Windows once, but it crashed on startup. Probably because of some incompatibility between the GTK+ and libglade versions I used.

That's why I'm replacing glade with GtkBuilder (an modernizing the GUI in the process).

The next step to make the GTK+ port build on Windows would be modifying the build system to make the Xv (and maybe OpenGL) output modules optional.

mudlord · Post by **mudlord** » Fri Oct 17, 2008 6:14 pm

I guess I'd better start brushing up on ARM assembler if I'm going to be of any use... I did lots of 6510 at one point (C64 demoscene... showing my age).

Â

No problem with that [img]<fileStore.core_Emoticons>/emoticons/happy.png[/img]/emoticons/happy@2x.png 2x" width="20" height="20" />. Having experience is a excellent thing. Anyway, if all goes well, its nice to see the MFC port getting some major luvvin' (I unfortunately no longer have access to recent Visual Studio development tools)....

Squall Leonhart · Post by **Squall Leonhart** » Sat Oct 18, 2008 2:46 am

i want to get away from MFC, and get WTL or Win32 type interfaces, that'd remove the restriction of having to use MSVC

spacy51 · Post by **spacy51** » Sat Oct 18, 2008 5:58 am

i want to get away from MFC, and get WTL or Win32 type interfaces, that'd remove the restriction of having to use MSVC

Â

I think what comes first now is major refactoring for the cores and ONE front-end (probably MFC), which will make use of it. I will create a new banch for that purpose. When it's done, the developers for the other front-ends can adapt their front-ends for it. Doing it this way, we can be sure that at least trunk will always compile fine.

colbsure · Post by **colbsure** » Thu Oct 23, 2008 11:05 am

i want to get away from MFC, and get WTL or Win32 type interfaces, that'd remove the restriction of having to use MSVC

Â

If, by WTL, you are refering to the Windows Template Library then using this will not free you from MSVC as it builds on the microsoft ATL libraries.

Â

Cheers,

Col