pouët.net

His code may suck - but can you explain how to wait for a vertical retrace in the win32 console?

As he just registred to post this stupid comment, I guess no, he can't.

You could "cheat"; load up directx to determine when vsync happens; close it down and use the windows multimedia timer from then on, but there is still possibility things will wander out of sync.

did I just say vsync instead of v-retrace?
I am the master of stupid comments

I wouldn't even call it timing code. I wanted to make the tearing test app as simple as possible to demonstrate the problem and not include unnecessary things in it. Better frame timing doesn't solve the problem of tearing in this case. My real app has timing code which works quite well -- and as I wrote in the initial posting, it doesn't matter what framerate you draw.

Frame rate!!??
You know; with gigahertz processors (say the refresh rate is 75hz, as it is on my flatscreen), you should be able to target vblank fairly precisely if you know where it is.
It could be anywhere from +0.000 ms to +13.3333 ms over your base clock (at 75hz). Just finding out where it is is the issue.

Having things run the exactly at the vsync rate (which is actually ≈75.1Hz in my case) won't prevent tearing. You need to make sure your dumping your stuff precisely on the side of the dock, otherwise you end up with a messy deck and half the stuff splashing into the water. It doesn't matter if everyone else in the band is going at 180 bpm if you are ahead or behind by %30 of a beat. You could come up with all sorts of other analogies.

That's cool QUINTIX256, go make a demo about it.

Is a textmode demo supposed to only run in dos mode, or is it any demo that uses text output?

psonice: i guess your vga bios should be in mode 0 to 7 or something, but this thread is prolly about TMDC definitions of textmode

Yeah, just thinking that most of the stuff discussed here basically comes down to how you answer that question.. it'd be a good idea to decide first. Tearing shouldn't be much of an issue if you're going to use dx/opengl...

psonice:
It looks more TMDC oriented. And the TMDC standard of textmode can be two things:
oldschool: DOS, running under DOS or emulated with DOSbox.
new school: Windows' terminal, with slightly different colors (the dark yellow in DOS is orange-ish while on windows they changed it to something more kaki) and sometimes incompatible with fullscreen mode (on WinXP64, Vista, Win7) which is a shame.

Having to run the demo in console window-only wouldn't be much of a problem if Windows allowed it to have a decent frame rate. I wonder if there isn't some posisble way to hack around that...

And btw someone asked earlier why linux and osx demos weren't accepted in TMDC: because not every judge have both a windows machine and a linux one and a mac one, else we might have extended the rules.
And about tweakmode: there actually is a lot of fun to have with a tweakmodes and a tweakmode contest could be interresting. But you end up with any kind of weird VGA mode, but it's no longer text mode.

Here is some very inspiring work by Sol. We are still a long way behind something like his bruteforce technique.

In other words: I don't know what I am talking about. Since that is the case everything I said is moot. I feel like an idiot.

about tearing: I tried the tearing test app: almost no tearing on 60hz display, but tears as soon as it move up to 75hz.

I know it sucks but it can be reduced with either slower effects or slower refresh rates, or more blurry image.

I actually never cared about tearing and never noticed it in my own demos, but it's probably the graphics that are too messy, or the code that is too unoptimized and slow :P

I also looked into what can be done to have fullscreen text mode under vista: the solution suggested by Microsoft is to install the XP video drivers. I might give you some BSODs but won't complain on int10.
You can set the setup.exe to run in XP compatibility if it doesn't want to install the driver on non-xp machines.

couldn't one "just" take the console rendering from dosbox and be fine? their rendering should look pretty much like a real console after all...

and it could be distributed as an "official" alternative to the native windows console for contests like TDMC

src: I don't think the 386/486 emulation dosbox can use nifty things like use SSE instructions or use multiple processors; and it is (at least in my experience) significantly slower. I don't think it is possible to do 3 billion ops/sec in dosbox; but then again who needs that much in textmode?

BarZoule: If it where straightforward to go from XP to Vista/7 drivers that would be fine... but it isn't, and as you suggested involves risks.

I think xteraco has a bit of a point. Their should be a platform independent textmode wrapper (like SDL?). So long as there is a 8kb buffer of chars and colors it shouldn't matter where it goes; be it a teletype terminal (like PuTTy), opengl/directx "tilemode", a ridiculously high speed color impact printer; XNA for ZuneHD and xbox360, or wherever 32bit high-performance cpus and relatively high res displays exist.

I just use their instead of there... I just must have a talent for displays of ignorance.

saga: it doesn't matter if he register just to post that question. He registered, he asked, he makes a demo. Fucking great I say. more people to the scene! Bring your family!

QUINTIX: i didn't talk about the emulation of a whole dos system but only the drawing code of the console (i guess they are drawing it with sdl?)

There are some terminal replacements already, they take the STDOUT and STDERR and put it back to the screen their own way. The only problem is they tend to not support color and/or simply crash when a textmode demo starts up.
It's kinda ugly to make a competition for an artificial plateform, but that's a solution we were actually thinking about, seeing the rapid decline of XP. If done as an enhancer (being only compatible and not giving less or more features than the old dos or terminal font gave, only being faster and fullscreenable) and the demo can still be run in the actual console, then it would be perfect. However I doubt the feasability of such Terminal Enhancer :T

I agree with src. Why not use an opengl/sdl wrapper? Just a lib providing console functions.

And I know this is no console demo then. Which it isn't anyway... so.

Well, my first though is that what stuff like Amiga AGA, Commodore 64, Nintendo DS, ZX Spectrum etc... demos are; artificial platforms. Some of the newer ones (xbox 360, PS3) are basically impossible to "emulate"...
So maybe it is about time to have a "Windows 5.0" (xp/2000) platform separate from "windows"?

I donno... textmode works fine on both my Vista systems; I just can't do fullscreen; which is no biggie. I just right-click and set the font size to 8x8 instead of 8x12 so things are proportioned properly; and XP/2000 are definitely not "obsolete" (Commodore) or "self-contained" (xBox 360, palm, windows mobile) like other demo platforms are.

I still think there should be a library that takes the 8 kilobyte buffer and draw however best on the system or however the user chooses, be it in an terminal in x; the console in windows, outputting to putty or other TTY software, or just doing "tilemode";

There is nothing platform specific about the 8kb "back-buffer" that is drawn to or the PCM that is streamed along with it. It is where stuff goes that is platform specific.