Finally! building a front end from scratch

[MaMeNnO]

Hi,

As I have "Finally! building a cabinet from scratch", I also wanted to build a front end (FE) from scratch. Why you may ask. Well, because it's fun too! And I could control everything I wanted.

I'll agree immediately that there are plenty FE's out there that are very feature rich, but I also could have just bought a complete cabinet or a complete package with cutted sides, front etc.

In what language then? In the past I've programmed in BBC Basic, Turbo Pascal, Delphi, C++. I could get my hands on Visual Basic 6.0, so I began with that. I know how to program, but in Visual Basic in haven't done anything before. It was quiet a challenge.

Where to begin? I looked at some screenschots from other FE's. Studied the features and decided what I first wanna to do...

1. It should have a list somehow to select a game.
2. An in game picture has to be shown for the highlighted game.
3. I wanted to have some game information (year, manufacturer, etc.) shown on screen.
4. Many things should be configured through a .ini file.
Plus what ever I could think that should be in my FE.

Keyboard input (added 1-APR-2007)
The first thing I was concerned about was how should I read the keyboard? In VB6.0 it's completely different then in a procedural language. I knew about "ReadKey" in Turbo Pascal and "Inkey" in BBC basic, but VB handles events. Every control on a form can generate events. When a control has the focus it can react on key presses. I read about "key hooks", but that sounded to complicated for me now. Then I searched with Google and I found the answer for my problems in the form property "key preview". When that is set to "true", then when a key is pressed it is first send to the keydown/up event of the form. This also solved future focus problems with controls.

Graphics on screen (added 1-APR-2007)
How can I put some decent graphics on the screen? DirectX? To complex to start with. I use only one black, full screen form. I place controls on that form and change visibility, positions, colour etc. at runtime. Works great. For the graphics I'd caputured the whole screen when the game list and everything was on it. Then I loaded this in Adobe Illustrator. I placed the graphic elements I wanted on the position I wanted. After that I did some after effects to make it look more
attractive. In the FE it self I used a image control that I blow up to full screen and then the background picture is loaded
in this image. And voila! there is your nice looking screen with what ever graphics you want on them.

Screenshot from Yaff. Just selected Jurassic Park, because of the colour combination.


   Example picture (added 2-APR-2007)
This was something that had to be included. There was/is one difficulty. Standard VB6.0 does not support the .png format, only .jpg. I don't have a solution to that right now, but maybe someone has done this and want to share this with me. For now, I just converted al files to .jpg. With Adobe Photoshop this was easy done.
I use the "script processor" to convert everything to 640x512 (no, 1942 is not strechted!). As I use a resolution of 1280x1024 in my cabinet, this is a nice format.
Yaff now only supports one picture. As you walk through the list of games Yaff looks for a picture with the <romname>.jpg if it exists, it is displayed otherwise a "now picture available" picture is displayed. This picture can be named (through .ini file) and adjusted as you please.

Control settings (added 1-APR-2007)
Al the controls (elements on the form) are set to transparent (property "BackStyle = Transparent"). That makes life easier, because when controls overlapping you don't notice this. The font for the text is set to "Snap ITC". The coordinates don't matter, because they are changed at runtime.

Game selection list (added 1-APR-2007)
I was experimenting with a "poplist", but I had trouble with the key presses. When an "B" is pressed the list jumps to the entry that begins with that letter. Such a list is not flexible. Finally I used "labels" in a "control array" to implement the list. I use 13 labels, because then I'll can divide it equally above and under the selection bar.
The selection bar I wanted to be stuck in the middle, until in reaches the end of the list. Then the bar walks down and when it reaches the end it wraps around to the first game. Then it goes down again. When it reaches the middle it stays there and the whole list scrolls through. I noticed later that in other FE's the list it self goes down, not the bar. Well, I didn't mind and kept it that way. It worked and it works great!

Menu (added 1-APR-2007)
I wanted to have a menu in it. Here you could choose a favourite list or strip the brackets from the game name etc. For this I used two rounded filled rectangles. For the options I made two control arrays, one for the option names and one for the option choices. The coordinates of the controls are used to place the selectionbar. When I advance through the menu I also advance a counter (0..#option names) the counter stands for the position of the option name in the control array. The same method is used for the option choices.
The menu is completely build at design time. At runtime the menu can be switched on (make all controls visible) or switched of (make all controls invisible). I wondered if I should save the background just before the menu is placed over other things, but that's not necessary, because all graphics are persistant.



mame.xml, controls.dat and catver.ini (added 2-APR-2007)
To show info from the mame.xml, controls.dat and catver.ini files I needed to read those files and combine them. In every file is some info I wanted. The year, manufacturer and full description of the game is held in mame.xml. controls.dat has some additional info about the game (MiscDetails) and in catver.ini I wanted to use the catagory info.

   mame.xml
The biggest problem was the mame.xml file. It's large and it's XML. For some reason I could not find the XML library and use it in my program. Since I was building everything myself, I thought then I'll also write a XML parser. A dedicated one. I wasn't concerned about syntax, because the file is generated from MAME itself. When writing this I thought it would take quiet some time to read and parse everything. So, I just wrote a piece of code to just read the whole file. That took only a few seconds, great!

My first try was just to read every line character by character, build up a tag when a "<" was found and stop when a ">" was found. Just plain simple. This whole proces took around one minute, yep to slow. I added some code to see if a line was interesting or not. If not, read the next line and othewise parse it. The time needed now was around 5-6 seconds! (PIV dual core 3.0Ghz, not in my cabinet ) That's more acceptable.
I adjusted the code to use the "instr" function, rather then read character by character. My guess was that I could speed things up more, but the result is not that drastic as I thought. I haven't really compared the figures though.
I wonder what time it would take when you use the built-ins from VB XML library.

   Controls.dat
Ok, that was my biggest concern. Next was controls.dat and catver.ini. These files are straight forward and no real parseing is needed. Just read a line cut out the property and value and store it in an array. When a line with the game name is read, then advance the counter of the array slot to the next.

   catver.ini
The catver.ini file was theated the same as the controls.dat. Also, no problem with this one.

   Merging
Now al files could be handled, I needed to merge/join these files. I asked a question about this earlier, actually if there was such a combined file, but Howard_casto found it a "dumb idea", because joining is done on the fly. Well, that sounded not to bad. I wrote a little code to join al arrays into one. I wrote two lookup functions for every array. As the rom name is in all arrays, I used that as the key and then give back the position so I could get the info and store it in the final one. No hassle with this, quiet simple.

.ini file (added 2-APR-2007)

A .ini file was also a thing that had to be included. Whithout this, it would be impossible to configure anything. As the project progressed I added parameters. For this I wrote a piece of code to just read the yaff.ini file until a particular parameter is found. The parameter goes befor the "=" sign. Everything after it is the value. This is assigned to a variable in the program. It is "just" assigned, meaning that I don't really make a difference between strings or numbers, so there is a bit of implicit conversion going on. When a parameter can't be found, a warning is writen to the yaff.log file.

yaff.log (added 2-APR-2007)
To be able and track some underneath behaviour and/or errors I made a little procedure to write to the yaff.log. It are just three lines of code. Open the file for append, write a line and close it again. A line is in the form of:

<date> <time> : <message>

2-4-2007 20:32:44 : Yaff version (0.1b) is started.
2-4-2007 20:32:44 : Begin reading D:\Arcade\Yaff\yaff.ini file.
2-4-2007 20:32:44 : Reading D:\Arcade\Yaff\yaff.ini file finished.
2-4-2007 20:32:44 : Begin reading roms from D:\Arcade\Mame0107b\Roms\.
2-4-2007 20:32:44 : ...225 roms read.
2-4-2007 20:32:44 : Reading roms finished.
2-4-2007 20:32:44 : Begin reading D:\Arcade\Yaff\catver.ini file.
2-4-2007 20:32:44 : ...5772 lines read.
2-4-2007 20:32:44 : Reading D:\Arcade\Yaff\catver.ini file finished.
2-4-2007 20:32:44 : Begin reading and parsing mame.xml file.
2-4-2007 20:32:49 : ...453605 lines read and 37115 lines parsed.
2-4-2007 20:32:49 : Reading and parsing finished.
2-4-2007 20:32:49 : Begin reading D:\Arcade\Yaff\controls.ini file.
2-4-2007 20:32:49 : ...18229 lines read.
2-4-2007 20:32:49 : Reading D:\Arcade\Yaff\controls.ini file finished.
2-4-2007 20:32:49 : Begin joining mame.xml, catver.ini and controls.dat.
2-4-2007 20:32:50 : Joning finished.
2-4-2007 20:32:53 : Yaff has been Shutdown.

This file includes what is going on at a particular moment, like what file is read, how many lines are read and parsed, etc. Maybe I'll include a loglevel that indicates how detailed things are logged.

Shutting down (added 6-APR-2007)
I want my computer to shutdown after I have closed down my front end. I first thought that I had to use an external program or some special system call to do this. I found out that I could just use "shutdown" from windows. So, all I do when the front end stops is:

Shell "shutdown -s -f -t 00", vbHide

The behaviour can be controlled with a .ini parameter I called "shutdown_computer_when_yaff_closes" when this is set to "Yes", the computer will completely shutdown, otherwise you will be thrown back to Windows desktop.

[SGT]

How can I put some decent graphics on the screen? DirectX? To complex to start with. I use only one black, full screen
form.

Are you not having problems with form flicker when changing things on the control or form?

[youki]

Good luck! 

Therefore, as you know Delphi , i would choose Delphi instead of VB6....

[Buddabing]

If you really want to use VB6, consult with Howard. His front end uses VB and he probably has some code you can use.

[MaMeNnO]

How can I put some decent graphics on the screen? DirectX? To complex to start with. I use only one black, full screen
form.

Are you not having problems with form flicker when changing things on the control or form?

No, not at all. Never experienced that. The only thing is, when you get back to the FE after playing a game the whole screen blinks one time.

Good luck! 

Therefore, as you know Delphi , i would choose Delphi instead of VB6....

Well, it's more I knew It's been along time and VB6.0 was the first thing I could my hands on.

If you really want to use VB6, consult with Howard. His front end uses VB and he probably has some code you can use.

Thanks for the tip!

BTW, I'll keep updating the first post.

[MaMeNnO]

Added a few pictures and some text.

[MaMeNnO]

Added the "Shutting down" part.

[liquid8]

Good luck It's a lot of work. I also would have started with a language you already know, but VB can make the development cycle quicker, and if you are doing a sort of "how-to" that might be the language to use.

A couple things I'd look into:

Are you not having problems with form flicker when changing things on the control or form?

You most likely will run into this when you get further into graphics development. VB is not really graphical friendly. For VB6, enable double buffering for the form:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformscontrolclasssetstyletopic.asp

or

http://www.bobpowell.net/doublebuffer.htm

This can have a negative effect on cpu usage, but for smooth scrolling is probably necessary...



I would look into gdi+ - not sure if there's a reference for it for VB6, but .NET and C can both use it. It gives you MUCH better control of graphics (and you can do more cool things)

[Howard_Casto]

There are ways to use gdi+ in mame, but it requires so many api calls one might as well just use opengl or directx, which gives you even greater flexibility.

[SavannahLion]

I don't know if VB6 would have been my first choice to develop a FE in either. For RAD designs, it's usually the first language I turn to however, mostly because I still remember quite a bit of it.

In the long run though, it's not a very satisfactory language. You'll find as your programming prowess increases (is that possible with VB?) you'll start hitting the upper limits of what the language is capable of doing. For some reason, moving to a different language is an almost impossible feat for a lot of people.

For me it took a lot, to finally drop VB and force myself to a new language.

VB isn't bad, but it leads into a dangerous trap where people simply don't use a different language.

[headkaze]

As far as RAD goes you can't beat C# (or VB.NET if your so inclined). I used to code in VB6 and you just don't get the productivity you do in C#/VB.NET. GDI+ is available in the System.Graphics namespace and can do everything you need to make a good looking FE. Mala for example uses GDI+. It can be a bit slow dealing with alpha channel images, but it has full support for them (including lovely PNG's). There is also the option of using MDX 1 or XNA which will give you a nice boost in speed for graphics rendering. GameEx uses MDX/Direct Draw so you can see it doesn't really have trouble with rendering at decent FPS even with FMV in the background.

The worst approach to writing a FE these days would be to use VB6 and Windows forms to draw the graphics IMHO.

[Howard_Casto]

I won't reccomend gdi+ in ANY .net language, at all, period.  Quite frankly, as you pointed out, it's very slow when dealing with alpha channels, and at this stage in the game, making a fe without alpha support makes it obsolete before the first release.  Regardless of the language, direct x or open gl is the way to go for the graphics engine.

[headkaze]

I won't reccomend gdi+ in ANY .net language, at all, period.  Quite frankly, as you pointed out, it's very slow when dealing with alpha channels, and at this stage in the game, making a fe without alpha support makes it obsolete before the first release.  Regardless of the language, direct x or open gl is the way to go for the graphics engine.

I think Mala does a pretty good job of being a FE and it just doesn't support alpha channel images, but it could if it wanted to. I think Swindus decided not to support them for the fact it does start to chug with too many of them. But it also depends on the quality of rendering you use, there are many options you can tweek to speed up GDI+.

There is no major speed hit from using .NET compared to Delphi (the language Swindus uses I believe) or any other language for that matter. People have a common misconception that .NET is slow, but I really don't notice a huge speed hit, and the rapid development makes it worth using anyway. MDX for example only has about a 5% speed hit compared to natively compiled code as it is highly optimized. It could be less than that I forget the exact figure Tom Miller quoted on Channel 9.

You can get away with not using alpha channels, but your right DirectX or OpenGL is the preferred way, it's just alot harder to write an application using those API's. If you don't go the obsolete DirectDraw way, you have to learn Direct3D and that is no easy chore. Even 2D in Direct3D is not that easy. XNA tries to make that easier, but there is still a steep learning curve.

[SavannahLion]

There is no major speed hit from using .NET compared to Delphi (the language Swindus uses I believe) or any other language for that matter. People have a common misconception that .NET is slow, but I really don't notice a huge speed hit, and the rapid development makes it worth using anyway.

That's because when .NET hit the developers market it was mind boggingly slow. .NET is a victim of the "let the hardware catch up" mentality. Don't tell me you don't remember the early press releases where Microsoft stated they weren't going to optimize many of the .NET routines.

My last version update was to 6.0. I believe I have a copy of C# sitting around somewhere, but I haven't actually gotten around to getting a copy of the .NET suite yet. Lats time I looked, there was no cross compiling tools available for Linux. Since Linux and Windows are fighting for dominance in this household, it's more important to me to be able to write software for either platform.

I'm sure the .NET situation changed since last I looked, I just don't have any incentive at the moment to find out.

[MaMeNnO]

I've been terribly lazy with my front end... I really should get going on with it.

Good luck It's a lot of work. I also would have started with a language you already know, but VB can make the development cycle quicker, and if you are doing a sort of "how-to" that might be the language to use.

A couple things I'd look into:

Are you not having problems with form flicker when changing things on the control or form?

You most likely will run into this when you get further into graphics development. VB is not really graphical friendly. For VB6, enable double buffering for the form:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformscontrolclasssetstyletopic.asp

or

http://www.bobpowell.net/doublebuffer.htm

This can have a negative effect on cpu usage, but for smooth scrolling is probably necessary...



I would look into gdi+ - not sure if there's a reference for it for VB6, but .NET and C can both use it. It gives you MUCH better control of graphics (and you can do more cool things)

I don't want to include to fancy looking things. Just a preview of the ingame image and a custom background is enough. What I do notice is that when I go through the list for the first time it's really slow (pictures can't catch up fast enough). The second time it can. Seems like pictures get cached or something.

Is there a way to cache the pictures when I start the front-end?

[unclet]

I think you can load all the pictures in an imageList control in VB and then access the images via this list (ie: array) for display purposes.   I think the ImageList control is part of the "Microsoft Windows Common Controls (SP3)" component ..... I think

Although, I am not sure how fast loading all screenshots for each emulator would take at start up time.   There are a lot of screenshots for Mame and tons of screenshots for GBA .... not to mention all the other 40 emulators out there.

[(+_+)]

I don't know if VB6 would have been my first choice to develop a FE in either. For RAD designs, it's usually the first language I turn to however, mostly because I still remember quite a bit of it.

In the long run though, it's not a very satisfactory language. You'll find as your programming prowess increases (is that possible with VB?) you'll start hitting the upper limits of what the language is capable of doing. For some reason, moving to a different language is an almost impossible feat for a lot of people.

For me it took a lot, to finally drop VB and force myself to a new language.

VB isn't bad, but it leads into a dangerous trap where people simply don't use a different language.

I'd have to disagree with you there. I've been programming now for 12 years and unless there is a real reason to code in a specific language, such as for real time systems for example, there is no need to adopt any one language over another. It really boils down to how well you or your team knows a specific language since it puts you on a much faster track to getting the program written. I've written my front end in VB and have been able to accomplish everything I set up to do and more. VB is notorious for giving programmers a bad wrap due to it's deceiving simplicity and the fact that it is/was a good starting place for beginner developers. Because of this every TD&H claims to be an experienced programmer. The result being, the market becomes flooded, lots of crappy code is written, VB salaries are reduced and thus making VB seem weak. Some languages are better suited for certain tasks but it doesn't mean that it cannot be accomplished in a different language. We used to use Powerbuilder for some of our products. It makes database programming much easier because of its data window features. But you can still write industrial database applications in Java, C, C++, C#, Delphi and VB.

MaMeNnO, unless you are interested  in learning a newer language and are willing to go through the learning curve, I'd stick with whatever language you are most comfortable with.

[(+_+)]

I've been terribly lazy with my front end... I really should get going on with it.

Good luck It's a lot of work. I also would have started with a language you already know, but VB can make the development cycle quicker, and if you are doing a sort of "how-to" that might be the language to use.

A couple things I'd look into:

Are you not having problems with form flicker when changing things on the control or form?

You most likely will run into this when you get further into graphics development. VB is not really graphical friendly. For VB6, enable double buffering for the form:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformscontrolclasssetstyletopic.asp

or

http://www.bobpowell.net/doublebuffer.htm

This can have a negative effect on cpu usage, but for smooth scrolling is probably necessary...



I would look into gdi+ - not sure if there's a reference for it for VB6, but .NET and C can both use it. It gives you MUCH better control of graphics (and you can do more cool things)

I don't want to include to fancy looking things. Just a preview of the ingame image and a custom background is enough. What I do notice is that when I go through the list for the first time it's really slow (pictures can't catch up fast enough). The second time it can. Seems like pictures get cached or something.

Is there a way to cache the pictures when I start the front-end?

I ran into this exact same problem. While scrolling through your game list, only show the game screenshot during your mouse up/key up event. I had to do the same thing for the .wav file that I play since it wouldn't playing quickly enough even though I'm reading it from a resource file. BTW, I put all images and sounds in my resource file except for the dynamic ones.

[(+_+)]

I think you can load all the pictures in an imageList control in VB and then access the images via this list (ie: array) for display purposes.   I think the ImageList control is part of the "Microsoft Windows Common Controls (SP3)" component ..... I think

Although, I am not sure how fast loading all screenshots for each emulator would take at start up time.   There are a lot of screenshots for Mame and tons of screenshots for GBA .... not to mention all the other 40 emulators out there.

Very true. Just load the image file on your keyup event. If it was data from ini files or registry data, then I'd load it up into a data structure of some sort just once up front. For countless images, I'd defer to reading on an as needed basis.

[gonzo90017]

Hey (+_+) Any plans on releasing your frontend?

[SavannahLion]

IRT: (+_+)

You are correct, but the full story isn't being told here. The very first language I learned is Atari Basic when I was eight, so when I entered the adult academic world, it was a natural choice for me to continue with the Basic family. For a very long time VB filled almost every need I had. I eventually reached a point where I found myself utilizing Windows API outside of VB to get around annoying VB bugs, writing wrappers to interface with 3rd party API's, and doing all sorts of other convoluted code in order to do the things I wanted it to do. (Unfortunately, despite my best efforts, VB and databases never worked well together for me.) In the end, I was trying to use just a hammer to build houses when I should've utilized a wider gamut of tools.  I finally realized enough was enough when I found myself writing viciously complicated memory management wrappers just to utilize one single API function I needed for my application.

Basic is relatively EASY as a language. Nothing brings a smile to a budding programmer better than to be able to literally "paint" a complicated GUI application in just a few minutes. I think VB should be in everyones language tool box, but I don't pretend to believe that VB should always be the tool of choice to turn to for every application need. And I don't kid people when I say that VB (or any language) shouldn't be the only tool learn. There is no perfect tool for every application.

After discarding my Basic portfolio, I decided to touch upon as many languages as I can including Java, C*, and Perl. I'm not shy to admit that my depth of knowledge is nowhere as deep as it was with VB. I spent the better part of ten years screwing around with the Basic language. Now I am happier that I can fire up notepad and pound out a small CL script with Perl to remotely manage files on a server, or not have to depend on anyone to audit the godawful PHP (which suffers from newbie hell worse than VB ever did) scripts before installing them, or port functionality I really want in either Windows or Linux to the other OS.

The gist of my argument here is to use the right tool for the job. You can get VB to do anything you want. But is it better to spend a week writing and debugging something when the same job can be accomplished in a much less time with another language? How about when you can use one language to accomplish one task and use VB to accomplish another?

In order not to steal this thread and to stay on topic. Try Xtreme Visual Basic and asking there. It's been years since I've last frequented that place so I don't know what kind of people visit there now. If they're anything like when I visited, you should be able to find at least several answers to your problem. If it were up to me, I would eschew using intrinsic VB controls for managing the image and look into bitblt as a basic starting point. Your options will quickly ramp up from there. That's just me though.

Edit: fixed typo

[unclet]

If you want a good forum to ask VB questions then www.vbcity.com is where you would like to go as well.

[(+_+)]

Hey (+_+) Any plans on releasing your frontend?

It is something that has always been in the back of my mind. I've been the sole developer and primary tester (my neighbor is the secondary tester and has found a couple of bugs  ) since it's inception. It isn't easy and I'm sure that once it hits the mainstream, there would be bugs that need fixing, install shields for the installing, help files for the making and web sites for the publishing. To be quite honest, I could easily handle the bugs, but the rest is really to much for me to handle at the moment. The launcher does have a lot of promise and does so many things that I sometimes forget it does them. I'd love to get it out there, since I feel such an large effort is wasted if only my next door neighbor and I use it. Any takers on sharing the burden? It may take some growing pains to get over the few humps of getting it installed (VB run time, reg keys, ... etc), but I've always felt it is worth it and continue to feel that way.

SavannahLion, a programming language is definitely a sensitive issue to tackle since there are so many of them as well as so many biased opinions about them as well.
I'm surprised you found Database programming to be so difficult using VB. I wrote a database class to make connections, return recordsets and the like for Sybase, Oracle and SQL server which made my life a breeze for all 3 platforms. It ending up boiling down to whether or not the stored procs being called were robust enough. If anything, I'd probably write my next app in C#. I'm considering writing a Robotron type game in C# using direct x 9, 10, 11, 12 ... infinity    . But again there are just so many hours in a day and I still need to finish my Hyperspace project. The CP art should be done any time now and the wiring festivities should begin. 

[MaMeNnO]

This thread brings back some memories from way back, but that's what we are trying to accomplish with our projects I guess.
Anyway thanks for the thoughts, insight, inspiration and the links not to forget!

[gonzo90017]

I'd love to be a tester for you. A have a spare pc i've been messing around with. I've been testing a bunch of frontends some you've heard of some you haven't like MalagaEmulador. It's using an nlited version of XP the only drawback is it's only 400mhz. But on the plus side because of that i've tested so many emulators to try to get the most out of the hardware. 90-95% of the games run full speed with no frameskip up to mame 84. So if you like what you here let me know.

[SavannahLion]

I'm surprised you found Database programming to be so difficult using VB. I wrote a database class to make connections, return recordsets and the like for Sybase, Oracle and SQL server which made my life a breeze for all 3 platforms. It ending up boiling down to whether or not the stored procs being called were robust enough.

If I recall at the time, a lot of the problem came from the code samples themselves. There was absolutely no consistency on which method was being used in samples so it was generally trial and error figuring it out. There is also never a consistent opinion on which to work with and no centralized resource that made a clear distinction between code samples. All of it made worse due to the vast number of people with little or no reliable VB experience throwing up crappy and incorrect code samples all over the net. IIRC, there is ADO, DAO, and sometimes a third. The last run-in with a VB database project, I just trashed it and gave the guy a refund.

I did have some progress strictly using Access. But, my prefered database of choice tends to be MySQL or Oracle. Neither of which meshed well with VB.

I've thought many times over the years of tackling this last major hurdle of VB, but I haven't had the incentive to go hunting down information about the different methods and any new techniques that might have cropped up since then.

[(+_+)]

I've wasted my share of time with RDO, DAO, ADO and the online code samples that usually didn't work. We ended up porting the older VB code from RDO to ADO. It seemed to work much better. I slightly remember going through a little hell but like I said once the class object was written, it was like a black box that I never had to open again. I probably had the upper hand though since my previous company got me certified in Oracle, gave me training up the wazoo and I had access to experience developers.

If you decide to tackle it again, why not try C# and ADO.net? You should try it again since it'll help open a lot of doors. The money doesn't hurt either.

[(+_+)]

I'd love to be a tester for you. A have a spare pc i've been messing around with. I've been testing a bunch of frontends some you've heard of some you haven't like MalagaEmulador. It's using an nlited version of XP the only drawback is it's only 400mhz. But on the plus side because of that i've tested so many emulators to try to get the most out of the hardware. 90-95% of the games run full speed with no frameskip up to mame 84. So if you like what you here let me know.

That nlite version of XP scares me, not to mention your processor speed. Isn't that the minumum xp processing speed requirement? If I remember correctly, you need to have mediaplayer 10 installed since PowerGamer uses the wmp.dll for the jukebox part of the application. It also requires the VB runtime. I plan to set up an FTP server soon to serve up the required files. I'm also curious to know how long it would take to initialize the program when it first starts up. I store all game/emulator/profile/controller design info in the registry. It whips on my machine but then again I'm running an Intel 6700 core duo. It also ran well on my previous AMD 2800 but even that one is leagues above a 400 mhz rig.  . We can always give it a try. It may help establish a minimum requirements for the app. I'll keep you posted and thanks for the offer.

[gonzo90017]

I have mp10 installed. And i'm pretty sure I have vb runtime installed. Anyways let me know.

[(+_+)]

Hi gonzo90017 , I've installed my FTP server, starting writing a help file and preparing the necessary files to make it run. I'm go to try to get it all together over the next few days and I'll PM you the server info.

[gonzo90017]

Cool.