Author Topic: New Arcade Database (Read 5856 times)

sysrpl · « **on:** December 07, 2005, 03:14:05 am »

I just announced this in the buy/sell/trade forum. Tonight codebot.org put online a new arcade database. Check it out at:

http://arcade.codebot.org

It will be interesting to see what games make it into the top 100.

HaRuMaN · « **Reply #1 on:** December 07, 2005, 05:22:51 am »

It needs some help... for example, Street Fighter 2:

Quote

Graphics: Raster
Orientation: Horizontal
Sound: Mono

Players: 2
Controller: None
Buttons: 4

ROM: sf2

it had 8 way joys, and 6 buttons each, not 4

sysrpl · « **Reply #2 on:** December 07, 2005, 07:02:22 am »

Quote from: HarumaN on December 07, 2005, 05:22:51 am

It needs some help... for example, Street Fighter 2

fixed: http://arcade.codebot.org/arcade/game/?rom=sf2

You can put corrections in on that page, just click the 'edit' link in the uper right corner and put in the correction

mahuti · « **Reply #3 on:** December 07, 2005, 10:29:49 am »

I'll stick with Klov.

RetroJames · « **Reply #4 on:** December 07, 2005, 10:39:26 am »

This is a step n the right direction, sooner or later this needs to be a Wikki site.

Havok · « **Reply #5 on:** December 07, 2005, 12:03:18 pm »

Quote from: mahuti on December 07, 2005, 10:29:49 am

I'll stick with Klov.

They need to fix the VAPS part, though...

SirPoonga · « **Reply #6 on:** December 07, 2005, 12:17:36 pm »

Where are you getting the information from?

RayB · « **Reply #7 on:** December 07, 2005, 01:04:16 pm »

Quote from: sysrpl on December 07, 2005, 07:02:22 am

You can put corrections in on that page, just click the 'edit' link in the uper right corner and put in the correction

Are corrections verified by an admin first?

menace · « **Reply #8 on:** December 07, 2005, 01:30:32 pm »

I'm not sure I understand--what does it do differently than KLOV? I was hoping someone was updating VAPS so that we could get a more realistic handle on whats rare and what isn't besides hearsay and conjecture...

sysrpl · « **Reply #9 on:** December 07, 2005, 03:05:51 pm »

Quote from: RayB

Are corrections verified by an admin first?

Yes.

Quote from: menace

I'm not sure I understand--what does it do differently than KLOV

It has the beginnings of wiki like acrade list, except the changes are moderated.

You can build your own queries (see http://arcade.codebot.org/arcade/search/help)

Arcade listings have hyperlinks that tie back to queries.

Genres.

It was just put online this morning. Look at it. Think about what features you'd like to see be added. Post feedback. Wait for the community to get it implemented, or better yet, offer to help out.

Oh, and I forgot to mention its free, as in no

yugffuts · « **Reply #10 on:** December 07, 2005, 03:47:18 pm »

Where did the list come from? I noticed you are missing games. IE Mad Dog McCree, Dragon's Lair, Cliff Hanger...you have something against Laserdisc games? Also Tokyo wars is missing, so it's not just that LD games were left out...

sysrpl · « **Reply #11 on:** December 07, 2005, 03:58:09 pm »

Quote from: yugffuts

Where did the list come from? I noticed you are missing games. IE Mad Dog McCree, Dragon's Lair, Cliff Hanger...you have something against Laserdisc games? Also Tokyo wars is missing, so it's not just that LD games were left out...

The initial data was pulled from mame.dk right before it was taken down.

rbarr110 · « **Reply #12 on:** December 07, 2005, 05:08:35 pm »

LOL - very handy but definately some errors.

Toobin was definately not lightgun controlled

SirPoonga · « **Reply #13 on:** December 07, 2005, 05:11:18 pm »

Quote from: sysrpl on December 07, 2005, 03:58:09 pm

The initial data was pulled from mame.dk right before it was taken down.

Which came from mame and explains alot about the accuracy problems.

So, currently, it's really no different than MAWS but shows less info.

RayB · « **Reply #14 on:** December 07, 2005, 08:07:48 pm »

Let me ask you this... if the data is based off of output from MAME, can the corrections made through that site somehow get filtered down so that the MAME info becomes corrected too? That would be great!

sysrpl · « **Reply #15 on:** December 07, 2005, 10:16:02 pm »

Quote from: RayB

Let me ask you this... if the data is based off of output from MAME, can the corrections made through that site somehow get filtered down so that the MAME info becomes corrected too? That would be great!

Yes, there seems to be a problem with many of the items right now. We are going to recreate all of the data tonight, so the incorrect data should be corrected really soon.

mahuti · « **Reply #16 on:** December 07, 2005, 10:58:55 pm »

Weeellllll... only if you don't get the info from MAME. And the question was "will the corrections make it back to MAME? Not necessarily. The controls.dat has made great strides in documenting controls... those changes have not made it into MAME.

pointdablame · « **Reply #17 on:** December 07, 2005, 11:08:44 pm »

MAWS seems much more useful and user friendly at this stage... maybe it'll improve over time though.

sysrpl · « **Reply #18 on:** December 08, 2005, 04:32:24 pm »

Thanks everyone for your feedback. We have made the following changes:

Corrected most all of the incorrect data
Added 2000+ more titles
Added screen resolution and color depth
Added tips and tricks section
Added related titles section

Fixed a few problems with the site that caused errors when viewing certain pages

Also, we are working hard to release our new emulator front end.

SirPoonga · « **Reply #19 on:** December 08, 2005, 05:46:21 pm »

You should add in controls.dat support.

Here's a good reason why
http://arcade.codebot.org/arcade/game/?rom=dotron

Here's why controls.dat exists
http://fe.donkeyfly.com/controls/faq.php#1

Discs of Tron is such a good example, it covers many of the problems.

One problem with mame is it doesn't report ALL the controls a games uses. Do you see dial or 8way coming form listxml? (this is one thing I think lixtxml can improve upon)
Second you might wonder why does dotron list trackball? It's an up/down spinner hack. most people don't have an up/down spinner so whoever create the driver put in that hack. You can use the tball/mouse like a spinner, but also move it up and down to simulate the up/down part of the spinner. Something like this will not get "fixed" in mame because there is nothing wrong with it other than it was added as a hack. Dial and 8way are still defined in the driver.

There are also games that are only, say, 2 buttons but mame lists 4 buttons. Granted these are fixable errors but it will take alot of work. The reason mame reports back 4 buttons is because each game in that driver is using the same macro that maps the buttons to rom memory access. A driver is generally all game that use the same hardware, just different software (roms). So you can play the other games if you swap the roms. That means if a game used 4 button and was defined for the hardware a game that only uses 2 it will still report 4. This is fixable but one would have to go through mame, find these occurances, and change each game to use it's own button defination instead of the macro.

And then there are games like 720 which the devs can't seem to come to a conclusion on. mame has it as stick (with no dials) now, which I think is false documenting for a documentation project. I am fine with stick being there as a hack but the two dials should be defined, or at least commented on their location in the INPUT_PORTS_START function.
for those who don't know 720 used a custom joystick. It's actually a glorified spinner with a handle on it. It had two encoder discs, one that works like a single mouse axis, the other had two notches so the game could calibrate when the joystick was pointing up.

sysrpl · « **Reply #20 on:** December 08, 2005, 10:08:48 pm »

Quote from: SirPoonga

You should add in controls.dat support.

Here's a good reason why
http://arcade.codebot.org/arcade/game/?rom=dotron

Here's why controls.dat exists
http://fe.donkeyfly.com/controls/faq.php#1

Thanks. I will definitely have a look into it, both for the website and the front end.

Regarding 720, yes I know the game well. Back in the '80s I was arcade king of that game. Take the half pipe park to level 4, then the jump park to level 8, then finish to level star, all gold stickers. Favorite park: I'd have to say the jump park. I used to spin the stick so fast that on the star levels, even with the best helment, when I got air in jump parks I could easily overspin the revolutions by about 10. Of course that would make the skater wreck, but it meant I could get perfect stars for any trick.

In discs of tron, I could never get much further than the up/down discs that disappear when hit. Also, the sit down arcade version used a mirror illusion to superimpose the gameplay over "tron-city". I don't know about the upright version of that game, I've never seen one.

Both of those games are great examples of titles that you need the original design to experience.

Finally, are there any front end ideas you people would like to see implemented? Do any front ends make use of animated eye candy? I don't know if it's a big deal, but our front end does video effect transitions, like when you select items the text fades and screen shot zoom in/out, when you change menus it does a horizontal wipe, and when you start a piece of media (video, game, music) there is a transition effect that animates elements into to this:

We are currently implementing UI skinning.

mahuti · « **Reply #21 on:** December 09, 2005, 01:29:29 am »

1. A built in control panel viewer (like johnny5) that displays YOUR controls with data from controls.dat project so you know what is what., a way to switch between control panel views (i.e. I have 3 swappable control panels each of which can play some games... i'd like to see how the key config could work on any of the 3.) this would require some user setup on how their CPO works. Johnny 5 is good, but not integrated into a frontend.

2. A good layout editor for the control panels (above)

3. A good layout editor for skins

4. Support for vertical monitors

5. Support for passing info to Gpwiz49 (like the set49way app)

6. "out of the box" configuration for emulators, with the abiliity to change configuration later.
Current front ends assume users want files / folders all over the place. I would gladly move all of my files / folders around if somebody made it simple. Preconfigured folders...

Frontend folder>emulators>mame>snap
Frontend folder>emulators>mame>roms
Frontend folder>emulators>daphne>snap

Etc. it's not going to work for everyone, but for newbies, would be a huge asset. Just drag / drop files instead of learning a new ini routine or something. A little research into the most common emulators that can be used with a front end (those that can use the "esc" key to escape) would give you appropriate folder names to start with. (there are some problems... but a little thought on this subject could iron them out.

I'll probably remember a few more.

mahuti · « **Reply #22 on:** December 09, 2005, 01:36:08 am »

oh and just as one note. I LOATHE losing time to eyecandy. any TRANSITION is a waste of time. Nice swirly things going on in the background is fine whatever. Taking my time to make it look all fancy is bad GUI design. Basically the GUI should look nice without being a hindrance to its use. The use here is to scroll through games and enter a game. I want that to be absolutely instantaneous. Nice transitions for a screensaver is cool, or animated transitions between certain image areas (like it could be cool to animate between dfferent folders of screenshots... I have screens for titles, ingame, etc) 1 section that contains multiple bits of info that is fairly unimportant (or a USER defined unimportant) could fade between multiple bits of info. Those kind of effects are cool, but anythign that hinders the scrolling through the list is not good. As long as effects don't have to be implimented by a user then they are fine to include (imho)

As an interface designer I am constantly besieged by people to make stuff that has fancy transitions, and in the end, the users hate it. I've watched 'em behind glass.. it drives em nuts.

sysrpl · « **Reply #23 on:** December 09, 2005, 02:17:00 am »

Those are some good ideas.

We have an XML file for the front end that stores all of the configuration data such as the keyboard assignments, program locations, resource locations, and the name/number of the different screens inside the front end UI. When the front end installs it comes with a bunch of pre populated defaults which you can change.

Also, there is a scan function that will search you hard drives form games, videos, and music, and only displays the content you have. Selecting to scan again rebuilds the list.

Eventually we will have a friendly windowed utility that lets you configure the settings without editing the XML file by hand. But this utility will as a separate program from the front end

Quote from: mahuti

1. A built in control panel viewer (like johnny5) that displays YOUR controls with data from controls.dat project so you know what is what., a way to switch between control panel views (i.e. I have 3 swappable control panels each of which can play some games... I'd like to see how the key config could work on any of the 3.) this would require some user setup on how their CPO works. Johnny 5 is good, but not integrated into a frontend.

2. A good layout editor for the control panels (above)

How would you like it if you had a folder where you could place an image of your control panel layouts, and in the front end you could cycle through them as they appeared on screen? The control mappings would be stored in the configuration file, editable through the friendly windowed configuration utility, and then passed to your emulator's settings when you launch a game.

Quote from: mahuti

3. A good layout editor for skins

This is the most difficult feature to implement. We are working on an XML format for the customized skins currently, but designing a format that maps image resources, texture coordinates, colors, sounds, fonts for each front end screen is not too easy, add to that a nice windowed designer application, that's a lot of work.

Sure we want our front end to be the best possible, but we need to prioritize our feature requests. This might make it into our front end, but probably in some release after version 1.0.

Quote from: mahuti

4. Support for vertical monitors

Check.

You can already do this in our front end. It allows you to rotate the front end in 90 degree increments, and stores them settings in the XML configuration file. This value is passed to the emulators when launched.

See the vertical layout screen shot 3 posts up.

Quote from: mahuti

6. "out of the box" configuration for emulators, with the ability to change configuration later.
Current front ends assume users want files / folders all over the place. I would gladly move all of my files / folders around if somebody made it simple. Preconfigured folders...

Frontend folder>emulators>mame>snap
Frontend folder>emulators>mame>roms
Frontend folder>emulators>daphne>snap

Check, we already have preconfigured folders for emulator programs, roms, screen shots, music, videos. You can change the folder locations in the XML configuration file. When you have resources in the folders and launch the front end, it automatically scans those folders for new content.

Quote from: mahuti

oh and just as one note. I LOATHE losing time to eyecandy. any TRANSITION is a waste of time. Nice swirly things going on in the background is fine whatever. Taking my time to make it look all fancy is bad GUI design. Basically the GUI should look nice without being a hindrance to its use.

Point taken. Most of the tranistions we use are very quick, but what you said makes a lot of sense. We will probably remove the game launch transition effect, and just go with a quick 0.5 second fade to black when an emulator is launched.

Also, we run a fullscreen borderless black window in the background from startup, so that when programs switch, you never see the OS.

Thanks again for your ideas, and remember you can visit our web site to post your thoughts or get involved in the community.

http://www.codebot.org

mahuti · « **Reply #24 on:** December 09, 2005, 02:33:18 am »

One thing that I have been thinking of lately. For skin configuration and other configuration issues, FLASH would make an ideal configurator.

1. Very good support for layout

2. Supports XML... requires very little work to import xml files.

3. Can easily output XML based on user input.

Flash could be used to write the XML files... the actual SWF / FLA files wouldn't be needed by the FE... flash could be used just to output the XML. Anyway, there might be nothing that YOU would have to do differently than what you are doing. Someone like me just needs to take your XML and make an example file. The only thing that would be an issue is the way you handle XY coordinates and layering. Your app would have to be able to handle images / text that overlay each other.. it would also need to be able to handle subpixel spacing.

Support for SWFs would be pretty sweet though (not the interactive kind... just animation would be a good start)

mahuti · « **Reply #25 on:** December 09, 2005, 02:37:21 am »

Re: 1.

Control panel key mappings should be taken from mame's own ctrl/ini files... so you only have to configure MAME.

Descriptions of the button names come from controls.dat. (i.e. leftshift=Thrust)

Key placement would be configured by users on CP layout files

sysrpl · « **Reply #26 on:** December 09, 2005, 04:18:04 am »

Quote from: mahuti

Re: 1.

Control panel key mappings should be taken from mame's own ctrl/ini files... so you only have to configure MAME.

Descriptions of the button names come from controls.dat. (i.e. leftshift=Thrust)

Key placement would be configured by users on CP layout files

We feel we need our own key mappings to work with a multitude of emulators.

Rather than using a several configuration files to map what keys interact with both the front end and the games, when you launch a game, we tell the emulator what key mappings to use. This enables the the front end to swap the player 1 and player 2 controls as well as reverse the controls for left and right handed play without exiting the front end. This useful, for example, in changing cocktail table players positions, where the side you are using the UI from becomes player 1.

RetroJames · « **Reply #27 on:** December 09, 2005, 10:37:07 am »

Suggestion on the Arcade DB

Can you hook up an RSS feed that alerts when content updates are made (approved?)

Also, you have no entry for Defender 3...

tsk.tsk.

RetroJames · « **Reply #28 on:** December 09, 2005, 10:38:55 am »

How is the "Top Games" list generated? By views?

mahuti · « **Reply #29 on:** December 09, 2005, 11:44:08 am »

re: 1. I must not understand what you are trying to accomplish with that functionality.

Different games (especially in mame) require different key mappings...When I play donkey kong, it uses 1 button. I need to know which button on my control panel is being used for that one button, and what that button does. If I play king of fighters, it uses 4 buttons. If I have 8 buttons on the panel, I need to know which buttons are being used (is it the top 4 or the bottom 4 of the two rows of buttons?), and what they are for (ie. punch, kick, high kick, etc) I map controls in MAME's ingame (tab) menu to the bottom row of buttons for king of fighters. I map high-kick to left shift, low kick to left alt, etc. These all happen to be on the bottom row. I don't understand how your front end would be able to automatically decide which button configuration suits a particular game.

By reading the .ini files created when I do this mapping within mame, and parsing the info from controls.dat a front end can display how the keys are mapped to my control panel, and what they are called in game.

SirPoonga · « **Reply #30 on:** December 09, 2005, 11:58:53 am »

Quote from: mahuti on December 09, 2005, 11:44:08 am

I don't understand how your front end would be able to automatically decide which button configuration suits a particular game.

By reading the .ini files created when I do this mapping within mame, and parsing the info from controls.dat a front end can display how the keys are mapped to my control panel, and what they are called in game.

You'd have to ask the user if they use ctrlr files or not. I forgot which version, somewhere in the late .70s or early .80s, mame changes their ini files from binary to xml. If the use uses the tab menu you can read the ini files then. They actually aren't ini files, but they use to be called that. The files in the /mame/cfgs/ folder... same format as the ctrlr files.

sysrpl · « **Reply #31 on:** December 09, 2005, 01:34:59 pm »

Quote from: 1hookedspacecadet

Suggestion on the Arcade DB

Can you hook up an RSS feed that alerts when content updates are made (approved?)

For the website, we have the registered user's control panel on the TODO list. We plan on allowing registered users to customize their own rss feeds. What we are in most need of at this moment is a team member with good webpage layout skills.

Quote from: 1hookedspacecadet

How is the "Top Games" list generated? By views?

As of right now games are being ranked by scored votes, then views. Votes and views are unique per ip address and/or registered account, so that for one ip address equals one view or vote.

After the list matures ranking scheme may be modifed, but the details of how and when it will be modified will not be published, to prevent people from attempting to abuse the rankings. For example, we may make it so there there need to be a mimimum number of votes to count, or we discard a perentage of the high votes and low then average the rest.

Quote from: mahuti

I must not understand what you are trying to accomplish with that functionality.

I probably misspoke earlier. I am looking at our source code now, and what we have is mappings like so:

Code: [Select]

  uint UI_CANCEL = DIK_ESCAPE;
  uint UI_PAUSE = DIK_P;
  uint UI_FRAMERATE = DIK_F2;
  uint START1 = DIK_1;
  uint START2 = DIK_2;
  //...

Which are variables mapped to direct input key codes.

When the front end starts up it replaces these values as read from our xml config file. These values are used within the front end to change selection, move to a new menu, add to favorites, start a game, exit the program ect.

Also, using direct input allows the front end to be controlled from alternate input devices like a usb gamepad, be it hacked or not.

When a game is launched we pass the current orientation to mame as command line switches:

mame.exe -resolution WxH [-flipy][-ror][-rol]

But we do not change the mame ini files when launched, so the front end doesn't care about any particular game's input settings.

SirPoonga · « **Reply #32 on:** December 09, 2005, 02:41:23 pm »

Quote from: sysrpl on December 09, 2005, 01:34:59 pm

mame.exe -resolution WxH [-flipy][-ror][-rol]

But we do not change the mame ini files when launched, so the front end doesn't care about any particular game's input settings.

So if someone made a vector.ini file with different options that the mame.ini file (something I do) with your frontend I lost the difference?

Also, why are you using -ror/-rol instead of -autoror/-autorol?

sysrpl · « **Reply #33 on:** December 09, 2005, 03:34:40 pm »

Quote from: SirPoonga

So if someone made a vector.ini file with different options that the mame.ini file (something I do) with your frontend I lost the difference?

Mame reads mame.ini and later vector.ini. The settings in the later ini will override previous, but only when values are present, and I believe only for vector games. I don't see a problem.

Quote from: SirPoonga

Also, why are you using -ror/-rol instead of -autoror/-autorol?

Our front end can be rotated in 90 increments. When mame is launched, the front end passes the [-flipy][-ror][-rol] switches to get mame to match it's rotation.

Nipedley · « **Reply #34 on:** December 09, 2005, 03:44:24 pm »

Hmm.. databases that go by rom name rather than machine name put me off them, for example there is no "Megatech" page just a bunch of useless megatech game's pages like Golden Axe etc..

sysrpl · « **Reply #35 on:** December 09, 2005, 03:53:26 pm »

Quote from: Nipedley

Hmm.. databases that go by rom name rather than machine name put me off them, for example there is no "Megatech" page just a bunch of useless megatech game's pages like Golden Axe etc..

Did you look at the search page?

http://arcade.codebot.org/arcade/search/?query=Mega-Tech

The default search is by tiltle, not rom name.

SirPoonga · « **Reply #36 on:** December 09, 2005, 05:20:32 pm »

Quote from: sysrpl on December 09, 2005, 03:34:40 pm

Quote from: SirPoonga

So if someone made a vector.ini file with different options that the mame.ini file (something I do) with your frontend I lost the difference?

Mame reads mame.ini and later vector.ini. The settings in the later ini will override previous, but only when values are present, and I believe only for vector games. I don't see a problem.

Yes, that's why I am asking, it sounds like you need to list all possible commands you fe sends to mame (if there are more than those) incase someone uses them in the ini files as what you send through command line take priority over the ini files.

Quote

Quote from: SirPoonga

Also, why are you using -ror/-rol instead of -autoror/-autorol?

Our front end can be rotated in 90 increments. When mame is launched, the front end passes the [-flipy][-ror][-rol] switches to get mame to match it's rotation.

It sends that to mame, right?

Do you know what autoror and autorol do? The do the work for you. Instead of you figuring out if it is a vertical game and need to rotate the game autoror and autorol do that for you. It won't rotate horizontal games.

Nipedley · « **Reply #37 on:** December 09, 2005, 05:32:42 pm »

Quote from: sysrpl on December 09, 2005, 03:53:26 pm

Quote from: Nipedley

Hmm.. databases that go by rom name rather than machine name put me off them, for example there is no "Megatech" page just a bunch of useless megatech game's pages like Golden Axe etc..

Did you look at the search page?

http://arcade.codebot.org/arcade/search/?query=Mega-Tech

The default search is by tiltle, not rom name.

That's exactly what I was saying =) All it does is pull up the games that run on the megatech hardware, not any info on the megatech hardware itself

ADD: On that note though, if that is your database you are missing one or two games (that I know of as I own them) and also some info on them ie. some are stereo but most (all?) listed as mono

sysrpl · « **Reply #38 on:** December 09, 2005, 06:08:45 pm »

Quote from: Nipedley

That's exactly what I was saying =) All it does is pull up the games that run on the megatech hardware, not any info on the megatech hardware itself

We currently store title, manufacturer, year, genre, rom name, mono/stereo sound, raster/vector graphics, resolution, colors, screen orientation, number of players, controller type, number of buttons, number of coin slots, original rom, clone roms, related titles, screenshots, game description, game strategy, views, votes, and averaged score.

We aren't planning on storing other info at this time.

Quote from: Nipedley

ADD: On that note though, if that is your database you are missing one or two games (that I know of as I own them) and also some info on them ie. some are stereo but most (all?) listed as mono

Of the 5768 machines we index, 2113 (or 37%) have stereo sound.

sysrpl · « **Reply #39 on:** December 09, 2005, 06:26:56 pm »

Quote from: SirPoonga

Do you know what autoror and autorol do? The do the work for you. Instead of you figuring out if it is a vertical game and need to rotate the game autoror and autorol do that for you. It won't rotate horizontal games.

I probably didn't explain myself correctly.

The goal is that the game's orientation matches the front end's orientation.

-autoror won't accomplish this

Say for example that you have the front end UI rotated 90 degrees clockwise, when mame is launched the front end tells mame -ror so that it is also rotated 90 degrees to the right. If the UI was rotated counter clockwise, it would be passed -rol instead

Now suppose the front end is rotated 180 degrees, When it mame is launched it is passed -flipy so that the orientation of the game matches the orientation of the front end.

The practical purpose of this is that from whatever perspective you are viewing the front end from, it would be expected that the game is presented properly to that same perspective.


Main	Restorations	Software	Audio/Jukebox/MP3	Everything Else	Buy/Sell/Trade
Project Announcements	Monitor/Video	GroovyMAME	Merit/JVL Touchscreen	Meet Up	Retail Vendors
Driving & Racing	Woodworking	Software Support Forums	Consoles	Project Arcade	Reviews
Automated Projects	Artwork	Frontend Support Forums	Pinball	Forum Discussion	Old Boards
Raspberry Pi & Dev Board	controls.dat	Linux	Miscellaneous Arcade	Wiki Discussion	Old Archives
Lightguns	Arcade1Up	Try the site in https mode		Site News


Unread posts \| New Replies \| Recent posts \| Rules \| Chatroom \| Wiki \| File Repository \| RSS \| Submit news