Subject: Writing pixels to computer screen
Platform: Windows 7 Pro 64-bit
IDE: Visual Studio 2010 Premium

How can we write pixels to a screen using C++? In other words, there's a specific point on my monitor that I want to have a specific color. What is the code to make that specific point a specific color?

Every time I've looked for a solution, I get some long bit about how Windows can make bitmaps through XYZ, transfer bitmaps or do other operations on them through YAX, etc, etc. (To add insult to injury, I'm still not sure how to even display a bitmap.) I just don't care about that stuff. I want an unmanaged method that Windows doesn't even touch, or failing that, touches minimally.

Computers have been displaying pixels before the first line of Windows 1.0 was even written, so there has to be a way to do this. What is it?

No (modern) operating system will let you touch video memory directly.

The only way would be to use something like OpenGL (cross-platform, FOSS) or DirectX (Windows-only, closed source) to create a window for rendering·

If I understand you correctly then I suggest you check out this link: http://msdn.microsoft.com/en-us/library/dd145078%28VS.85%29.aspx

It's fairly straight forward what to do from the explanations on that page (I hope).

Chrisname,
If Windows won't let me mess with the video memory directly, is there some other system that will? Or a way to work without a system, or something?

I just need this program to crunch some numbers for me and keep me up-to-date with a graphical display showing the evolving data in a plot; no need for it to work on other machines or be user friendly.

Chris,
That's really a lot like what I'm looking for. However, I hear that that specific method is pretty slow (I'm guessing it makes a lot of calls internally). Would you know if there was a faster one?

In that case, couldn't you just plot them on a console screen and use ncurses instead?

Sure, plotting to the console screen would work. Could you tell me how to do that?

Ideally, it'd be an efficient operation since the CPU is going to be pretty much consumed crunching the math.

@Chemical Engineer

Use ncurses:
Download: http://pdcurses.sourceforge.net/ (ncurses works on windows but you'd probably have to compile it yourself)
Tutorial: http://tldp.org/HOWTO/NCURSES-Programming-HOWTO/

If you want to do your number crunching and handle your GUI at the same time, you could put the UI in a separate thread.

Windows threading tutorial: http://www.bartosz.com/win32/active.html

chrisname,

Thanks, I'll look into the ncurses.

I'm a bit confused, though. How does ncurses itself modify a pixel? And why shouldn't I just use that method instead of ncurses?

If you are in a windows app use the windows GDI function SetPixel

ncurses doesn't handle that. It stores what you print in a buffer (called a backbuffer) and then you call the refresh() function to switch what's on the screen (in the forebuffer) into the backbuffer and vice versa. It's a technique called double buffering. It reduces tearing and flicker on a screen and allows you to display all your data in one go (or, you can refresh() the screen after each print, it doesn't matter).

The way writing to a console window works is something like this:
1. You call a library routine (say, printf()) to write to standard output (stdout) (which is a file on UNIX systems and, IIRC, on Windows too)
2. If "cooked mode" is on, then the output is actually stored in a buffer until either a newline ('\n') appears or the buffer is filled. When that happens the buffer is "flushed" (written to the file and emptied). If "raw mode" is on, then the output is written directly to the file.
3. The terminal emulator (e.g. xterm, gnome-terminal, cmd.exe (I think cmd is the terminal emulator but I'm not sure)) gets the contents of the file (usually through a pipe) and sends the text to a graphics library (such as the windows API, SFML, SDL, DirectX or OpenGL) to be rendered on the screen
4. The rendering library turns the text into raw data and writes it to a buffer and sends it to the graphics driver
5. The graphics driver plots the pixels on the screen in the appropriate places
6. The video card turns the data in it's memory into an analogue signal and sends it to the monitor
7. The monitor writes on the screen (sometimes you have an Analogue-to-Digital Converter (ADC) for digital monitors). Different monitors write to the screen in a different way (CRT (Cathode Ray Tube) monitors write each pixel one-by-one, horizontally (the time it takes to do this a line is the H(orizontal)Blank or HSync period) and then vertically (the time it takes to display the entire signal is the V(ertical)Blank or VSync period); (most) LCD monitors display the entire thing at once).

And all this happens (usually) 60 times per second (sometimes higher). What (I think) you're trying to do is skin steps 1-4 and send data straight to the graphics driver (or possibly straight to the video card). You can do this, but there are libraries (OpenGL, DirectX) that do this for you. So you might as well use them.

chrisname,

Thanks for the explanation of how it works.

Say, for whatever reason, I don't want to use those libraries. Rather, I want to use the base methods that those libraries call. How could I do this?

To note it:
Honestly, I just don't have the time or patience to go through and learn a bunch of idioms and memorize how specific libraries want me to call them and what they do. I just want the bare functions, which will be easy enough to get to perform any song and dance I want to as soon as I can figure out what they are. However, I just can't seem to find anyone who actually knows how to skip to the drivers or video card.

Everyone I've asked on this subject since I started the project a month ago has been telling me to use this library or that, this method or that. And I get it- libraries are great tools in many situations. However, they are not what I need, and, bluntly, I'm just so tired of no one giving me a straight answer. It's obvious that it can be done; I just want to know how.

Part of me suspects that people have been using the libraries for so long that most programmers today don't know how to do the basics without the libraries. Which is cool if that's what they need, but it does leave me unsure of how to find out what I need to know.

It would take you far more effort to learn how to do that.

Part of me suspects that people have been using the libraries for so long that most programmers today don't know how to do the basics without the libraries

Then who writes the libraries? Most programmers could, in theory, do anything that any other programmer can do. Maybe not as elegantly or as efficiently, but with the same resources they could. But why reinvent the wheel?

I said that I don't think most programmers can. And I think this because no one's telling me how. They're obviously helpful people, and if they're not helping me, it makes sense that it's because they can't. And I can understand why most programmers don't mess with the low-level coding; it's just impractical for many projects these days.

However, I do have to mess with the low-level stuff. Do I really need to explain why?

Please, if you know, tell me. If you don't know how to mess with pixels without going through libraries, but you have an idea of where I can ask or look it up, that'd help, too.

Modern hardware is built for multitasking. In order to make that work you have one and only one program managing the display (typically the OS), and all other programs go through the OS and access the data indirectly.

This allows the OS to do things like window layering, and prevents conflicts. What would happen if two programs were trying to draw data to same part of the screen at the same time? Which would "win"?

This is why everything is done through libraries. Direct access to the hardware is simply impractical. Not because it's too complicated, but because it is prone to conflict and doesn't play well with other programs.

There is almost never a practical reason to bypass this pipeline. And I'm really wondering why you would even want to consider doing it. Why wouldn't using a library work for your needs? Why do you feel you need to skip the middle-man?

Unless you're looking to write your own OS, I really don't see the point here.

EDIT:

Chemical Engineer wrote:
And I think this because no one's telling me how. I don't think that they're trying to push me around and mess with me - it's more likely that they just don't know.

To address this: I don't know how. I've never had the need.

I question whether you really have the need, or if you just think you have the need.

However, I do have to mess with the plumming. Do I really need to explain why?

I suppose you don't. It would certainly satisfy my curiosity, which would be appreciated, but it wouldn't put me any closer to give you the answer you're looking for.

At best if you could explain why you think you need it, we might be able to explain why you really don't, and be able to suggest an alternative way to do what you want that has the same end result.

You want to plot pixels to the screen. You can't do this directly (because of memory protection) on a modern (assuming AMD/Intel hardware, anything that runs on a newer CPU than the 8086) OS. So, you have to ask the operating system. Therefore, you should probably use the SetPixel() function.

Edit: Damn you Disch.

Disch,

I want to cut out the middle man because the program itself is very resource intensive. It's a program which performs complex regressions - many of them. I'd give a number, but in truth, I'd like it to perform infinitely many. Since that's not actually possible, I'm going to set the cut-off at some extremely high yet still possible number.

The OS and other operations would just slow this process down, and I'd have to have the program run for longer to get the same amount of calculation done. That's highly impractical. I don't need the computer to do anything else while this process is running, so I'd even go without the OS if that's possible.

In short, I want the computer to act as a giant calculator. I want to mess with pixels so that I can have it printout plots of what it's doing while it's running so that I can keep track of its progress.

PS- If you're really curious, I'm working on my Ph.D. in Chemical Engineering. I've already earned some undergrad degrees in various subjects - this isn't a simple project. At this point, I have the math, physics, chemistry, engineering, etc. mostly figured out. I need a computer to crunch the equations as best it can, since doing them by hand would take longer than my natural life span.

I need to have a basic graphical output which will represent plots that will really only make sense to me, since I'm the one who designed it. The graphs won't be in English and I am using the word "graph" loosely. But, long story short, I only recently learned the bit of programming that I know. I don't have time to learn a million libraries, nor can I afford to lose processing power.

However, I can very strong when it comes to manipulating data, and given the secret handshake that I need to perform to get the computer to use the monitor, I'll be able to make this work.

In that case, why not run the UI in a separate thread like I suggested before?

Edit:

Actually, if you want the computer to be focused solely on your program and not doing anything else, you could add it to the Windows boot menu (or better yet, the GRUB boot menu) and have the Windows bootloader (or GRUB) load your program. It would mean doing EVERYTHING yourself, however.

http://wiki.osdev.org/Expanded_Main_Page
Take a look at the articles on here. Depending on your skill you may be able to follow the articles there and write the code you need to write to the screen yourself. If not, I've been working on writing as much operating system code as I can [understand] over the last month or two and I can give you what I've done so far. Then you could add your code and have your program running at the lowest level possible.

chrisname,

I'm not sure if running the UI in a separate thread would really free up all of the processing that I want. Plus then I'd still have to figure out how to mess with the graphical output.

I don't know how quickly my screen updates - 60Hz, I'd guess? - but I'd like to be able to have the calculations update and print at that speed without significantly impairing the CPU.

Put MS-DOS on a floppy disk, boot to that and use a copy of Microsoft visual C++ 1.5 ( if you can find it) and write a DOS program. The screen RAM can be directly addressed as address $A000 onwards if i remember correctly on a 320x200 screen palette of 256 colors. Anything else is going to require you to work with the OS. If you build your own OS, you're going to need to talk to the hardware you have in the language it understands. That's what drivers are for, to convert the OS way of talking, to the hardware way of talking.
Personally I think your best bet is to look up some directX code for writing directly to the back buffer, you'll need to use the DIRECTX SDK library, reference to the Lock() meathod.

In that case, I can give you the code I've written.

It's not fantastic and is probably riddled with bugs but it will work well enough for your purposes. It's very unfinished (I have theoretical support for multiple virtual terminals but no dynamic memory allocator so in practice there is only one buffer and therefore only one terminal); at the moment all it can do is boot, print messages and load the IDT and GDT.

Also it only runs in text mode; so you wouldn't be able to change the colour of specific pixels. You would only be able to draw ASCII characters in 16 colours.

Edit: Also, I should mention that my implementation of the C string library hasn't been tested at all (except the itoa() function, that one has been tested thoroughly).