Page 1 of 3

Dev questions

Posted: Thu Oct 16, 2008 11:59 am
by colbsure

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


Dev questions

Posted: Thu Oct 16, 2008 12:17 pm
by mudlord

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


Dev questions

Posted: Thu Oct 16, 2008 2:03 pm
by spacy51

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


Dev questions

Posted: Fri Oct 17, 2008 6:37 am
by colbsure

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


Dev questions

Posted: Fri Oct 17, 2008 9:26 am
by spacy51

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.


Dev questions

Posted: Fri Oct 17, 2008 3:59 pm
by bgK

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.


Dev questions

Posted: Fri Oct 17, 2008 6:14 pm
by mudlord

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)....


Dev questions

Posted: Sat Oct 18, 2008 2:46 am
by Squall Leonhart

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


Dev questions

Posted: Sat Oct 18, 2008 5:58 am
by spacy51

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.


Dev questions

Posted: Thu Oct 23, 2008 11:05 am
by colbsure

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