AlphaMAME 0.61

Post by **mahlemiut** » Sat Jul 20, 2002 10:05 pm

Ok, here's the first version based on MAME 0.61.

http://mahlemiut.marpirc.net/alphamame061b1.zip

Please, don't upload any recordings to MARP using this version, as it's still being tested. But do let me know of any bugs/problems/whatever.

Post by **mahlemiut** » Mon Jul 22, 2002 8:27 am

http://mahlemiut.marpirc.net/xalphamame061b1.tgz

This is a Linux binary, and should work the same as the Win32 build. Note that it only work on x86 platforms, and is compiled under Red Hat Linux 7.2. Other x86-based Linux versions may or may not work.

DGA should be enabled, as is the x86 68000 CPU core. Display is X11. Based on X-MAME 0.60.1 with the 0.61.1 preview patch. As such, an OpenGL version cannot be built at this time. If anyone would have some other display build let me know, but don't hold your breath, I can only post so many versions here.

There is one problem with this version, and that's that it have little slowdowns every couple of seconds while playing back and recording.

Chad · Post by **Chad** » Mon Jul 22, 2002 11:05 am

you're a gawd! yeah those slowdows i get while in xwindows mode using a DGA binary. REQ: can we get a svga binary? i just figured out how to compile svgalib last night, it was a pain because you it wouldn't make install with the -j2 (normally everything does but the makefile svga has is not multithread compliant nor is the svgalibrary itself for that matter). A regular make worked fine. And i noticed the other person that uploads with xmame recs also uses svga. DGA in full screen crashes my linux box or the video driver which crashes linux, haven't really figured it out yet so i'm trying svga to see if it'll work and not crash.

DRN · Post by **DRN** » Mon Jul 22, 2002 11:25 am

I'm in danger of sounding stupid here but what's Alphamame?

Post by **mahlemiut** » Mon Jul 22, 2002 4:07 pm

DRN wrote:I'm in danger of sounding stupid here but what's Alphamame?

The next TG-compliant (we hope) version of MAME.

kfx · Post by **kfx** » Mon Jul 22, 2002 4:31 pm

What is the difference between 61tg and the normal 61 version? how does the tg stuff work?

Post by **mahlemiut** » Mon Jul 22, 2002 4:37 pm

From the docs:

What's different from the regular MAME build?
---------------------------------------------

- Compressed and encrypted INPs.
- Game speed recorded in INP.
- Pause disabled
- Graphics viewing and Save states disabled (methods of pausing)
- Re-recording disabled (-playback <inp> -record <inp>, introduced intentionally
in MAME 0.35)
- Disabled speed throttling during recording.
- And maybe some other stuff I've forgotten.

kfx · Post by **kfx** » Mon Jul 22, 2002 4:56 pm

Thanks for the quick answer, I got one more question.

Compressed and encrypted INPs

What does that meen?

Chad · Post by **Chad** » Mon Jul 22, 2002 5:37 pm

a quick answer to that is that it'll make marps storage requirements larger, because the compression used (after zip) will be not as good as ziping a bare uncompressed inp. But if you got the more complex answer barry would have to kill you.

Basically with non-encrypted inp files you could hack together a wizard of a game with any mame program and say I'm from japan and make really good scores and have the inp to prove it. But in Reality you just re-recorded inp files untill you eventually passed all the stages of the game (taking as much time as you like, e.g. pausing to go to the bathroom between re-recordings) and later put it together into one INP as if you did it in one credit. When inps are encrypted, it makes it impossible to cut and paste inp recordings unless you know how to decrypt AND recrypt the inp data back into place. the compression is a side effect of the encryption barry is using (i.e. he's using it because he can and it makes the encryption a little harder to decrypt.)

sikraiken · Post by **sikraiken** » Mon Jul 22, 2002 10:38 pm

Dood, that shouldn't be possible. I didn't know that till now..

Just imagine what people could do knowing that. Not that I would do anything of the sort of course, but that just sucks.

Chad wrote:When inps are encrypted, it makes it impossible to cut and paste inp recordings unless you know how to decrypt AND recrypt the inp data back into place.

Anyone who would ACTUALLY even try do that truely has no life.

Haze · Post by **Haze** » Mon Jul 22, 2002 11:57 pm

since you *have* to provide the source under the terms of the Mame License agreement I don't really see what stops somebody from hacking it anyway since your encryption / decryption code has to be open source ...

Chad · Post by **Chad** » Tue Jul 23, 2002 1:20 am

all of the source will be provided and more importantly it WILL be free. the source that has the encryption will be logically ommited for necessity by barry. Otherwise there is NO logical reason to include the encryption algorithm source if the source is available. Since the encryption's existance is the reason it is being hidden. I wonder how far this argument is going to go.

m35tg3 was the same way for some time all source provided except for a few lines and it was provided FOR FREE, even though it was gawd awfully easy to decrypt it with a simple program that you didn't need the source to decrypt it. the new mame has many more challenges for people with no lives.

Post by **mahlemiut** » Tue Jul 23, 2002 4:09 am

Don't tell me this is going to all start up again...

No more Nicola impersonations, please!

BBH · Post by **BBH** » Tue Jul 23, 2002 4:30 am

mahlemiut wrote:Don't tell me this is going to all start up again...

No more Nicola impersonations, please!

Ahhhhh, memories

viewtopic.php?t=3327
viewtopic.php?t=3384

Just a refresher for anyone that might've missed it the first time.

sikraiken · Post by **sikraiken** » Tue Jul 23, 2002 6:54 am

Yea, only thing I'm worried about is an arguement. :/