Main > Main Forum

Arcade hardware question

<< < (3/3)

Hoopz:
My question was definitely not intended to bash anyone, let alone Mamedev.  Just asking for some help understanding.  I have the utmost respect for those who do this in their spare time for everyone's benefit.

ark_ader:
Apparently making accurate suggestions which have already been echo'ed equals bashing now.  :laugh2:

I'll keep on bashing thank you until someone wakes up.

u_rebelscum:
I don't know if you're trolling or not, but assuming you're not...




--- Quote from: ark_ader on October 18, 2007, 02:15:11 pm ---I think the main issue is optimization of the main core....
--- End quote ---

This paragraph is so full of wrong connotations and other non-facts that I can't address them all.  I'll point out just this.

There is little optimization that can be done in the core except what's Aaron is already working on (multithreading).  That is if mame sticks to it's goals: document the original hardware, document as many games as possible, document as close to the the original as possible, be portable, be open to outside contribution, and be actively developed in the future.  In the long term, the last three help optimisation (example: the switch from 16 bit to 32 bit to, currently, 64 bit would not be possible without major headaches). 

More effective (but less global) optimization can be done (and is being done) in the CPU, sound, etc drivers.


--- Quote ---But with so many contributors to the project, the above suggestion would be difficult to accomplish without a stop work order.
--- End quote ---

Agree.  Each person contributing to mame picks what they want to work on, which is usually what games they like and know most about, and what programing areas they're best at.  They all do it for the fun of it.  So you'll get zero progress anywhere in mame if you tried to force everyone to optimise code, as optimising code isn't on most contributors list of things to do for fun.


--- Quote ---I don't think the hardware has anything to do with it today.  You could come up with that argument 5 years ago, but with better coding skills and a better understanding on how the target platform works and whats out there, would see a major improvement.
--- End quote ---

The computation power of the original hardware has a lot to do with it.  Not all, but a lot.  Mame not liking speed hacks also has a lot to do with it, too. 


--- Quote ---Like the previous poster said about it being years since he coded, I too am in that bracket, but even C was harder to implement than Assembler back in the day.  With all the libraries and toolkits available the mere suggestion of coding woes is just an excuse. 
--- End quote ---

You're confusing porting a game with emulation.  Mame does not re-write the original code; that's why you need the original ROMs.  So this whole paragraph is irrelevant and shows you didn't understand what I meant in my example.

I'll repeat it.  Mame emulates the original CPU.  The original ROM has a command (conditional jump in my example).  The original game has no idea it's running inside mame, so it "sends" the command to the "CPU".  Mame does what ever the original CPU would do with that command.  And to fake it, it takes (in this example) 5 lines of C code, which means more than 5 lines in assembly/machine/binary.


--- Quote ---I like the comment about non standarisation of hardware, but vanilla Windows can operate in plain old VGA in just about any graphics card out there.
--- End quote ---

You're missing the point again.  Do you have the same computer as he?  No.  Windows running or not doesn't matter.  That's not what mame does.


--- Quote ---I'm just glad Aaron Giles is leading the project, and he is doing a great job.   :applaud:
--- End quote ---

Agreed.

Navigation

[0] Message Index

[*] Previous page

Go to full version