Home Page Forums Archives MacMAME MacMAME - Source Code Hackers Club?

Long time lurker first time poster....

Okay all you closet programmers (or programmers in training like me)... How many of you MacMAME fans play with the source code of the project?

- Have you thought about re-writing the frontend in cocoa and perhaps make use of tiger stuff like coredata, bindings, etc?

- Have you done more than just thought about it?

- Maybe we can get something going as a group?

As I said above I'm really just a programmer in training and while I'm glad to have access to the source code for MacMAME, but, it's carbon and well I just don't see me going back to learn carbon after diving head-first into cocoa development but at the same time would love to 'play with' making new front ends for MacMAME. - I guess you could say I'm stuck between a rock and a hard place....

Well anyway... just wondering if we had any other closet hackers that might be willing to share ideas etc...

Dave

Thought about it? Yes.

Tinkered with it? Yes.

Understood it? Nope.!

I'm a professional programmer under windows but so far have managed to get to grips with squat programming wise on the Mac. And the only thing i understand within mac mame (and mame in general) is the driver files, but that's not really coding, it's all just macro definitions.

Things i'd like to see (read would like to be able to do!) are:

Get the debugger to really be useful like the windows one by not having the emulation window pause as soon as the debugger has focus (animate doesn't really help me much if i can't see what it's doing while it's animating!)

Have the romident functionality match that of the windows version. Give that a directory name and it'll ident all the files in a directory. Can't select dirs in macmame.

Finally, divorce the emulator from the front end.

Unfortunately for me, it's sheer fantasy to hope to be able to do these things. It's a million miles from the backend image processing work i do for a living!

I did spend ages one night looking at the romident thing but without a scrap of prior knowledge in the mac programming world i think i found WHERE i needed to change things, but didn't have a clue what to change them to

Oh well.

I'd be up for it, but i'd need a major amount of teaching / hand holding!

Martin.

I've written a kind of Cocoa front-end for MacMAME (I will update MacMAMEInfoX soon, promise), and I do play with the MacMAME source a bit. It's very big, and I don't understand how it all hangs together most of the time.

Tinkered with the code? Yes and often. It's mostly to get misfit ROMs working. Sometimes, I tinker with input code just to see what happens.

Rewriting the frontend in Cocoa? No and I never bothered fooling around with that. Except maybe change the default screenshot and that's how far I got.

Have you done more than just thought about it? I love to do more but my understanding of much of the MacMAME is very limited.

Maybe we can get something going as a group? If that can get Multipac working on later MAMEs or Unofficial MacMAME Plus that compiles with Xcode, I'm all for it. Still, I do understand what you're trying to get at.

I guess the first step would be separating backend and frontend. That would make lots of room for a frontend-developers community, and allow ppl to work on the mac port without having to bother with all the carbon stuff...
maybe there is a way to merge xmame sources with brad's opengl and stuff...

Okay....


We seem to have a few potentially interested parties already. Very cool!

-------------

Carbon - As I said, my carbon programming knowledge is 'near zero' but I do know how to traverse the code and can muddle my way into understanding things (all be it with the help of google and company).

Cocoa - Well I'm far from an expert in that but I can 'make my way' with quite a few simple things and more important can find ways to get the answers I need to most of the things I need.

MAME code - cpu emulation, drivers, etc... Not even close! In short, totally over this man's head and I'm pretty sure I'm not ready to even dive into those waters even if I wanted too!

-------------

MacMAME dissecting - Due to lack of carbonized skill - It took me a while to figure out where the windows were coming from (mame.rsrc) and such but little by little I think I'm starting to understand things - the frontend code looks to be fairly well insulated from the rest (Brad either kept things that way or has been migrating his code to the current state)

Much of what is 'macfrontend.c' seems to be very UI related and then it just "calls out" to other code for the things that it needs. For example - code in that gets the 'list of roms' that you see is NOT in macfrontend.c but located in - maclists.c (I think). Same goes for the rest of the stuff.

While macfrontend.c does the job of showing you the screenshot graphic , where macfrontend.c gets the filename for that graphic is from code located outside macfrontend.c.

I hope that make 'some' sense....

I've also read that carbon applications can (now?) contain cocoa code files (for things just like what we want to do - user interface stuff) - Not that I've gone this far yet but it seems like it is 'doable'...

Note: Doing so may prevent MacMAME from running on systems running 10.2 and maybe even 10.3 (not sure yet) but since this is more of an 'exercise' then a 'released product' I'm thinking it'll be okay...

After all you've gotta break some eggs when you bake that cake!

I'll report back when I have new information to share... and don't any of you stop anything you might be doing and by all means share any useful things you might find back here in this thread.

Dave

A cool links you might want to look over:

Using a Cocoa User Interface in a Carbon Application

Dave

Now I think think about the frontend, I do remember messing around with the code that displays the red "X" on the "not working" games. I changed that code so that the X appears games with emulation problems, like games with no sound, imperfect graphics, etc.