reiboul said:I always supposed so, because I err... *found* it in a file, with roms, on an infamous GP2X siteRivroner said:h34r: How do I check?
on windows: use md5sums or md5check
From what I remember of notaz's explanation of the algorithm, it doesn't seem overly difficult to apply the same thing vertically.Tobriand said:Not sure, but I imagine picodrive's software scaling only works horizontally. Leastways, the way it's designed would only work horizontally... it's also scaling a very specific ammount to create an illusion of wider pixels (as opposed to a larger space). That's not necessarily a problem, but you'd need to work out what factor scaling was worth doing - and it would still be horizontal only. At least, it would if the algorithm was to remain trivial.
Or maybe I'm wrong - insert not a coder disclaimer here
Edit:notaz said: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
Scaling vertically is much more expensive than scaling horizontally because these kinds of renderers usually work a scanline at a time, which go in the horizontal direction. Even if they didn't, you'd be increasing the workload by a good 4x anyway performing an algorithm like this over a square instead of a line. And while it's not that computationally expensive to generate these intermediate colors it's far from free.Tobriand said:
Not all games can benefit from those, in fact, less than half probably. The name has to be the same as the one in the ROM's header, it has nothing to do with the filename if that's what you mean.DaveC said:
Games with idle loops will always run better with them marked. This may range from a little better to a lot better. Whether or not a game can run fullspeed with them disabled is another story altogether.DaveC said:
It could be bugs in the autoframeskip. Try manual and see what happens, or try lowering the skip tolerance on the autoframeskip. It's possible that the game is actually doing something though.DaveC said:
Exophase said:
rokdcasbah said:reiboul said:I always supposed so, because I err... *found* it in a file, with roms, on an infamous GP2X siteRivroner said:
on windows: use md5sums or md5check
I use filealyzer http://www.safer-networking.org/en/filealyzer/index.html
It lets you right-click on any file and "analyze" it, including an MD5 hash SHA1 and CRC-32 all at once, besides letting you see what the program gets its hooks in when it runs
Sorry for the OT.
I tried the manual FS it doesn't skip then. It could be that the game is doing something but it doesn't seem so. In my test game Pacman collection I test it at the part where you select the type of game. There is nothing going on except for a sinus scroll in the background with music playing. It doesn't seem related to the music (does it in-game too). It will skip a frame or two, then a couple more then get worse before going back to normal. Seems to look like below where periods are skipped frames. It seems pretty rhythmatic.Exophase said:
imhotep said:
