pointer to video memory

"any outside libraries" as in ANY?

One thing I used back in the day was called Mode 13h, where you make an interrupt call to DOS and it puts the video card in 320x200 256 color mode, and you can write directly to video memory starting at 0xA000. I can't think of a reason why it wouldn't work anymore... is that what you actually want to do though?

If my memory serves, you can't even do that. Mode 13h, as you said, requires an interrupt call and Windows XP pretty much blocks out lots of interrupt calls that aren't meant for it (ie: DOS interrupts) as well as prevents you from mucking about yourself with video memory.

Look into a library called TinyPTC. I believe it has the source included. All it does it gives you a way to grab a handle to video memory (or possibly an emulated layer or something) so you can work with it like in the old Mode 13h days.

I'd explain better, but I'm in a rush. Hope it helps though.

-Auron

i cant use any other librarys because i will be doing it at school and i cant be guaranteed the same computer everyday. I am also just looking to draw some simple shapes with colors,yea i think what i am looking for is the vga programing. bassicly i got to get a pointer to vid mem like this

UCHAR vidMem* = 0xA0000000;

then map out my memory so i can have my screen my back buffer and some surfaces. this is all cool exept all the tutorials i have found are in assembler (I SUCK HARD AT ASSEMBLER :() and look about 15 years old. Ive been doing graphics programing for a while so i think i will be ok one i get it set up a little but im still stuck on how i draw even a pixel. anyways any help would be appreciated.

My ride's late, so I have a couple minutes extra...

Give it a shot, but I don't think you can use DOS interrupts in Windows XP because Windows XP is NOT based on DOS. There is no DOS left and the compatibility options rarely if ever seem to work.

My point with TinyPTC though is that there are so few files that you could very well just add its source to your source tree and compile it into your program. It requires NO DLLs and has no real dependencies. It can use DirectDraw, GDI or Video For Windows, all of which should be available on any given computer you're at.

Give an indication of what compiler you're using and what it targets.

Almost any compiler you could throw at us SHOULD have some native way to draw graphics that would be available with its standard distribution.

If you can include windows.h for instance, you can use GDI. That is essentially the best option for drawing pixels with no other outside code sources and with no foreign dependencies (everything for GDI is automatically shipped with Windows).

Anyway, the link to TinyPTC.

-Auron

Quote:

Original post by Auron If my memory serves, you can't even do that. Mode 13h, as you said, requires an interrupt call and Windows XP pretty much blocks out lots of interrupt calls that aren't meant for it (ie: DOS interrupts) as well as prevents you from mucking about yourself with video memory.

Not quite. Mode 0x13 _will_ work in Windows XP through its DOS emulation; I'm actually working on a retro project using it right now. The only way to access it, however, is to write DOS executables (.COM files) which are 16-bit, not 32-bit. You'll need to exhume an old 16-bit compiler or use assembly if you want to use mode 0x13.

Other than that I doubt there is a way to access video memory directly in Windows because of its protection mechanisms. Unless there's some hidden system call to do it I don't think it's possible.

ughhh ok i think i might just use the windows gdi. c++ should have some drawing function in the standard library :( (i miss drawing using the standard pascal library in high school).

Dipping into 16 bit real mode and using mode 13h is the only way. Other than that, it's not possible to get a real, direct pointer to video memory under WinXP, not unless you're a driver.

If you're using DirectX, however (either D3D or DDraw), you can lock the primary render target and get an indirect pointer which will be copied to video memory.

You can use interrupts in winXP. Or any non-hack video modes I know of. Vesa would even work for as long as it's p-mode and not real mode.

so in ASM you could do a:

asm
{
mov ax, 0x0013
int 0x10
}


to go to 13h.

taking the vidmem in chained 13h...

unsigned char *screen;
screen = (unsigned char *) 0xA0000000;

plotting would look like this:

screen[x + y * 320 ] = color.

I have a C/C++ example in TC++ but unfortunately it's not online. I made a 13h lib in ASM though for use with QuickBasic.

link w/ source in ASM.
http://rel.betterwebber.com/junk.php?id=22

And example of a 3d lookat demo using the same lib.
http://rel.betterwebber.com/junk.php?id=24

SDL is pretty barebone.

all you have to do is initialize it, and you can create a surface in either RAM or video memory, and get the pointer associated with it

Quote:

Original post by Raymond_Porter420 i cant use any other librarys because i will be doing it at school and i cant be guaranteed the same computer everyday.

Then you should be fine using TinyPTC or Windows GDI. Just link statically with the library and you will be fine.

While I was at uni we had a CG assignment where we had to plot directly into a buffer and display it, key was to keep it cross platform. Ended up solving the problem by using OpenGL like this..

Assuming a 320x240, 3 byte per pixel buffer (RGB)

#1 Alloc an array of bytes to represent the buffer - depending on your buffer format you would have 320x240x3 bytes for a RGB buffer, where the first three bytes represent (0,0) in the buffer. The second three (1,0) and so on.

#2 plot to this buffer using some function you have coded - Plot(10,15,R,G,B)


#3 once armed with this, you can upload this to OpenGL backbuffer and have it displayed on the screen.


I realise you said that you cant use external libraries as you dont know what computer you will be running on, except for WinXP is a certainty. AFAIK, all windows machines have an implementation of MS OpenGL. This stuff uses only old well supported OpenGL API calls, so you shouldnt have any compatability problems. The beauty here, it is extremely portable across unix flavours, mac and windows, although that prob does not matter to you.

Use Glut for easy set up. You can include this library with your application.