Mjlink
ithic.com
^
Thank you sir!
Any chance you'll be on the new forums? Both of you Dave & Steve?
Peace & Pandora,
Link
Thank you sir!
Any chance you'll be on the new forums? Both of you Dave & Steve?
Peace & Pandora,
Link
It's a little more complicated than that. For many games, the largest scale that will fit in both axes is 1:1. This isn't so much of a problem if your native resolution is 320x240 like on the Wiz; you just render it and live with a bit of a border and maybe some minor clipping. On the Pandora you however end up with a tiny image and massive borders. What it therefore does is calculate the integer scale which best matches the physical screen, based on the diagonal measurement. This may be larger or smaller than the actual screen, so borders and/or clipping can occur. If the calculated scale results in clipping in both axes, it backs off by one. It's not an ideal algorithm and the non-4:3 aspect ratio doesn't help, but it does work as designed and provides a reasonable compromise for the games I tested. I can add a "never clip" mode, but I don't think it would make a good default.DaveC said:EDIT: Ok now I know what it is doing. It is using the tallest hight and integering that. So in this case it is taking the 256 image height (which is now landscape on the Pandora screen) and saying "hey 256 x 3 will fit into 800" But since the Pandora screen is not 4:3 the 224 x3 doesn't fit. You need to use the vertical oriented game WIDTH value (smaller number) when determining the integer that will fit into 480.
To me using a diagonal measurement makes little sense especially since we have a widescreen and no MAME games that this version runs do.SteveM said:It's a little more complicated than that. For many games, the largest scale that will fit in both axes is 1:1. This isn't so much of a problem if your native resolution is 320x240 like on the Wiz; you just render it and live with a bit of a border and maybe some minor clipping. On the Pandora you however end up with a tiny image and massive borders. What it therefore does is calculate the integer scale which best matches the physical screen, based on the diagonal measurement. This may be larger or smaller than the actual screen, so borders and/or clipping can occur. If the calculated scale results in clipping in both axes, it backs off by one. It's not an ideal algorithm and the non-4:3 aspect ratio doesn't help, but it does work as designed and provides a reasonable compromise for the games I tested. I can add a "never clip" mode, but I don't think it would make a good default.DaveC said:EDIT: Ok now I know what it is doing. It is using the tallest hight and integering that. So in this case it is taking the 256 image height (which is now landscape on the Pandora screen) and saying "hey 256 x 3 will fit into 800" But since the Pandora screen is not 4:3 the 224 x3 doesn't fit. You need to use the vertical oriented game WIDTH value (smaller number) when determining the integer that will fit into 480.
Maybe not be wide-screen, but many games are 384x224 (scales nicely to 768x448) which is a lot closer to the Pandora's native aspect ratio than it is to 4:3. I agree that the diagonal measurement is not ideal, though. I could use some kind of threshold system (e.g. allow clipping if less than 10%) but then I'd also have people complaining that the thresholds were wrong for some specific game.DaveC said:To me using a diagonal measurement makes little sense especially since we have a widescreen and no MAME games that this version runs do.
Making it fit is easy; I've already said I can add an option for that. But using this approach for games like R-Type (224x256) results in a tiny image and a lot of wasted screen.What would make much more sense would to be to use the width (smaller) number in pixels of the arcade game, then determine how many times that would go into 480 then determine the integer (and probably 99% of the time it would be 2X unless it is vector). Since if you make the width fit, the height (800PX) will ALWAYS fit that is all you need to be concerned with. There would never be a case where an integer value that fits the narrow dimension of the screen would clip in the 800PX direction.
And in your 384x224 example with the method I suggested it automatically would give 768x448 as you would integer double the 224 width and you would get that result. As I said if you did it using the narrow number (arcade width vertical, height horizontal) the size in the 800 direction would automatically fall out. I don't know of any game MAME4all suports that is native resolution of over 400 one direction and less than 240 the other.SteveM said:Maybe not be wide-screen, but many games are 384x224 (scales nicely to 768x448) which is a lot closer to the Pandora's native aspect ratio than it is to 4:3. I agree that the diagonal measurement is not ideal, though. I could use some kind of threshold system (e.g. allow clipping if less than 10%) but then I'd also have people complaining that the thresholds were wrong for some specific game.
Making it fit is easy; I've already said I can add an option for that. But using this approach for games like R-Type (224x256) results in a tiny image and a lot of wasted screen.
R-Type is 256 lines (I typoed on the horizontal figure) and this at 1:1 really is tiny. This is what I'm trying to avoid.DaveC said:Your R-type example 256x224 would double to 500x448, hardly "tiny".
There are allot of other modes in MAME where the screen IS tiny like vertical games not played rotated, vector games etc. Ok so you have a border on the sides as expected, but of course you will for all of these because none were widescreen. The object is to get the largest integer size you can while fitting everything in, no cropping. The object of this mode was not: must fill screen completely no matter what. I guess this is where your thinking and mine are opposite. If you want full screen no matter what then you would use one of the fractional modes and filter it.
I tried Donkey Kong rotated integer and it was totally unplayable cropped off and I would expect most others to be the same. What I was expecting, and was the whole point of this mode, was to get it unfiltered and have it integer to 448x500 so it is as large as it can be while still looking good unfiltered (have to use Notaz script for now). I don't know of anyone who would want to play with a good chunk of the screen cut off.
SteveM said:R-Type is 256 lines (I typoed on the horizontal figure) and this at 1:1 really is tiny. This is what I'm trying to avoid.
We are talking about two different modes. I've explained the object of the one that's in there, and it works as designed. Your mode has an entirely different goal but I acknowledge its usefulness and have said I can add it.
Don't think so. Could be hidden in the menu somewhere but I've never come across it.jonlad1 said:Oooh, forgot to ask, are saves states implemented in MAME4ALL?
No plans just now but if something was ported it's be easy enough to plug in. The current menu is actually a front end too; the MAME executable is completely separate and so can be run from anywhere. I thought about porting my own FE but there's a lot of old-style OpenGL in there and I'm not sure how it'd perform on the Pandora.jumpman said:Do you have any plans to add in a Mame frontend? You know so when you select a game, you can see the game artwork and whatnot, that would be a very cool addition.
Really not necessary, but I may set something up as it gets "less beta". I'm not in this for money but it would of course be cool if donations would cover the occasional SD card or whatever.Also, do you have a donation link? I would love to throw you some funds for your hard work, it's greatly appreciated.
Is the source available? FinalBurn Alpha would be nice too, eh? ;-) No-one working on either of these yet?Please, keep up the good work. Maybe you can port over the CPS2/Capex emu, seeing how good you did on this one, just a thought!
Yes, I will be adding this. The integer mode was included in anticipation of the nearest neighbour filter.DaveC said:Also now that Notaz allows the filter to be toggled on/off could a line in the menu be added for filter on/off and be saved per game like the other options? This is the main reason to have an integer mode at all is to do an integer mode and nearest neighbor for sharpness. Right now as everything is filtered there is almost no point to integer as it looks pretty much the same as fractional with the filter on both.
Hmm... I thought this might have been fixed already but I never tried it. Will have to dig out Asteroids or something and have a look.Do you think a way to run vector games bigger than a post stamp is going to be added? Talk about "tiny"
Yeah, never tested that either. I don't think any of my changes would have affected it though. If you're following the below and it still doesn't work, let me know and I'll look into it. The samples directory should be in appdata.Also samples are not working unless i screwed something up.
The sound samples are used to get complete sound in some of the oldest games.
They are placed into the 'samples' directory compressed into ZIP files.
The directory and the ZIP files are named using low case!.
The sound samples collection can be downloaded in the following link:
http://dl.openhandhelds.org/cgi-bin/gp2x.cgi?0,0,0,0,5,2511
You can also use "clrmame.dat" file with ClrMAME Pro utility to get the samples pack.
I ended up chopping out the separate buffers and replacing them with one big one. This made it easier (for me) to follow where I should be writing to and reading from. It's all SDL now, so a bit easier to digest. The current PND does however have a potential buffer overrun but this is (hopefully) fixed in the code already.Hitnrun said:So you figured out the sound problem? Nice! Was it a buffer problem, or you completly rewrote the audio parts of the library?
Strange if this doesn't work - I've not touched any of that code. I'd like to get rid of these key combos though anyway as we have plenty of keys just to use 2,3,4 and 6,7,8 like the big MAMEs do.jonlad1 said:When playing games with four players (TMNT, Simpsons) you can play as other characters with right+select (Player 3 for example) to add coin and right+Start to start the game as player 3.
This doesnt seem to be working for me. Am I doing this correctly?
SteveM said:I ended up chopping out the separate buffers and replacing them with one big one. This made it easier (for me) to follow where I should be writing to and reading from. It's all SDL now, so a bit easier to digest. The current PND does however have a potential buffer overrun but this is (hopefully) fixed in the code already.Hitnrun said:So you figured out the sound problem? Nice! Was it a buffer problem, or you completly rewrote the audio parts of the library?
(I had a look if the same approach would work on PocketSNES, but the sound code in the emulation bits assumes separate buffers so it would take a bit of extra work. So if you're looking for something to do, the current code is here ;-)
Strange if this doesn't work - I've not touched any of that code. I'd like to get rid of these key combos though anyway as we have plenty of keys just to use 2,3,4 and 6,7,8 like the big MAMEs do.jonlad1 said:When playing games with four players (TMNT, Simpsons) you can play as other characters with right+select (Player 3 for example) to add coin and right+Start to start the game as player 3.
This doesnt seem to be working for me. Am I doing this correctly?