VOGONS

Common searches


Reply 380 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
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.

Attachments

Reply 381 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

If so, can you please delete the conditional compilation and test with

pix_out.pixels += 1;

.
EDIT: The bug is caused by this offset in the reading of pixel values:

A B G R
b g r

i.e. alpha channel (random value) is read as blue, blue as green, and green as red. This is why the screenshots have no blue color except in (semi)random blue stripes and why white is shown as yellow (g+r). Once you help me to confirm that this is the actual problem, I will find a way to treat pixels in a format-independent way.

Reply 382 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
Ant_222 wrote:
If so, can you please delete the conditional compilation and test with […]
Show full quote

If so, can you please delete the conditional compilation and test with

pix_out.pixels += 1;

.

Now it crashes with a segmentation fault.

Reply 384 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
Ant_222 wrote:
Can you try it with […]
Show full quote

Can you try it with

machine=ega

?

The build with the conditional compilation directives commented out: no blue strips.

Attachments

Reply 385 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

Thank you very much. It is very late now, so I must to bed. Tomorrow I shall give a code to output the properties of sdl.surface->format: Rshift and Bshift. There must be some difference in the RGB(A) layout between our machines. If you can look at them yourself, then please do. This is a global variable available from ssPsEndUpdate() and initialized by the time it executes.

Reply 386 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Solanacean wrote:

The build with the conditional compilation directives commented out: no blue strips.

I have reproduced this by exactly the opposite modification (decrement by one). Please, try again with the attached function.

Attachments

  • Filename
    ssPsEndUpdate.cpp
    File size
    874 Bytes
    Downloads
    50 downloads
    File license
    Fair use/fair dealing exception

Reply 387 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
Ant_222 wrote:
Solanacean wrote:

The build with the conditional compilation directives commented out: no blue strips.

I have reproduced this by exactly the opposite modification (decrement by one). Please, try again with the attached function.

Attachments

Reply 389 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

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 surfacenp/i], which extracts individual channel values for interpolation.

Attachments

  • Filename
    ssPsEndUpdate.cpp
    File size
    561 Bytes
    Downloads
    62 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    formats.cpp
    File size
    187 Bytes
    Downloads
    47 downloads
    File license
    Fair use/fair dealing exception

Reply 390 of 733, by Solanacean

User metadata
Rank Newbie
Rank
Newbie
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 surfacenp/i], which extracts individual channel values for interpolation.


You're awesome! 😀 Everything looks fine now!

Attachments

Reply 391 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Solanacean wrote:

You're awesome! :happy: Everything looks fine now!

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.

Reply 392 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member
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 […]
Show full quote

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:

320 * 4.0 = 1280
200 * 5.0 = 1000

and PAR:

5.0 / 4.0 = 1.25

Each 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:

320 * 5.0 = 1600
200 * 6.0 = 1200
5.0 / 4.0 = 1.2 ( = source PAR)

Hi Ant -

I revisited this thread tonight to reacquaint myself with the pixel perfect patch; I just wanted to say thanks for your excellent and detailed explanations; they have been very interesting to read.

I do have a couple more questions, something that I missed the first time around. In the quote above, you state

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. 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?

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?

3. 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? 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?

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:

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. I thought that running in full screen was essentially guaranteed to net me a perfect pixel aspect ratio? 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?

Reply 393 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
lukeman3000 wrote:

I do have a couple more questions, something that I missed the first time around. In the quote above, you state

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. 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?

No. Since the correct value is 1.20, the ratio should be inverted:

(1.25 - 1.20) / 1.20 = 1/24 ~ 4.1%

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?

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.

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?

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.

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?

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.

4. Also, finally, I seem to be running into some issues with pixel perfect. For example, with Space Quest V, stdout.txt says the […]
Show full quote

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:

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.

This behavior is correct. In order to play Space Quest V in the original aspect ration you would need a resolution of at least:

3200 by 2400
1.20 = 6/5
640*5 = 3200
400*6 = 2400

I thought that running in full screen was essentially guaranteed to net me a perfect pixel aspect ratio?

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.

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?

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.

I am strongly in favor of pixel-perfect display and use it unless aspect error is so large that it outweighs the disharmony of blurry or irregular pixels.

Reply 395 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
lukeman3000 wrote:

Thank you. What aspect error might be large enough for you to consider using a different render mode - 10%, 20%?

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).

Reply 396 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member
Ant_222 wrote:
lukeman3000 wrote:

Thank you. What aspect error might be large enough for you to consider using a different render mode - 10%, 20%?

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).

I see. With SQV, I'm looking at an aspect error of about 20%... Guess I'll just have to compare the image from a couple different render modes and see which one I prefer.

Reply 397 of 733, by lukeman3000

User metadata
Rank Member
Rank
Member

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?

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.. ?

Reply 398 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
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?

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:

(4/3-6/5) / (6/5) = 1/9 ~ 11%

In the second case the smaller available area of 1024x768 was insufficient for any correction whatsoever, so the patch displayed the game with unity PAR and with an aspect-ratio error of

(1 - 6/5) / (6/5) = - 1/6 ~ - 16%

This value is negative because the actual PAR is smaller than the correct one. If you subtract the errors respecting their signs, you will have:

11% - (-16%) = 27%

which is a large difference (of almost one third).

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.. ?

They are linked via resolution:

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)

Your mistake was in ignoring the sign of the error.

Reply 399 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie

Does anybody use surfacenp or surfacenb? The latter is already implemented in openglnb, so the question is whether opengl is available on the majority of systems. surfacenp is very slow and becomes indistinguishable from surfacenb/openglnb as the the output resolution increases. Would anybody miss these modes if I removed them?