Textmode on Windows: Tearing
category: general [glöplog]
I'm trying to do some Windows textmode-stuff and have problems with massive amounts of tearing in the console window. I'm using the Windows console API (with CreateConsoleScreenBuffer(), WriteConsoleOutput(), etc.) to handle the textmode.
It doesn't matter whether I update the console window at 30 fps or 70 fps or whatever, it's always tearing. Is there any way to sync the console window updating to v-refresh?
I've created a simple little example to show what I mean: http://juah.net/rnd/tearing.zip. It comes with source as well (written in D, should be easily understandable for anyone who knows C).
Anyone know how to fix that? :-/
It doesn't matter whether I update the console window at 30 fps or 70 fps or whatever, it's always tearing. Is there any way to sync the console window updating to v-refresh?
I've created a simple little example to show what I mean: http://juah.net/rnd/tearing.zip. It comes with source as well (written in D, should be easily understandable for anyone who knows C).
Anyone know how to fix that? :-/
Doesn't tear that much here. There's probably no way to fix it, since text mode is... well, text mode.
Textmode on Windows is a goner anyway. You can't even Alt-Enter on 64bit versions of Windows.
Going forward, I'd actually suggest setting a 256-color 720x480 mode and doing the text mode bit by hand. Yes, really.
Going forward, I'd actually suggest setting a 256-color 720x480 mode and doing the text mode bit by hand. Yes, really.
If someone interested, here is a rip of 8x8 and 16x8 BIOS fonts from NTVDM
Each byte encode a mask for 8 pixels (width of a char)
http://codepad.org/b0aVkPH4
Each byte encode a mask for 8 pixels (width of a char)
http://codepad.org/b0aVkPH4
@Ryg: actually, fullscreen console died with Vista, 32 and 64 bit versions alike :)
Also, the new way to do textmode is to use an OpenGL wrapper
Also, the new way to do textmode is to use an OpenGL wrapper
Quote:
This *so* hurts my oldskool mentalities. While I am thinking of whether or not it's feasible to do a demo on an old PC *at all*, with routines optimized for text mode, you guys are talking about using OpenGL and just rendering to textmode as an afterthought.
Maybe TMDC should really be called the 80x50 compo? :-)
Quote:
Maybe TMDC should really be called the 80x50 compo? :-)
Don't say that or you'll get beaten mercilessly. I stopped trying after the third utterance; I couldn't take the pain.
If textmode compo actually allowed picking your textmode via rendering to bitmap, I'd pick 640x200 obviously (CGA)... if you want to be ANSI purist, you'd pick 640x350 (EGA).
lugoober: that was the case in xp64 already :)
Making your own custom mode to get around the limitations that define text mode doesn't sound right to me. One of the attractions of text mode demos is they overcome the limitations of the console in a novel way, and the fact that everyone has to use the same medium levels the playing field.
Building your own custom text mode means you have a significant advantage over the competition and I don't think the textmode demo scene is big enough to support separate compos for "classic" console demos and "enhanced" custom mode demos.
Building your own custom text mode means you have a significant advantage over the competition and I don't think the textmode demo scene is big enough to support separate compos for "classic" console demos and "enhanced" custom mode demos.
@ryg: that I didn't know :)
MICROSOFT IS KILLING THE TEXTMODE SCENE!!!!11
MICROSOFT IS KILLING THE TEXTMODE SCENE!!!!11
Quote:
Making your own custom mode to get around the limitations that define text mode doesn't sound right to me. One of the attractions of text mode demos is they overcome the limitations of the console in a novel way, and the fact that everyone has to use the same medium levels the playing field.
Well, we have recreated the same environment, not made our own custom mode (although we could have, obviously). The alternative to doing it this way is to run textmode-demos in XP32 or DOS (no, no, linux is not an option), where fullscreen console windows are still available.
But the real problem with your statement is that most textmode demos are regular demos shown through a filter. So the only real difference between the demos are the dithering from a highres framebuffer to a lowres text-buffer. And considering that several demos are using the same routines for the dithering...
Quote:
MICROSOFT IS KILLING THE TEXTMODE SCENE!!!!11
This is basically what I've been saying for ages.. =)
It's still posible to make your demo fit in 512bytes and put it as the bootsector of any usbkey. That is, as long as PC still ship with a BIOS :)
I have tearing issues with my text renderer too. =[ I tried to get a text renderer done in time for last year's TMDC and failed. With just under a month now it looks like I won't be able to make this one either. I'd use libcaca but for the life of me I can't get it to build.
I did find an interesting link just a few minutes ago that I'm going to look in to.
http://www.benryves.com/tutorials/?t=winconsole
Hopefully that helps with your tearing issue.
I did find an interesting link just a few minutes ago that I'm going to look in to.
http://www.benryves.com/tutorials/?t=winconsole
Hopefully that helps with your tearing issue.
The point is that tearing is not a limitation of textmode, just a consequence of the Win32 (and Linux) textmode implementations not caring about vertical blanking at all. Similar goes for the inverted character that's supposed to represent the current mouse cursor position which can't be turned off.
I really think that emulating textmode yourself is not a bad thing, particularly if it allows you to fix these problems.
I really think that emulating textmode yourself is not a bad thing, particularly if it allows you to fix these problems.
Quote:
... Similar goes for the inverted character that's supposed to represent the current mouse cursor position which can't be turned off.
Sure you can, under xp at least, see my tmdc demos :) It' just that libcaca users don't bother findintg out how to hide keyboard or mouse cursors.
While you can't avoid tearing, you can minify it by limiting framerate to refreshs rate.
Quote:
I really think that emulating textmode yourself is not a bad thing, particularly if it allows you to fix these problems.
But there it stops being text mode and starts being some sort of tile mode.
Quote:
But there it stops being text mode and starts being some sort of tile mode.
Now what is that supposed to mean?
What defines text mode for most people is precisely the original IBM PC character set, the resolution and the 16 default colors. If you think that it makes any difference to the demos themselves if you or the hardware does the conversion to RGB pixels, fine, but I think it's a pretty retarded way to make the distinction.
For what it's worth, I did a lot of textmode stuff years ago (all unreleased and lost by now), and that involved making heavy use of the programmability of the charset, the fact that VGA and compatibles actually support 512 usable characters and not just 256, and occasionally palette modifications during the frame to get more than 16 colors (and certainly a different default palette to begin with).
All that is actual textmode stuff, in the sense that it runs in VGA text mode and makes heavy use of its capabilities. Yet none of these things are allowed in TMDC (I'm not certain about this though - I believe nobody actually tried). This is not meant to be a criticism of TMDC - I just want to make very clear that the de-facto limitations of TMDC entries are really self-imposed and have little to nothing to do with the actual hardware limitations of VGA text mode. And if it's really about this particular set of limitations (and not about "what is the most you can get out of text mode" in general), then there's very little point in insisting that it be an actual text mode, particularly when the support infrastructure for that is as bad as it is.
Quote:
I just want to make very clear that the de-facto limitations of TMDC entries are really self-imposed and have little to nothing to do with the actual hardware limitations of VGA text mode.
Question is, though - is it "VGA text mode" or "Windows console text mode" that TMDC aims for?
Ok, so it can't be helped. Thanks for the answers.
I agree that TMDC rules probably need to be adapted in the future. Like, providing a standard textmode-emulation-program that entries have to use (after all, MS-DOS entries running in DOSBox are allowed, and in a way that is simply a textmode-emulation). Or maybe some hack that zooms the windowed console to fullscreen.
Otherwise, with more and more people upgrading to Vista or Win7 which have no fullscreen-textmode anymore the audience will get smaller and smaller...
I agree that TMDC rules probably need to be adapted in the future. Like, providing a standard textmode-emulation-program that entries have to use (after all, MS-DOS entries running in DOSBox are allowed, and in a way that is simply a textmode-emulation). Or maybe some hack that zooms the windowed console to fullscreen.
Otherwise, with more and more people upgrading to Vista or Win7 which have no fullscreen-textmode anymore the audience will get smaller and smaller...
The thing that pisses me off about TMDC is that they don't accept Linux or alternative OS entries. That, and no tweak mode. You're forced to deal with trying to make text mode look good, but you're not allowed to use technical tricks. phff
xteraco: I think the whole point is that you're forced to deal with trying to make the built-in OS text mode look good without creating your own special text mode with exclusive bells and whistles. Other OSs probably aren't allowed because there aren't enough entries to split it into OS categories, and a combined category could be unfair because capabilities differ significantly between OSs.
I'm starting to see the argument for a standard charset and standard, portable renderer here, but allowing a free for all would be a terrible idea.
I'm starting to see the argument for a standard charset and standard, portable renderer here, but allowing a free for all would be a terrible idea.
Code:
Sleep(15); // Wait a little for the next frame
It's quite simple really. Your timing code sucks.