Question to PowerMAME32 users

[MikeQ]

Would PowerMAME32 users like to see all the game specifc features on a single PowerMAME tab or spread out amongst the other tabs that they would normally belong to?

Thanks,

Mike

[Kremmit]

Both?

[MikeQ]

Both?

Your a huge help....

[MYX]

I think that PM should have it's own tab. It would make changing the PM specific stuff easier. This way you don't have to go hunting.  Just my 2 cents worth.

[MikeQ]

I think that PM should have it's own tab. It would make changing the PM specific stuff easier. This way you don't have to go hunting.  Just my 2 cents worth.

OK.  I was thinking along the same lines.  So for per game features, there is now a PowerMAME tab on the game options dialog.

[SirPoonga]

I think that would make it easier to maintain.  Instead of mucking with the gui of all tabs just add a single tab for each new version of mame.

[MikeQ]

I think that would make it easier to maintain.  Instead of mucking with the gui of all tabs just add a single tab for each new version of mame.

Well I was pleasantly surprised the last time I merged some of my changes.  The gui .rc file merged without a single problem.  I figured this would be an issue but it wasn't. 

I'm going to keep it on a tab just because it differentiates what is and isn't a PowerMAME feature.

I've got a question for you SirP.  Controls.dat comes in a plain text and XML format correct?  Which is more commonly used? and do you have parsing routines or does everyone implement thier own?

[SirPoonga]

I've got a question for you SirP.  Controls.dat comes in a plain text and XML format correct?  Which is more commonly used? and do you have parsing routines or does everyone implement thier own?

It comes in ini and xml formats.
I would say it is split on which gets used.  Johnny5 uses ini format which is the most popular program that uses constols.dat.  But almost everything else uses xml that I am award of, like ListGen.

The developers package has info on the formats used, along with an algorithm suggestion
http://fe.donkeyfly.com/controls/controls_dat.php

[Howard_Casto]

How it gets used really depends on the development environment and if it has a good xml parser available. 

I use the ini format because I coded j5 in vb6 and a good xml parser doesn't pop up until .net.  Since mame includes an xml parser this one should be a no brainer. 

[SirPoonga]

and a good xml parser doesn't pop up until .net.

ACtually, the one in .net is pretty good.  It's what set49mode uses.  Granted for the 26meg listxml file it still struggles, but for controls.dat it should be fine.

[Silver]

vb6 - I found a great XML parser as part of the MSXML package. The default "DOM Document" approach was horrible - took ages to run and consumed 400megs RAM to read variables from the mame xml output. However, there is also a nifty SAX parser in there. Its a one pass approach - it flies through the xml file and reads any data you flag into variables or whatever in seconds or less, for the whole 30meg file.

[SirPoonga]

yep, sax is the way togo.  DOM builds the entire tree in memory, hence why it took up so much.  SAX deals with the file as you read it.  Each has it purpose, but for this SAX is what you need.

[Howard_Casto]

I haven't gotten enough time to really mess with sax yet, but considering I'm currently rebuilding dk's core in a few minor areas it might be worth a look.  You guys wouldn't know if there is a way to treat an xml hierarchy like a database would you?  Mind you I can load my text files into a database, but that requires dependencies and I like to keep my apps as lite as possible these days. 

I'm looking for a faster way to implement my filtration system barring the obvious solution (an access database).  I want something I can do totally in memory but has built in searching features that are actually fast when filtering out the 5,000+ entry masterlist the average dk user would have. 

[Silver]

I'm no expert programmer, generally learning as I go...

The DOM approach lets you essentially treat the XML as a database, (it loads the entire tree to memory, and you can search for any value or node) but is essentially useless for any reasonably sized XML file. (Don't even think about it for mame).

What I did is do a single pass of the XML file using the SAX parser, but I flagged up all the info I was interested in - romname, full game name, romof, cloneof, and every joystick and button, - for every game. All of this info is passed into simple arrays in memory during the parse. Everything else in the xml is ignored. The entire process takes well under 2 seconds for me. This gives me arrays so that if rom(10) is 1942, then romname(10), full game name(10), romof(10), cloneof(10),joystick(10)..... gives all the info associated with 1942.

I then go through the users actual roms on disk and pull the info from the arrays as needed. So if I find 1942.zip in the rom folder, I'll search the rom() array for '1942' to find its position in the array - get a return of '10' - and I have instant access to all the info I need for 1942. (You can build a Hash table of the rom()  for searching - makes it enormously quick to search).

This is a bit simplistic, and its not that far removed from txt scanning the xml line by line and pulling all the info you need, but the SAX parser (from MSXML I used - yes a dependancy - but I think there are lots of other SAX parsers out there) is basically doing the same thing and returning data for nodes you specify in advance....

(In my program I SAX parse mame.xml and then controlsdat.xml to pull all the data into memory arrays, then search controlsdat to get accurate data, then search mame.xml if controlsdat has no info - remember to check for clones in controlsDat of course...  )

[Howard_Casto]

Well right now I take listinfo data, convert it into easy to read delimeted text files and load the whole thing into a 3d array in memory.  It's essentially what you are describing, it just makes for very slow filtering as you have to search every game entry programatically instead of calling a function and have windows do it "automagically". 


I did find an article the other day on how to use .net classes/dlls/ect in vb6.  This is very cool as I now have access to the .net xml goodies.  It'll take some research to get it working properly though. 

[screaming]

I'm no expert programmer, generally learning as I go...

The DOM approach lets you essentially treat the XML as a database, (it loads the entire tree to memory, and you can search for any value or node) but is essentially useless for any reasonably sized XML file. (Don't even think about it for mame).

What I did is do a single pass of the XML file using the SAX parser, but I flagged up all the info I was interested in - romname, full game name, romof, cloneof, and every joystick and button, - for every game. All of this info is passed into simple arrays in memory during the parse. Everything else in the xml is ignored. The entire process takes well under 2 seconds for me. This gives me arrays so that if rom(10) is 1942, then romname(10), full game name(10), romof(10), cloneof(10),joystick(10)..... gives all the info associated with 1942.

I then go through the users actual roms on disk and pull the info from the arrays as needed. So if I find 1942.zip in the rom folder, I'll search the rom() array for '1942' to find its position in the array - get a return of '10' - and I have instant access to all the info I need for 1942. (You can build a Hash table of the rom()  for searching - makes it enormously quick to search).

This is a bit simplistic, and its not that far removed from txt scanning the xml line by line and pulling all the info you need, but the SAX parser (from MSXML I used - yes a dependancy - but I think there are lots of other SAX parsers out there) is basically doing the same thing and returning data for nodes you specify in advance....

(In my program I SAX parse mame.xml and then controlsdat.xml to pull all the data into memory arrays, then search controlsdat to get accurate data, then search mame.xml if controlsdat has no info - remember to check for clones in controlsDat of course...  )

  Good description.

[SirPoonga]

What I did is do a single pass of the XML file using the SAX parser, but I flagged up all the info I was interested in - romname, full game name, romof, cloneof, and every joystick and button, - for every game. All of this info is passed into simple arrays in memory during the parse. Everything else in the xml is ignored. The entire process takes well under 2 seconds for me. This gives me arrays so that if rom(10) is 1942, then romname(10), full game name(10), romof(10), cloneof(10),joystick(10)..... gives all the info associated with 1942.

Which is why I think you are going to see new frontends start to use a local database like sql server express, access, or sqllite.   It owuld be much easier to dump all that info to a database and query the database instead of loading it all into memory when program starts up.

[Howard_Casto]

What I did is do a single pass of the XML file using the SAX parser, but I flagged up all the info I was interested in - romname, full game name, romof, cloneof, and every joystick and button, - for every game. All of this info is passed into simple arrays in memory during the parse. Everything else in the xml is ignored. The entire process takes well under 2 seconds for me. This gives me arrays so that if rom(10) is 1942, then romname(10), full game name(10), romof(10), cloneof(10),joystick(10)..... gives all the info associated with 1942.

Which is why I think you are going to see new frontends start to use a local database like sql server express, access, or sqllite.   It owuld be much easier to dump all that info to a database and query the database instead of loading it all into memory when program starts up.

Have you looked at new front ends lately?  I mean no offense to anyone out there, but after 3 years of dormancy dk is still the only fe out there that supports advanced filtering techniques.  3d arcade does it, but to a more limited degree.  Again though... emulaxian/3d arcade is like three years older than dk.  So as I see it we get one good fe every 3 years and a slew of crappy ones.  Not crappy as in they don't look nice, or won't launch a game, but crappy as in they don't have the basic functionality needed to actually manage a 5000+ entry masterlist of games.

And to all of you out there that are confused by that comment, "mangage" does not mean make a single, giant "mame" gamelist.  Manage, does not mean hardcoding gamelists based on catvers when the average user probably doesn't want to waste a 4 entry gamelist for "basket-weaving / underwater".  Manage also doesn't mean forcing a user to manually add/delete/tag every single game in the masterlist to make a new custom gamelist.  Manage means being able to add a few simple search/filter strings into the fe somehow and have it spit out a gamelist based on those requirements.   

ok I'm done ranting....

[Buddabing]

What I did is do a single pass of the XML file using the SAX parser, but I flagged up all the info I was interested in - romname, full game name, romof, cloneof, and every joystick and button, - for every game. All of this info is passed into simple arrays in memory during the parse. Everything else in the xml is ignored. The entire process takes well under 2 seconds for me. This gives me arrays so that if rom(10) is 1942, then romname(10), full game name(10), romof(10), cloneof(10),joystick(10)..... gives all the info associated with 1942.

Which is why I think you are going to see new frontends start to use a local database like sql server express, access, or sqllite.   It owuld be much easier to dump all that info to a database and query the database instead of loading it all into memory when program starts up.

Yep. That's what my ListGen utility does. If I ever build a frontend around ListGen, it will have SQLite built in, and will have great search capabilities, and list generation will be fast.

[Silver]

Yes I'm surprised there is not more demand/response for on-the-fly list generation/filtering in frontends. Something like SQLite or similar eats 6000 game database entrys for breakfast, and could cope easily with flipping between genres or years or similar - which is something I hope to be doing when I finally get round to building a cabinet....