> The port definition in the driver states the size, and MAME converts it. Why would
> you want to redo the work in 1000s of drivers?
>
> I would recommend to study the code and drivers to understand why it does what it
> does.
I am yet to decide if I'll go for a full re-write, it will depend on the popularity of the build. I really only had to rewrite animation part for proper video/audio sync, and now input handling to get rid of the latency as much as possible since I'm gonna release it to public soon and I'd hate those things to be there.
My motive is the usual one, I think I can make it better, and once the code is free of repetition and redundancy the new design should make adding (converting) drivers quick and easy. I also enjoy doing it, it's my specialty. I also think the desire to make software optimal is only natural, so my question to you is the opposite - why would you not want to re-write MAME?
I am studying the code and drivers, that's exactly what I am doing right now. The part of that study involves me coming here and talking to people who wrote or have worked with the code, which normally should provide the answers faster.
The only question I have right now about the drivers is the opening question of this thread - why would anyone use 8 bytes to store 17 bits precision instead of 4 bytes and 16 bit precision like every other program on this planet, except perhaps Microsoft Windows.
The answer to that question is not in the code, the answer also has nothing to do with portability. I don't see other choice but to conclude there is only one possible answer - it is a mistake. Don't you agree?
|
Previous 
Index 
Next 
Flat 
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
Reply
