VOGONS

Common searches


Reply 60 of 733, by Scali

User metadata
Rank l33t
Rank
l33t
Ant_222 wrote:

Can such a window be technically called a separate graphical mode?

Yes, I suppose so.

Ant_222 wrote:

I thought it would still be a 320x200 mode with the software writing within a 200x200 subregion?

Not necessarily. You can reprogram CGA/EGA/VGA/Hercules so that a scanline is actually just 200 pixels wide in memory.
The advantage is that you aren't wasting any memory, so you can use it for offscreen buffering.
I use this in the sprite part for 8088 MPH, to make fast vertical scrolling and double-buffering possible.

Ant_222 wrote:

Is it the reason that DOSBox reports a unity aspect ratio for 256x224 Flashback—does that game use a "window"?

I don't know how Flashback works exactly, but I suspect it uses a 320x240 mode, reprogrammed to a smaller window, because if it was a regular 320x240 mode, I don't see how DOSBox would be able to know it only uses 256x224 pixels of the total screen.
DOSBox calculates various things, including refresh rate, from how the CRTC registers are programmed.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 61 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

I don't know how Flashback works exactly, but I suspect it uses a 320x240 mode, reprogrammed to a smaller window, because if it was a regular 320x240 mode, I don't see how DOSBox would be able to know it only uses 256x224 pixels of the total screen.

So it was foolish on my part to suspect a regular 256x224 mode? Ok, that answers why I should respect the ratio that DOSBox gives me instead of calculating it myself.

Reply 62 of 733, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Bug.

with aspect=true:
640x400 doesn't display properly, it stretches to full area of my 1920x1200 screen where it should be 4:3.

320x200 displayed as 4:3, as it should.
640x480 aspect=true, is a smaller window with black borders around the image, woks in 4:3.

Anyway, I want 4:3 with top and bottom touching the screen edge at all times so super-scaled and interpolated is still the way for me.


my important / useful posts are here

Reply 63 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote:

Bug.
with aspect=true:
640x400 doesn't display properly, it stretches to full area of my 1920x1200 screen where it should be 4:3.

aspect = true activates vertical nearest-neighbor scaling. My algoritthm is not supposed to be used with aspect=true because it takes care of the aspect ratio itself. Edit: You don't want a superposition of two aspect-ratio corrections—one by DOSBox's nearest-neighbor interpolation and one by my algorithm.
Edit:

James-F wrote:

Anyway, I want 4:3 with top and bottom touching the screen edge at all times so super-scaled and interpolated is still the way for me.

Edit: This is exactly the way my algorithm will display a 320x200 game on your 1920x1200 dispaly—which you can check with a ruler,—although in general it is a matter of tradeoffs. You seem to prefer maximum size with imperfect scaling to a perfetly scaled image of a smaller size.

Reply 65 of 733, by Scali

User metadata
Rank l33t
Rank
l33t
James-F wrote:

Anyway, I want 4:3 with top and bottom touching the screen edge at all times so super-scaled and interpolated is still the way for me.

That is not how it is supposed to look though.
Sadly DOSBox does not support the border. But on real CRTs there was always a border area around the visible area. the reason for that is that the visible area was square, and the screen was not, the sides were a bit rounded. So you'd center the display so the square area would be fully visible.
As a result, you'd have visible border around the image, and this border could be set to any background colour. In DOSBox you cannot see this, but various games make use of it. Eg Wolf3D and DOOM will not only flash the screen red when you get hit, but also the border. This effect is completely lost on DOSBox.
Also, you could actually reprogram the visible window so that you'd get 'overscan', and actually draw in text or graphics right into this border (Trixter's CGA compatiblity tester does this).

So you shouldn't make the top and bottom of the visible area touch the screen, that's not how CGA/EGA/VGA/Hercules are supposed to work. You should have a border of arbitrary size around the visible area (adjusting monitors wasn't an exact science, the user had width/height and horizontal/vertical center controls to adjust the screen to their liking, and choose their own preferred ratio between visible window and border).

In this video you can see it, if you look closely: https://youtu.be/LM1HYM_qSsw
Eg, everytime something is selected in the menu, you see it go to red, and then fade back. You can see a small area of red outside the visible menu, which goes back to black, that's your border background colour.
In DOSBox the menu fills the whole window, no border is visible.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 66 of 733, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Isn't that part of the front/back porch part of the sync signal?
Back in the 90's I had the image touch the border of the CRT, it had sharp corners, LG flatron.


my important / useful posts are here

Reply 67 of 733, by Scali

User metadata
Rank l33t
Rank
l33t
James-F wrote:

Isn't that part of the front/back porch part of the sync signal?
Back in the 90's I had the image touch the border of the CRT, it had sharp corners, LG flatron.

Not really.
In fact, on VGA you can program how much of the border uses the background colour (which is why you still see black around the red flashing border in Wolf3D). On CGA/EGA the colour is hardwired, but it is still part of the active video signal ('overscan').
On systems like the C64 and Amiga you can actually draw graphics in these border areas, if you like. On PC, the timing and memory are too restricted, so you can't pull it off that well.

Anyway, later CRTs and LCDs aren't representative of CGA/EGA/VGA/Hercules, which were 80s technology, when CRTs were still quite curved.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 68 of 733, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

https://en.wikipedia.org/wiki/Video_Graphics_ … #Signal_timings
http://easymamecab.mameworld.info/html/monitor6.htm

The VGA signal has horizontal and vertical parameters called: total pixels, active, pixels, front & back porches, and sync.
The overscan you are talking about is actually the frond and back porch which can be made smaller and used for more active pixels.
Also the front and back porches have been used to move and stretch the image via software without using the monitors own adjustments.

vga_regions_1.png

I think the game can report 320x200 resolution, have 340x220 active resolution in a 400x300 total pixels.
The overscan border in doom/wolf3d is not part of the 320x200 resolution of the game, but active pixels intruding to the porches.

Last edited by James-F on 2016-08-09, 17:42. Edited 2 times in total.


my important / useful posts are here

Reply 69 of 733, by Scali

User metadata
Rank l33t
Rank
l33t
James-F wrote:

The overscan you are talking about is actually the frond and back porch which can be made smaller and used for more active pixels.

I disagree.
I think you are missing a 'phase'. Front porch and back ports are part of the horizontal sync pulses during the 'blank/retrace interval', see here: http://www.ni.com/white-paper/3020/en/
If you take the image you posted, yes there's the 'visible area' between front and back porch (but front and back porch should be reversed, I believe. front porch is before the hsync pulse, back porch after the hsync pulse, so front porch happens first after a scanline, and then the back porch. Then you get the colorburst, in NTSC, but VGA doesn't need that).
However, this is the visible area on the CRT. If you use the complete visible area, that is 'maximum overscan': you are drawing the maximum amount of pixels that the CRT can display (part of which will be 'lost' under the bezel of the monitor that covers the edges of the CRT).

However, the default resolutions have a smaller active window inside the visible area. So your standard 320x200, 640x480 etc resolutions aren't using the full visible area.
Therefore, the border is not part of the front/back porch, but is the area between front/back porch and the active display area, so basically the part of the visible area that is not part of the active display.
On CGA and EGA, the entire visible area takes on the background colour. On VGA, there's some extra registers to control how much of this border area should have the background colour, and how much should be black. The reason for this is probably because CGA and EGA make use of standard NTSC signal timing, and the front/back porch are mostly hardwired (you can only change the total hsync pulse width, but not the individual signals that happen inside this sync interval), where VGA has its own signaling, so there is no clear reference for how long a front porch or back porch should be. They may have thought it would be a good idea to keep it programmable.

James-F wrote:

I think the game can report 320x200 resolution, have 340x220 active resolution in a 400x300 total pixels.

Something like that, yes. If by 'active resolution' you mean visible area.

James-F wrote:

The overscan border in doom/wolf3d is not part of the 320x200 resolution of the game, is active pixels intruding to the porches.

A scanline for Wolf3D would look something like this:
back porch -> delay X pixels -> turn on background colour -> delay Y pixels -> turn on active display area -> delay 320 pixels -> turn off active display area -> delay Y pixels -> turn off background colour -> delay X pixels -> front porch/hsync pulse

The X-pixels thing is something unique to VGA, and is the reason why part of the border is still black. On CGA/EGA that would always be 0 pixels, and the entire visible area would be red (that is real CGA/EGA, not CGA/EGA software on a VGA system).

Here's an example of that on a real CGA system: https://youtu.be/Hq2-eY3OkSo
The scroller is the full 320 pixels width. The rasterbars are done by setting background colour, and therefore are full overscan, and cover the screen from bezel to bezel.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 70 of 733, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

Thank you, I definitely learned something new.

EDIT:
Can I say that with digital technology displays the Visible area = Active area?
There is no need for overscan.

EDIT2:
According to this: http://martin.hinner.info/vga/timing.html
I want to add that this overscan area between the active area and the porches in VGA is completely gone from later standards like SVGA/VESA or modern timings.
What was: 40 back porch and 8 left border, simply became 48 back porch (pixels).


my important / useful posts are here

Reply 71 of 733, by Scali

User metadata
Rank l33t
Rank
l33t
James-F wrote:

Can I say that with digital technology displays the Visible area = Active area?
There is no need for overscan.

Well, if we are talking about a fully digital system, so using DVI, HDMI or DP, then there can be an exact mapping of pixels in the signal to the actual screen. So the visible area is a fixed resolution.
However, you still don't need to use the full visible area as your active display. For example, there are two ways to support non-native resolutions on LCD and similar screens. One is to digitally upscale the screen. Another is to show it 'letterboxed', so you keep the exact 1:1 pixel mapping, but introduce borders. So in that case the active area is smaller than the visible area.

But 'overscan' is indeed not required. Because you can have an exact mapping, you can generate a perfectly filled screen, so you don't need a sort of 'error margin' on the sides, to make sure that all signals completely fill the screen.
Mind you, even some LCD TVs still apply overscan (scaling up the screen a few % to make sure it fills the visible area), even when using a digital signal. You'll find that some video cards start in 'underscan' mode for that reason, when you use the HDMI output: they add a small border around the display to make sure the text doesn't fall off the edges.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 73 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
James-F wrote:

Still, 640x400 will not show as 4:3 with aspect=false, I think you should check that. Even though 1200 perfectly divides by 400.

That is expected. In order to represent the 640x400 mode with the correct aspect ratio in a pixel-perfect manner you will need an LCD display with a resolution not less than 3200x2400.

Reply 74 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
Ant_222 wrote:
KainXVIII wrote:

I prefer 1:1 and [Flashback] looks exactly like this on CRT monitor back in the days, AFAIR.

Fixed version uploaded.

Nice!
https://youtu.be/VDxz4oO5-Ck here is recorded video of Flashback.

Reply 75 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
KainXVIII wrote:
Ant_222 wrote:

Fixed version uploaded.

Nice!
https://youtu.be/VDxz4oO5-Ck here is recorded video of Flashback.

Thank you, but I couldn't make that video play pixel-perfectly. Can you?

Reply 76 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
Ant_222 wrote:
KainXVIII wrote:
Ant_222 wrote:

Fixed version uploaded.

Nice!
https://youtu.be/VDxz4oO5-Ck here is recorded video of Flashback.

Thank you, but I couldn't make that video play pixel-perfectly. Can you?

What do you mean?

Reply 77 of 733, by Ant_222

User metadata
Rank Oldbie
Rank
Oldbie
KainXVIII wrote:
Ant_222 wrote:

Thank you, but I couldn't make that video play pixel-perfectly. Can you?

What do you mean?

That at 100% zoom set in the browser your video has dimensions other than a multiple of the original and is blurry.

Reply 78 of 733, by KainXVIII

User metadata
Rank Member
Rank
Member
Ant_222 wrote:
KainXVIII wrote:
Ant_222 wrote:

Thank you, but I couldn't make that video play pixel-perfectly. Can you?

What do you mean?

That at 100% zoom set in the browser your video has dimensions other than a multiple of the original and is blurry.

Hmm, are you sure that video quality is set to 1080p/60fps? And of course youtube encoder will add some blur (but not that much)

Attachments

  • yt1.png
    Filename
    yt1.png
    File size
    396.4 KiB
    Views
    1401 views
    File license
    Fair use/fair dealing exception