|
Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
#280105 - 03/23/12 12:08 AM
|
|
|
Something I've always been curious about. MAME defines the range of input values for axes such as analog joystick axes, or deltas such as mouse motion, as -65536 to +65536.
This is 17 bits in each direction. Why not a more logical -65535 to +65535? That is 16 bits in each direction.
From my reading of the code, the entire acceptable range of input values is inclusive of these 17 bit ranges. It would make more sense if the ranges are -65536 to +65536 *non-inclusive*, but the code and the comments don't read that way.
Why are these ranges 17 bits?
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Bryan Ischo]
#281108 - 04/01/12 04:55 AM
|
|
|
Either no one cares - or you need to post this in MAMEChat.
|
Consider it high comedy....sincere tragedy....whatever...don't take it personally.
The Culture
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: mogli]
#281702 - 04/06/12 04:29 PM
|
|
|
> Either no one cares - or you need to post this in MAMEChat.
Won't help. Derrick's the only man who knows this and the "MAME public" burned their bridges with him a while ago.
|
|
|
| mesk |
|
@ the arcade
|
|
|
|
|
Reged: 03/03/11
|
|
Posts: 484
|
|
Loc: Rhode Island
|
|
|
|
Send PM
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: R. Belmont]
#281717 - 04/06/12 09:58 PM
|
|
|
> Won't help. Derrick's the only man who knows this and the "MAME public" burned their
> bridges with him a while ago.
Talk about being late to the party.This is the third time I have heard of the "MAME public" burning its bridges with a developer\emu author.
|
|
|
| B2K24 |
|
MAME @ 15 kHz Sony Trinitron CRT user
|
|
|
|
|
Reged: 10/25/10
|
|
Posts: 2663
|
|
|
|
|
|
Send PM
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Bryan Ischo]
#281719 - 04/06/12 10:11 PM
|
|
|
> Why are these ranges 17 bits?
Isn't it better to have too many than not enough? 
|
|
|
| Sune |
|
Connected
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 5648
|
|
Loc: Lagoa Santa, Brasil
|
|
|
|
Send PM
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: R. Belmont]
#281856 - 04/08/12 07:07 PM
|
|
|
> > Either no one cares - or you need to post this in MAMEChat.
>
> Won't help. Derrick's the only man who knows this and the "MAME public" burned their
> bridges with him a while ago.
Sorry to hear that, I must have missed it. It can't be that bad, he posted something in the bin the other day.
S
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Sune]
#281960 - 04/09/12 04:38 PM
|
|
|
> Sorry to hear that, I must have missed it. It can't be that bad, he posted something
> in the bin the other day.
The bin is where emulation goes to die 
Also, I know you were involved with the thread in question. Does "gear shifts" ring any bells?
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: R. Belmont]
#283757 - 04/24/12 08:06 PM
|
|
|
> > Either no one cares - or you need to post this in MAMEChat.
>
> Won't help. Derrick's the only man who knows this and the "MAME public" burned their
> bridges with him a while ago.
Just to clarify, the MAME public has been great, it was just a couple of trolls that took any joy I had in the hobby and totaly killed it.
I had long ago added sound to most of the games I had interest in. (Amazing Maze, Asteroids, Fire Truck, Sprint) I only worked on the other games because I knew how. I worked on the input system because I am a hardware kind of guy. But that is where I got the most flack from people who thought I owed it to them to do it their way imediately. It seems they are still waiting and haven't figured it out on their own.
As for the +/-65536 decission, that was Aarons decisson to make it universal for any kind of future OS port. As is the 512(IIRC) steps per mouse movement. I just went along, because it does not really affect anything other them adding a little complication to the code.
take care all,
D.
P.S. There was also never any winter here this year, so I was not walled in the house by snow this year.
|
Do not p-mail me for help compiling my updates, ask on the board.
Do not request sound for your favorite game. I work on whatever, when I get around to it.
If you have schematics for discrete sound games not easily found on the net, I would be interested.
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Derrick Renaud]
#283775 - 04/24/12 11:22 PM
|
|
|
> P.S. There was also never any winter here this year, so I was not walled in the house
> by snow this year.
Damn global warming...
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Bryan Ischo]
#283900 - 04/26/12 01:41 PM
|
|
|
Bryan Ischo,
Please point me at what file(s) are you looking at and what variables? What data type is used to store that value?
I would expect the range to be -1.0f to 1.0f, although most of the games probably use −128 to 127, or something like that, but in any case, is that range you are talking about passed to all the game drivers or is it converted to something else first?
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: R. Belmont]
#283909 - 04/26/12 03:21 PM
|
|
|
R. Belmont,
Except C/C+, what else is there to know? Surely you must have opinion on the subject regardless of whether or not you are aware of the current implementation, eh?
As much as I gather you are one of the last "MAME devs" around, so if you don't know, and the other guy left, does that mean the project is in need of someone who would look at it, or is everyone happy (don't care) to leave it as it is?
On the side note, I find it interesting with all the re-writes MAME went through, that input and frame stepping (animation) algorithms stayed almost completely unchanged from the DOS days. Can you comment on that?
By the way, I am making my own MAME re-write, just finished with frame-stepping algorithm, accompanied with numerous changes to how timing and general frame and audio syncing is handled there. Those changes fixed all the visual glitches and audio hiccups and crackling MAME is cursed with, as you know, or do you not?
Auto frame skipping algorithm is wrong. Some kind of attempt at telecine on the fly, but that doesn't work, it can not work. It's like dividing 5 by 3 and expecting to get a whole number as the result. There are only two properly working frameskip values in MAME: 6 and 9, (from 60fps -> 30fps, 15fps), but even using those would still leave you with audio syncing issues. You know what I'm talking about? Let me know if you wanna hear more.
Anyway, the input handling is next for me to re-write, which brings me here, and that part is tough one since it's everywhere, interwoven in user interface and worst of all it may impacts all the game drivers, possibly requiring individual changes to every one of them.
My re-writes are drastic, you probably will not like it. I throw away anything not absolutely necessary, which turned out to be around 80% of the code so far, but even if you don't think my re-writes are suitable we can still talk about it and hopefully there is something for both of us to learn by it.
Oh, by the way, I was also exploring the possibility to do "interlaced rendering" so every other frame have odd lines and the next one even lines of the frame. I can of course do it with post processing and it looks cool, similar to scan-lines effect, but what I really want to do is to use it as optimization trick, so to skip processing half of each frame and therefore hopefully gain some speed up while getting a cool visual effect in the same time, and I was hoping I could do it from "drawgfx.cpp", but it seems this must be done with each game driver individually, each one possibly requiring unique modifications. Can you tell me anything more about it, do you know how was interlaced rendering handled in DOS builds that supposedly could do it with arcade monitors?
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: LazyCat]
#283915 - 04/26/12 04:06 PM
|
|
|
> Bryan Ischo,
>
> Please point me at what file(s) are you looking at and what variables? What data type
> is used to store that value?
>
> I would expect the range to be -1.0f to 1.0f, although most of the games probably use
> −128 to 127, or something like that, but in any case, is that range you are
> talking about passed to all the game drivers or is it converted to something else
> first?
It is the range passed from the OS layer to MAME which then gets converted to the port value needed by the game driver. Which can be anything. 1bit, 2bits, 8bits, 16bits, etc
read the input .h files its described at the top of one of them.
|
Do not p-mail me for help compiling my updates, ask on the board.
Do not request sound for your favorite game. I work on whatever, when I get around to it.
If you have schematics for discrete sound games not easily found on the net, I would be interested.
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Derrick Renaud]
#283925 - 04/26/12 07:13 PM
|
|
|
> It is the range passed from the OS layer to MAME which then gets converted to the
> port value needed by the game driver. Which can be anything. 1bit, 2bits, 8bits,
> 16bits, etc
>
> read the input .h files its described at the top of one of them.
Ok, thank you.
Would it not be more convenient and more "object oriented" design if each driver converted the value for itself, since it already has to know what it needs and the data is defined in the driver part of the code anyway, right? In that case emulator would not need to care which driver is running, to MAME it would all be the same. -- Anyway, this is type of simplification and reduction of code I go for in my re-writes, where basically the single purpose and goal is to make MAME as small and as fast as possible, while still keeping it portable. I'm porting it to mobile platforms by the way, that's why.
As for 17 bits precision...
0 to 65535 fits in 16 bits, two bytes, so you need four bytes to store the whole range, the data type "long" or "doubleword", that is 32 bits.
Now, to fit that one extra bit on each side, which insignificantly increases resolution, you have to use "long long", that is 64 bits or 8 bytes. Four more bytes just to store two extra bits.
To know whether it affects anything, or not, we have to do it the other way too, so we have something to compare. Input handling is the kind of thing that is processed at least once per frame, so just passing 8 bytes instead of 4 as a function argument can very easily impact performance, and then take into account all the operations you perform on those variables and I bet you will gain at least 3-4 frames if everything done with 32(16) instead of 64(32) bit variables. Not to mention hardware platforms that would have extra trouble processing and transferring those large chunks simply due to processor architecture and width of the bus, who knows?
All that aside, the motive for doing so, and even complicate the code for the sake of it, as you said, seem completely out of place. Why do you think "long long" would be more portable than "doubleworld" data type? If that even matters with proper compiler, would it not rather be the opposite?
It's not up to today's code to try and be modern for tomorrow's hardware, it's up to hardware to be backwards compatible with yesterday's software. Stick with ints and floats and I guarantee your code will compile and work forever, on whatever hardware future brings... unless humanity goes completely crazy and we see the day when people eat their soup with a shovel instead of spoon.
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: LazyCat]
#283952 - 04/26/12 11:55 PM
|
|
|
> Would it not be more convenient and more "object oriented" design if each driver
> converted the value for itself, since it already has to know what it needs and the
> data is defined in the driver part of the code anyway, right?
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.
|
Do not p-mail me for help compiling my updates, ask on the board.
Do not request sound for your favorite game. I work on whatever, when I get around to it.
If you have schematics for discrete sound games not easily found on the net, I would be interested.
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: LazyCat]
#283972 - 04/27/12 05:23 AM
|
|
|
> By the way, I am making my own MAME re-write, just finished with frame-stepping
> algorithm, accompanied with numerous changes to how timing and general frame and
> audio syncing is handled there. Those changes fixed all the visual glitches and audio
> hiccups and crackling MAME is cursed with, as you know, or do you not?
>
> Auto frame skipping algorithm is wrong. Some kind of attempt at telecine on the fly,
> but that doesn't work, it can not work. It's like dividing 5 by 3 and expecting to
> get a whole number as the result. There are only two properly working frameskip
> values in MAME: 6 and 9, (from 60fps -> 30fps, 15fps), but even using those would
> still leave you with audio syncing issues. You know what I'm talking about? Let me
> know if you wanna hear more.
Video and audio syncing are particularly important when running on 15KHz arcade monitors. If you don't get any interest here from the core MAME people, you might want to drop by the GroovyMAME forum over on BYOAC... http://forum.arcadecontrols.com/index.php?board=52.0
I think that GroovyMAME has some custom code that attempts to sync sound and video and I'm sure Calamity and BitByteBit would be interested in hearing about your methods for frameskipping.
|
GroovyMAME support forum on BYOAC
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Derrick Renaud]
#283973 - 04/27/12 06:02 AM
|
|
|
> 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?
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: LazyCat]
#284020 - 04/27/12 04:34 PM
|
|
|
I have stated the reason it was done, but you are free to agree or disagree as you see fit.
Remember MAME has to convert from any possible OS input to any possible game input port. It has nothing to do with what Windows or any other OS uses.
One of the other reasons is to be able to convert part of a signed OS axis to an unsigned MAME driver input port.
eg: you may want to map 1/2 of your OS joystick axis to an unsigned 16 bit game driver port in MAME. so you need half of +/- 65535 on the OS part side to easily map to 0 to + 65535 for the MAME driver. To give an example, would be to use half an OS joystick axis as a gas pedal in the emulated game.
In case you don't know, you can select any of full axis, - axis, + axis of the OS analog input to be used for MAME input.
Personally I would have used 16bit +32767/-32768 because I do not know of any game with an analog port greater then that. Also 1 bit per relative (eg mouse) input. But the decission was made to be as universal as possible to cover any future unseen case.
Again it was not my decission, so do whatever you like. That is the joy of open source code.
FWIW, changing it to 16bit, will not change the driver speed or latency in any real sense.
As to my question of why you would want to modify all drivers, I say again why? That is a step backwards that would have to be maintained in 1000s of drivers. Currently everything is handled in the game drivers by simple PORT_ macros that link a port to properly sized OS data. Your not liking 17bit OS data should have no affect on the drivers.
|
Do not p-mail me for help compiling my updates, ask on the board.
Do not request sound for your favorite game. I work on whatever, when I get around to it.
If you have schematics for discrete sound games not easily found on the net, I would be interested.
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Derrick Renaud]
#284162 - 04/28/12 06:18 PM
|
|
|
> I have stated the reason it was done, but you are free to agree or disagree as you
> see fit.
>
You said the reason was to make it universal for any kind of future OS port, but 17 bits is not universal.
I did a quick search for DirectX specifications for analog joystick interface and instead found Linux and Xbox use -32767 to 32767, which was enough to convince me that was in fact the standard (universal), so if you want to conform to standards you should use that, but the real reason should be because that's sufficient while 17 bits are unnecessary and very non-optimal.
http://manpages.ubuntu.com/manpages/natty/man1/jscal.1.html
http://msdn.microsoft.com/en-us/library/windows/desktop/ee417001(v=vs.85).aspx
> Remember MAME has to convert from any possible OS input to any possible game input port.
>
I don't see "possible" when there is no input device that sends it, no OS that gets it, and no game in MAME that needs it. (17 bits)
> It has nothing to do with what Windows or any other OS uses.
>
I hear you, it's about what some future OS might use.
I never heard anyone thinking like before. The only thing I can think of that is similar to what you are talking about is when DOS games didn't use relative timing but relied on CPU speed so they don't work properly today, however all the other software does, and as long as you are not doing anything unwise like that your code will be future proof too, without any need for trying to predict the future.
> One of the other reasons is to be able to convert part of a signed OS axis to an
> unsigned MAME driver input port.
> eg: you may want to map 1/2 of your OS joystick axis to an unsigned 16 bit game
> driver port in MAME. so you need half of +/- 65535 on the OS part side to easily map
> to 0 to + 65535 for the MAME driver. To give an example, would be to use half an OS
> joystick axis as a gas pedal in the emulated game.
>
> In case you don't know, you can select any of full axis, - axis, + axis of the OS
> analog input to be used for MAME input.
>
Your example does not need 17 bits. And why scale the range to +/- 65535 if the resolution you get from the input device is maxed at -32767, 32767? Maybe Windows and DirectX are different after all?
Let me see... no, DirectX just the same, SDL too.
http://msdn.microsoft.com/en-us/library/windows/apps/hh780563.aspx
http://freegamedev.net/wiki/Input_Handling
> Personally I would have used 16bit +32767/-32768 because I do not know of any game
> with an analog port greater then that. Also 1 bit per relative (eg mouse) input. But
> the decission was made to be as universal as possible to cover any future unseen
> case.
>
Decision, as if there was some discussion about it?
Using four more bytes just to store two extra bits does not make it universal, nor it covers any future cases, because if any future interface decide to use 32 bits for precision it will use its full range: −2,147,483,648 to 2,147,483,647.
> Again it was not my decission, so do whatever you like. That is the joy of open
> source code.
>
I will change it in my build for sure, and you should change it in your too. Why would you trust some Aaron character more than your guts, and me, the Lazy Cat, anyway? Meow!
> FWIW, changing it to 16bit, will not change the driver speed or latency in any real
> sense.
>
Sounds like a bet, I accept!
Never used MAME profiler much and removed it from my build, but this looks like a perfect opportunity to see what's really worth. Can it measure input latency? You seem pretty certain there, what do you base your opinion on?
> As to my question of why you would want to modify all drivers, I say again why? That
> is a step backwards that would have to be maintained in 1000s of drivers.
>
I believe to have really simple and elegant design that would make adding drivers, that is converting from MAME, very easy, where one of the benefits of that new design is: *no more maintenance*. In this "UtopiaMAME" it will not be possible any more to screw up working drivers by fiddling with other drivers, adding new games or new features. I'd say that's a step forward.
Maintenance? What are your drivers made of, snowflakes?!
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Derrick Renaud]
#284185 - 04/29/12 12:51 AM
|
|
|
I see you are surprised about re-write for what seems like a huge effort where there is no any personal gain, only I never told you what is my build really about. Chinese bootlegger? No, but I'm not rewriting it just because crows drank my brain either, or to maintain yet another unnecessary xxxMAME build with few different settings. I have two big new features, one never before seen in MAME or any other emulator, as far as I know, and the other never before seen anywhere else. I need MAME to present and advertise these two new features, that will also be available for purchase as separate libraries on Android and possibly iPhone market. The two features can be incorporated and used in other emulators and also in any other games on those mobile platforms. Both features are completely independent and unrelated to MAME source code. One of those features is possible to implement on a PC too, but not the other. Two of them are not related in any way, one is related to playability and the other to re-playability of the games.
Would you like to guess what those two features are about?
And that's all ready for testing, but I think I can get in trouble with Google if I post a link outside Android Market, so maybe it's best to wait few more weeks when it will be available for download from the Market, for free. Although, I suppose I could give you a link in a private message.
I don't need full MAME rewrite to publish that, it's good enough as it is for the purpose it needs to serve. But, if it becomes popular, as I said, then I'll probably go for the full re-write. I'm only actively working with 7-8 games and supporting around 100 "test" games all together until I'm happy with the design and start mass-converting. Anyway, if all that goes well then there will also be a third very cool feature. I will try to add support for some home computers and consoles, but nothing like MESS is doing. In my build C64 or NES will be ROM images that you load in MAME just like Pac-Man and Donkey Kong, and will have their drivers designed in similar manner as any other hardware platform in MAME, as "driver", not interwoven within and obfuscating MAME code. How does that sound?
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: LazyCat]
#285511 - 05/08/12 06:24 AM
|
|
|
I think that the input system of MAME as implemented could definitely use a re-design, and if you can accomplish that and improve the design and implementation, I say do it, definitely.
That being said, in libmame I attempted to hide all of the nuances of the MAME input system behind an API that is fairly sane. Rather than deciding to attempt to redesign the MAME input system, I just defined my own API and put all of the MAME stuff on one side of it, allowing everything on the other side to not care about the implementation details.
I don't personally believe that input latency can meaningfully be improved, and I don't think you'll accomplish significantly better input latency with any rework you do. However, making the code more readable and more maintainable would be welcome.
I read your other posts about improving the audio and video systems with interest. I hope you can accomplish what you want to in a way that can be incorporated back into MAME. I am not aware of the specifics of the issues you are dealing with - I didn't realize that MAME had flaws in its audio or video handling that would cause video frame rate jittering or audio buffer underruns (cracking, etc), but if it does and you can fix them, that would be awesome.
I think there is nothing wrong with wanting to improve MAME and I support you in your efforts. I also agree with you that the way that MAME is implemented, so much of it is intertwined in suboptimal (from a design and maintenance perspective, not so sure about performance but we'll see) ways and it would be difficult to make significant changes piece by piece. So it's only natural to want to rewrite large parts of it rather than deal with trying to make incremental changes.
For what it's worth, I think that the C++-ification that's been worked on off-and-on by Aaron is not very useful. Maybe it is from a MAME driver writer's perspective but it looks to be very marginal to me, and the use of a terse and self-obfuscating C++ style doesn't help. Like I said, maybe somehow driver writer's jobs are being made easier but looking at how drivers are currently defined, with a bunch of confusing macros that have been repurposed and overloaded in weird ways, not to mention weakly documented, I can't see how things could be worse. But that's just my opinion, and it's not super highly informed (I've never written a MAME driver), and I'm only posting it here because this thread seems to be a place that dissatisfaction with MAME design is a relevant topic.
More on topic, I agree with everything you wrote about the 34 bits analog input ranges. It's nonsensical. 32 bits would already be overkill - is there any input device for which input ranges of -32678 to +32767 is not sufficient? I would say absolutely not. It reminds me of the type of design sensibility that says that 128 bit filesystems might not be sufficient even though you'd need more energy than it would take to boil all of Earth's oceans to populate a 128 bit filesystem.
In libmame I recently collapsed the range down to 16 bits in either direction and scale the results to 17 bits before passing them to MAME. The one part out of 32000 difference in accuracy will never, ever be detectable.
Edited by Bryan Ischo (05/08/12 06:28 AM)
|
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Bryan Ischo]
#285542 - 05/08/12 03:34 PM
|
|
|
>> I think that the input system of MAME as implemented could definitely use a re-design, and if you can accomplish that and improve the design and implementation, I say do it, definitely.
<<
It's only that my build is based on 0.37, I will try it there first.
>> I don't personally believe that input latency can meaningfully be improved, and I don't think you'll accomplish significantly better input latency with any rework you do. However, making the code more readable and more maintainable would be welcome.
<<
Has anyone ever even attempted to measure input latency in MAME?
I've seen some funny comments in older MAME builds that seem to suggest input is actually delayed on purpose. Not sure what was the reason, think it's about catching multiple simultaneous inputs (keystrokes?). Possibly has to do with the speed of serial transfer via USB or PS/2. I will start my investigation from there.
Anyway, just like in animation handling routine there are dozen of function calls before the value gets where it needs to go: A calling B, B calling C, C calling D, D calling E, where the call could have been made from A to E directly. When re-writing video I wasn't even really looking in those intermediate functions, since I was gonna re-write it all anyway, I just made sure the value in question got prepared and converted to expected format and then deleted everything else. Just doing that fixed most of the problems, so I'm optimistic to see improvements in input handling code too once I start deleting it.
>> I am not aware of the specifics of the issues you are dealing with - I didn't realize that MAME had flaws in its audio or video handling that would cause video frame rate jittering or audio buffer underruns (cracking, etc), but if it does and you can fix them, that would be awesome.
<<
1.) Issues related to AUTO frame-skip and hardware too weak to run the game at full speed.
- solution: different frame-skipping and video syncing algorithm
2.) Issues related to impossibility of syncing non 60.00 Hz games with fixed 60fps displays such as LCDs.
-solution: speed up or slow down each game if necessary to fit available display refresh-rate.
Audio issues in both cases are just byproduct, it's because the time from one frame to another gets to vary wildly, too much for audio-stream to catch up, re-sample, re-sync or whatever it is doing. Have no idea how audio in MAME works, fixing video glitches fixed audio hiccups and crackling automatically. In any case it's about "temporal uniformity", you wanna even out turn-around trip time from one frame to another, doesn't really matter if you can push just 30 frames per second, or even 15 only, if it is uniformly distributed in time and synced with the display's refresh rhythm it will sound and appear smooth, smoother in many cases than if frame-rate varied from 50-60fps.
These are not very obvious issues in most cases and with most games, but depending on your hardware configuration and MAME settings some games, particularly scrolling ones, will manifest video imperfections. Audio problems then usually come when you try to smooth the video as neither video syncing nor auto-frame skipping works properly. And sometimes it simply can not work, you can not divide 60 with 57 and get a whole number, so it's simply not possible to run Moon Patrol (57Hz) smoothly at its authentic speed on a fixed 60fps LCD display.
>> More on topic, I agree with everything you wrote about the 34 bits analog input ranges. It's nonsensical. 32 bits would already be overkill - is there any input device for which input ranges of -32678 to +32767 is not sufficient? I would say absolutely not.
<<
Yeah, not a big deal really, just sort of thing that makes you think what else has been wasted and what makes you wanna do the re-write, but the reason in its essence, for me, is really more about aesthetics and principles than it is practical.
>> In libmame I recently collapsed the range down to 16 bits in either direction and scale the results to 17 bits before passing them to MAME. The one part out of 32000 difference in accuracy will never, ever be detectable.
<<
I guess, if it is scaled at the right place, otherwise I'm guessing there is a possibility you could have a problem with centering and dead zone with analog sticks. I'd test it out on Star Wars and maybe also Missile Command & Road Runner. Also spinners that have to return the pointer to exact same position every 360 degrees, you might now have a gap there.
|
|
|
| Sune |
|
Connected
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 5648
|
|
Loc: Lagoa Santa, Brasil
|
|
|
|
Send PM
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: R. Belmont]
#285615 - 05/08/12 11:11 PM
|
|
|
> > Sorry to hear that, I must have missed it. It can't be that bad, he posted
> something
> > in the bin the other day.
>
> The bin is where emulation goes to die
It's much worse than that.
> Also, I know you were involved with the thread in question. Does "gear shifts" ring
> any bells?
It does but I don't remember why I got into that discussion or what I said. If someone was trolling I probably took the bait as usual.
I know you like to push my buttons but please don't pin Derrick's lack of motivation on me, that's ridiculous.
S
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9713
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
[Re: Sune]
#285773 - 05/10/12 12:21 AM
|
|
|
> > Also, I know you were involved with the thread in question. Does "gear shifts" ring
> > any bells?
>
> It does but I don't remember why I got into that discussion or what I said. If
> someone was trolling I probably took the bait as usual.
>
> I know you like to push my buttons but please don't pin Derrick's lack of motivation
> on me, that's ridiculous.
Huh? I pinned Derrick's motivation on that thread, not on you. I simply noted that you had participated in the thread, so you oughta be able to remember it. No placement of blame was intended or implied.
|
|
|
|
Previous 
Index 
Next 
Threaded 
Why are MAME INPUT_ABSOLUTE_{MIN/MAX} 17 bits?
Reply
[Re: 
