Learning 13h Graphics, can't compiel some given code

This is a discussion on Learning 13h Graphics, can't compiel some given code within the C Programming forums, part of the General Programming Boards category; First
Dev-C++ compiler
Problem
30 d:\docume~1\iamien\mydocu~1\c\newfol~1\untitl~1.cp p
aggregate `union REGS regs' has incomplete type and cannot be initialized
Code can ...

I haven't done a whole lot of low-level coding, but when I tried to access the parallel port at a low-level in windows it would fail, but in DOS or Debug it would not. So I finally learnt that I would have had to create a device driver to gain Ring 0, or ring 3(I can't remember, sorry!), hardware access. I found an example at a website that used undocumented win API to give the thread access to that hardware. I'll try to find the link again, I've reformatted since then and did not save my favorites. Yup, go here: http://www.beyondlogic.org/ it may help, I don't know. Maybe you'llhave to create a DLL in MASM or something. Good luck!

"What are you after - the vague post of the week award?" - SalemIPv6 Ready.Travel the world, meet interesting people...kill them.Trying to fix or change something, only guaruntees and perpetuates its existence.
I don't know about angels, but it is fear that gives men wings.
The problem with wanting something is the fear of losing it, or never having it. The thought makes you weak.E-Mail Xei

Because mode 13h is all about low level access to the hardware and your OS no longer allows such nonsense from unprivileged programs.

Because your compiler is incapable of producing that ancient 16bit real mode code which would be required.

Because....

Not exactly all there is to it...but if you want to use mode 13h graphics you can do it in DirectX. Just get DirectX up and running and tell Windows to go play with itself and you can treat DirectX exactly like you would any old DOS mode 13h program. The beauty of it though is that you have oodles and oodles of memory to play with and yet you can still use mode 13h and access the frame buffer directly - either from C or from assembly via a pointer that DX will give to you when you lock the buffer.

I'm working on a DirectX shell for new comers so that people interested in starting with graphics or games can get up and running w/o having to mess with all of the DirectX init crapola which has little to nothing to do with actually programming the game.

And your compiler can produce the so-called ancient 16-bit code but it requires a bit of manipulation on your part. Best bet is to use DirectX for mode 13h, that way you don't have to mess with 16 bit code or fighting with your compiler - which is something you don't want to do. It all might sound hard right now, but really its not.

Gimme some time and I'll get the shell up and running - pure C mind you not C++. My current shell is in in a class and I'm working on removing the class and making it easier to get up and running for people just like you.

In fact, the goal in DirectX programming is to get the system as close to a pure 32-bit DOS environment as is possible. We don't want Windows screwing around with anything and we don't want to call Windows to do much because its so doggone slow. All it takes is to create a simple window, message loop, and some other housekeeping chores and you basically have control of the system and access to its hardware as well as all of that memory - a programmer's dream come true.

My advice to would be to get a book on DirectX programming by Andre Lamothe or another well-known author - it will help you a lot.