Picodrive 1.32


I am impressed at how well this emulator performs at only 200 mhz! This is simply amazing! Fantastic work Notaz! This emulator is near flawless...

Is it possible to make a shortcut in GMenu2x that will launch a game directly, rather than selecting it off of a list once inside the program?

Example: Picodrive.gpe -ROMNAME.zip
 
Notaz has set a new standard for the GP2X and every dev will have a very hard time to develop an emulator with the same compatibility, customizability and as well featured like Picodrive.
Great job Notaz, can' t wait to see what you will do next.
 
notaz said:
shinneri said:
EDIT: Though it is outrageously wonderful, I thought you might like to know that the voice in the intro of Lunar 2 are no longer in correct sync (and used to be). Specifically, it's very severe on the part where Hiro falls and gets chased by fire monsters.
It worked correctly in 1.31 or earlier? Might be because the change in timing, might need "better sync" now..

It did work correctly before, but that fixes it. And I don't even notice a performance hit with "better sync" on. :)
 
Last edited by a moderator:
Damn notaz, from the sound of it, it seems you have accomplished near flawless genesis emulation; something the psp is not even close to (I find the psp genesis emu to pale in comparison to Dr.MD on my gp32!).

superb work! I wish I could see it first hand :)
 
notaz said:
DaveC said:
I am suprised pixel averaged horizontal scale doesn't slow down much.
Well it is in hand-written asm, done while drawing pixels, so it shouldn't be too slow.


That is pretty amazing. It does work very well. I am not a big fan of stretching as you may know but this looks so good that I may use it once in awhile :eek:

Honestly most scaling and filtering looks like crap. This seems much better, it almost looks 1:1 in sharpness. Bi-linear filtering seems to look more blurry in comparison.

I think I know why this looks good. It only averages the pixel columns it stretches, it leaves the 1:1 pixels as-is and doesn't blur those. It also only does it in one direction and leaves the vertical alone. It only averages the bare minimum that it needs, doesn't go over-board with filtering. Bi-linear in contrast just seems to blend everything no matter what making it look more blurry, it is not as selective. Or it could be that everytime I have seen that used it does it in both directions, not sure. This looks almost TV like too as TVs had the same effect. TVs never averaged vertically scan line to scan line, but tended to in the horizontal direction like this, pretty similar in effect.

This probably wouldn't look as good if it was done in both directions, it has limits. But for this it looks as good as it possibly can for scaling. The speed is amazing. Thanks again for this, quite a nice piece of work.
 
Last edited by a moderator:
DaveC said:
That is pretty amazing. It does work very well. I am not a big fan of stretching as you may know but this looks so good that I may use it once in awhile :eek:
Strange, the algorithm is very trivial:
It basically takes 4 pixels and makes 5. Repeating this 64 times you get 256->320 enlargement.

pixels before:
| 1 | 2 | 3 | 4 |
pixels after:
| 1 | (3/4 * 1) + (1/4 * 2) | (1/2 * 2) + (1/2 * 3) | (1/4 * 3) + (3/4 * 4) | 4 |

Have no idea what it could be called, probably just trivial pixel averaging, I thought of it myself :)
The 1/2, 1/4 and 3/4 multiplications can be achieved without float arithmetic by simply shifting, so they are very cheap.
This can be easily applied for the SNES emus, but it would be slower there, because it would need to be done after the whole image is rendered, not while it is being rendered (what I do in PD).

Edit: oops, I messed the formula, the one actually used is which ledro wrote below
 
Last edited by a moderator:
Wouldn't the following be better?
| 1 | (1/4 * 1) + (3/4 * 2) | (1/2 * 2) + (1/2 * 3) | (3/4 * 3) + (1/4 * 4) | 4 |

this way every pixel would weigh as much
pixel 1: 5/4
pixel 2: 5/4
pixel 3: 5/4
pixel 4: 5/4

as opposed to
pixel 1: 7/4
pixel 2: 3/4
pixel 3: 3/4
pixel 4: 7/4
 
ledro said:
Wouldn't the following be better?
| 1 | (1/4 * 1) + (3/4 * 2) | (1/2 * 2) + (1/2 * 3) | (3/4 * 3) + (1/4 * 4) | 4 |

this way every pixel would weigh as much
pixel 1: 5/4
pixel 2: 5/4
pixel 3: 5/4
pixel 4: 5/4

as opposed to
pixel 1: 7/4
pixel 2: 3/4
pixel 3: 3/4
pixel 4: 7/4
The effect that Notaz is trying to do with this is to make the pixels "appear" at the in-between off-center pixel location they would be if it were not a fixed pixel device. Hard to explain for me, but this would mean making one pixel out of two adjacent ones a bit "stronger" than the one next to it. This kind of gives the illusion that the pixel is offset a half of a pixel in between the physical ones. To do that some would need to be weighted different or it would just look like the standard ugly blocky scaling.
 
Last edited by a moderator:
Think i found a tiny little bug. Before (v1.31) the max my volume would go up to was 90, i took this to be because i have volume limit turned on in my firmware. However it would appear that picodrive now ignores this volume limitation and will go upto volume level 99.
 
DaveC said:
ledro said:
Wouldn't the following be better?
| 1 | (1/4 * 1) + (3/4 * 2) | (1/2 * 2) + (1/2 * 3) | (3/4 * 3) + (1/4 * 4) | 4 |

this way every pixel would weigh as much
pixel 1: 5/4
pixel 2: 5/4
pixel 3: 5/4
pixel 4: 5/4

as opposed to
pixel 1: 7/4
pixel 2: 3/4
pixel 3: 3/4
pixel 4: 7/4
The effect that Notaz is trying to do with this is to make the pixels "appear" at the in-between off-center pixel location they would be if it were not a fixed pixel device. Hard to explain for me, but this would mean making one pixel out of two adjacent ones a bit "stronger" than the one next to it. This kind of gives the illusion that the pixel is offset a half of a pixel in between the physical ones. To do that some would need to be weighted different or it would just look like the standard ugly blocky scaling.


That makes kinda sense. It propably gives you the nice old TV feeling. I have not tried out the latest version of pico drive, I'm curious. I'm definitly going to try it out tonight.
Great work Notaz!
 
Last edited by a moderator:
notaz said:
This can be easily applied for the SNES emus, but it would be slower there, because it would need to be done after the whole image is rendered, not while it is being rendered (what I do in PD).
That would be great. :)

Yorper said:
Think i found a tiny little bug. Before (v1.31) the max my volume would go up to was 90, i took this to be because i have volume limit turned on in my firmware. However it would appear that picodrive now ignores this volume limitation and will go upto volume level 99.
No, it works that way for everybody--limiter or not. Mine's off and it does the same thing. ;)
 
Last edited by a moderator:
shinneri said:
Yorper said:
Think i found a tiny little bug. Before (v1.31) the max my volume would go up to was 90, i took this to be because i have volume limit turned on in my firmware. However it would appear that picodrive now ignores this volume limitation and will go upto volume level 99.
No, it works that way for everybody--limiter or not. Mine's off and it does the same thing. ;)


Aah ok then, well i wasnt sure that why i said i thought. Maybe make it limit volume to 75 then if volume limit is on. But previous versions limited the volume to 90.
 
Last edited by a moderator:
ledro said:
Wouldn't the following be better?
| 1 | (1/4 * 1) + (3/4 * 2) | (1/2 * 2) + (1/2 * 3) | (3/4 * 3) + (1/4 * 4) | 4 |
Yes this is the one actually used (I just made a mistake in that post).

Yorper said:
Think i found a tiny little bug. Before (v1.31) the max my volume would go up to was 90, i took this to be because i have volume limit turned on in my firmware. However it would appear that picodrive now ignores this volume limitation and will go upto volume level 99.
Well I intentionally upped the limit because some games do not distort at 99 volume, and this is better in noisy environments. And yes it is ignoring firmware's volume limiter (and always did).
 
Last edited by a moderator:
notaz said:
Well I intentionally upped the limit because some games do not distort at 99 volume, and this is better in noisy environments. And yes it is ignoring firmware's volume limiter (and always did).
Any chance you could make the volume always start at say 50, then we can up it as we like. Mine always seems to start maxed out now and not only does that blast my ears but it sounds totally god aweful too. So if it atleast starts at 50 then my ears and many others ears will be saved.
 
Last edited by a moderator:
Yorper said:
Any chance you could make the volume always start at say 50, then we can up it as we like. Mine always seems to start maxed out now and not only does that blast my ears but it sounds totally god aweful too. So if it atleast starts at 50 then my ears and many others ears will be saved.
Volume control is part of main or game specific config (game specific one has higher priority), so set it to whatever you want when ingame and save the config.
 
Last edited by a moderator:
Micket said:
I just finished Snatcher!
Amazing work, worked flawlessly throughout the whole game, no overclock.
I'm just playing Snatcher now. It's really great playing it on the GP2X.
I showed my partner the title screen to the first chapter "SNATCH" and she looked at me asked me what the hell I was playing... :p
 
Last edited by a moderator:
Well done on the latest release. Just played a bit of Road Avenger and Jaguar XJ200. Nice.

Ultimate Mortal Kombat 3 doesn't work properly anymore. The gameplay appear to jerk when in the matches even though the fps counter shows 60/60. It didn't do this before (pre version 1).

Also something doesn't seem right about Super Hang On. It may just be me, but it seems to 'feel' slightly jerkier and slightly slower than pre version 1. As I said though, it may be just me.
 
Back
Top