Ant_222 wrote:Solanacean, please replace the function ssPsEndUpdate in sdlmain.cpp with the one attached and test again.
Unfortunately, the glitch is still there.
Ant_222 wrote:Solanacean, please replace the function ssPsEndUpdate in sdlmain.cpp with the one attached and test again.
pix_out.pixels += 1;
A B G R
b g r
Ant_222 wrote:If so, can you please delete the conditional compilation and test with.
- Code: Select all
pix_out.pixels += 1;
machine=ega
Ant_222 wrote:Can you try it with?
- Code: Select all
machine=ega
I have reproduced this by exactly the opposite modification (decrement by one). Please, try again with the attached function.Solanacean wrote:The build with the conditional compilation directives commented out: no blue strips.
Ant_222 wrote:I have reproduced this by exactly the opposite modification (decrement by one). Please, try again with the attached function.Solanacean wrote:The build with the conditional compilation directives commented out: no blue strips.
Ant_222 wrote:Can you please replace 3 with 4 in the rgb_32_fmt structures as shown in formats.cpp and restore the function ssPsEndUpdate.cpp to its original state (attached), and try again. No need to test several devices, just test with ega.
EDIT:This should help with surfacepp and surfacenb, which copy pixels as memory blocks, but not with [i]surfacenp/i], which extracts individual channel values for interpolation.
Thanks, but surfacenp doesn't work and the other two modes are potentially slower because instead of copying three bytes I know copy four. All in all, this is only a temporary fix.Solanacean wrote:You're awesome! :happy: Everything looks fine now!
Ant_222 wrote:Available area is the maximum size of the output image. In windowed mode it is the window dimensions and in full-screen mode it is your full-screen resolution. Both are specified in the DOSBox config file. 320x200 is the resolution of the graphical mode of the game being emulated and 1.20 is its PAR, as reported by DOSBox. [4.0 x 5.0] shows the horizontal and vertical scaling factors that my patch applies. The final entry contains the resulting image resolution, 1280x1000:and PAR:
- Code: Select all
320 * 4.0 = 1280
200 * 5.0 = 1000Each pixel of the game is represented as a 4x5 rectangle and therefore has a PAR of 1.25. Since 1.25 is within 4.1% of 1.20, the aspect ratio of the scaled image is nearly perfect, and the difference is barely perceptible. If the available area were at least 1600x1200, then you would have a perfect PAR:
- Code: Select all
5.0 / 4.0 = 1.25
- Code: Select all
320 * 5.0 = 1600
200 * 6.0 = 1200
5.0 / 4.0 = 1.2 ( = source PAR)
Since 1.25 is within 4.1% of 1.20, the aspect ratio of the scaled image is nearly perfect, and the difference is barely perceptible.
Available area: 2560x1440
Scaling: 640x400 (1.20) --[3.0 x 3.0]--> 1920x1200 (1.00)
No. Since the correct value is 1.20, the ratio should be inverted:lukeman3000 wrote:I do have a couple more questions, something that I missed the first time around. In the quote above, you state1. When you say it's within 4.1%, I assume you're doing the following: (1.25 - 1.20) / 1.25 = 0.04 or 4%. Correct?Since 1.25 is within 4.1% of 1.20, the aspect ratio of the scaled image is nearly perfect, and the difference is barely perceptible.
(1.25 - 1.20) / 1.20 = 1/24 ~ 4.1%
This is the exact percentage of error for that case, so the value is not arbitrary. This error, of one part in twenty-four, is so small as to be hardly noticeable.2. You say "since 1.25 is within 4.1% of 1.20" -- why, specifically, do you say 4.1%? Is this an arbitrary percentage, or does it have some meaning?
Hard to say because I don't yet know whence this slow-down comes. It might be due to an inefficient initial filling of the screen with black pixels. I am on vacation now and have no access to the PC with my build environment.On an unrelated topic, I notice that launching games with surfacepp takes considerably longer (a few seconds) than if I'm using one of the other render modes. Is there any chance that as you continue to develop the patch, this time may decrease?
Yes, it may, for the current algorithm does not use either GPU or multithreading. In DOSBox 2.0 it could be implemented using the GPU and should be (theoretically) fast enough for most games is not for all. You can test the performance of the current version and post the results here.And will using this patch potentially make it difficult to play newer, more demanding games, or does the delay only occur when launching the game and does not affect the game's performance once it's being played?
This behavior is correct. In order to play Space Quest V in the original aspect ration you would need a resolution of at least:4. Also, finally, I seem to be running into some issues with pixel perfect. For example, with Space Quest V, stdout.txt says the following:
- Code: Select all
Available area: 2560x1440
Scaling: 640x400 (1.20) --[3.0 x 3.0]--> 1920x1200 (1.00)
This is running in full screen mode. So, if I'm doing this right, I'm looking at a difference of about 16% (1.20 compared to 1.0), which doesn't seem that great.
3200 by 2400
1.20 = 6/5
640*5 = 3200
400*6 = 2400
No, as shown above. Fullscreen will give you the largest available area and therefore the best possible rendering on your system. It may not always be ideal.I thought that running in full screen was essentially guaranteed to net me a perfect pixel aspect ratio?
This is largely a subjective question. Try to compare how it feels in pixel-perfect mode and with in one of the modes that preserve aspect ratio, and choose whichever you like best.So if not, should I still be using surfacepp in these kinds of cases, or should I consider a different render mode, and if so, for what reason?
I have never consciously analysed it. It might even vary with games. Suffice it to note that before I had made the patch, I prefered playing Alone in the Dark in pixel-perfect mode without aspect correction (surface, normal3x) rather than with the correct aspect ratio but with distorted pixels (opengl, openglnb, overlay). This gives an error of 17%. It is large but not as annoying as the alternatives I had. Of course, with the patch AITD looks gorgeous on anything starting from 1280x1000 (for the nearly-perfect 4:5 correction).lukeman3000 wrote:Thank you. What aspect error might be large enough for you to consider using a different render mode - 10%, 20%?
Ant_222 wrote:I have never consciously analysed it. It might even vary with games. Suffice it to note that before I had made the patch, I prefered playing Alone in the Dark in pixel-perfect mode without aspect correction (surface, normal3x) rather than with the correct aspect ratio but with distorted pixels (opengl, openglnb, overlay). This gives an error of 17%. It is large but not as annoying as the alternatives I had. Of course, with the patch AITD looks gorgeous on anything starting from 1280x1000 (for the nearly-perfect 4:5 correction).lukeman3000 wrote:Thank you. What aspect error might be large enough for you to consider using a different render mode - 10%, 20%?
In the first case the patch had an available area of 1152 x 864 which allowed for an imperfect aspect-ratio correction of 3:4 instead of the perfect 5:6. This resulted in the following error:lukeman3000 wrote:Ant, another question:
When playing with resolution and surfacepp, I get two very different results from a seemingly small difference in PAR (about 5.8%).
The calculator in each image shows the difference between the game's native PAR and the rendered PAR (e.g., ((1.2 - 1.0) / 1.2)*100 = 16%. So, 16% vs 10.8% is about 5.8%, and yet the aspect ratio of the two images seem to have a much greater difference than 5.8%... What am I missing here? Or is that 5.8% making that much of a difference?
(4/3-6/5) / (6/5) = 1/9 ~ 11%
(1 - 6/5) / (6/5) = - 1/6 ~ - 16%
11% - (-16%) = 27%
They are linked via resolution:Is it such that I'm comparing two different things? In other words, pixel aspect ratio and aspect ratio aren't intrinsically linked, so even though the difference in PAR is only 5.8%, for some reason the difference in aspect ratio is much greater.. ?
AR = (1/PAR) * Width/Height
Original: 320/200 * (1/(6/5)) = 4/3 ~ 1.33 (CRT)
Case I: 320/200 * (1/1) = 8/5 = 1.60 (wide)
Case II: 320/200 * (1/(4/3)) = 6/5 = 1.20 (tall)
(But 1.20 is closer to 1.33 than 1.60)
Users browsing this forum: No registered users and 4 guests