• Advertisement
Sign in to follow this  

C only graphics, no library.

This topic is 4342 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I want to write a game strictly in C with no graphics library. Now do not jump the gun on how stupid that may sound. Yes I know 'C' has no graphics support, but the game I am looking to make does not really need any. A simple text only game of sorts, or more if it is possible. So of course I googled for awhile and the best I found was some minor control via printf() but the tutorial was less than one page and provided no explanations. Any got any idea's on where I can search for information on how to get minimal graphics out of C. Thanks, Halsafar

Share this post


Link to post
Share on other sites
Advertisement
You can't. printf is as far as it goes. Anything else (colors, moving the cursor, clearing the screen) is OS-specific.

Share this post


Link to post
Share on other sites
Got anything more on printf() graphical support.
I see it can apparently change video modes.
From there can I not print text out?


Share this post


Link to post
Share on other sites
What you're looking for just isn't in ANSI C. As it's very machine/OS specific, it's not even mentioned in the standards. So as far as "no graphics library" goes, you'll definately need a terminal library. These terminal libraries can sometimes be very difficult to work with, terminals being archaic, confusing, hacked up beasts. Seriously, you might want to think about a graphics library, and if you're really in love with text, sprites or tiles with nothing but text.

Share this post


Link to post
Share on other sites
Quote:
Original post by Halsafar
Got anything more on printf() graphical support.
I see it can apparently change video modes.

No, it can't. Certain operating systems can use ANSI control codes to do things like that, but it isn't standard, so you may as well just use your OS-specific libraries to do console manipulation (they're a hell of a lot more user-friendly).

Share this post


Link to post
Share on other sites
Okay, that is fine.
See I have played a lot of text only games from back in the day which I know where coded in 'C'. I wanted to make a super quick one. If I assume I am on DOS or Linux would that make life easier? Any links to a site which may explain more.


Any tutorial on how to use the terminal specific libraries?

Share this post


Link to post
Share on other sites
Well, let's see. Linux and similar have a great console library called "curses" or "ncurses" (I forget the distinction), for which there is a tutorial available here. I believe that curses/ncurses is also available for Windows. There are also console functions in the Win32 API, documented here (somewhat more low-level).

Share this post


Link to post
Share on other sites
If you're just interested in making a text game like Zork (rather than doing this to learn C) i'd recommend looking at something like the Inform programming language - which is specifically designed for making interactive ficition.

Otherwise, QHack is a simple roguelike intended to help people get started - it's source code is freely available.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
You can't. printf is as far as it goes. Anything else (colors, moving the cursor, clearing the screen) is OS-specific.


I am not sure how much control you have if your in Linux but the address for the screen is B800:0000 and you can poke around in that memory location to get what you want.

I think the layout for the screen is: where each <...> is 1 byte

<attr><char><attr><char><attr><char>

or

<char><attr> etc...

You would need to experiment a bit as I have not done this for years..... As for the cursor on/off control... This you can do by writing directly to the ports or using your OS specific API function.

Share this post


Link to post
Share on other sites
If you really wanted a text based game, i think that could easily be done with no libs at all, regardless of OS. Of course, all you get is text, but that's what you want right?

Instead of ncurses or equivilent, just output with printf() something like this:

"Select an option: [L]ook, [T]ake, [M]ove, se"

and wait for the user to press L, T, M, or U. Something like that. That's as barebones as it gets.

Share this post


Link to post
Share on other sites
Quote:
Original post by Adam Hamilton
I am not sure how much control you have if your in Linux but the address for the screen is B800:0000 and you can poke around in that memory location to get what you want.

Only under the IBM AT/XT architecture, and then only in a real-mode operating system (i.e. MS-DOS) or through an emulation layer.

Share this post


Link to post
Share on other sites
Quote:
Original post by leiavoia
If you really wanted a text based game, i think that could easily be done with no libs at all, regardless of OS. Of course, all you get is text, but that's what you want right?

Instead of ncurses or equivilent, just output with printf() something like this:

"Select an option: [L]ook, [T]ake, [M]ove, se"

and wait for the user to press L, T, M, or U. Something like that. That's as barebones as it gets.


You can implement conio.h for it's kbhit and getch(e) commands too if your target compilers have support for it (keep in mind it's non-standard and may be implemented differently. That said, it's very commonly included with compilers despite not being standardized.)

If, however, you want colour characters or different resolutions or font sizes, that just is not going to happen without a different language that has native support for that (qbasic for example, though you sacrifice a lot of constructs if you go that route) or by implementing a library which I mention last because you stated you don't want to use one.

If you do end up needing colour text, I suggest getting SDL involved and getting one of its text libraries then just use that. Yes, it involves linking a lib, however I anticipate your main reservation is compatibility and portability and those are two things SDL has down pat, works on almost any OS you can name and many you probably haven't even thought of ;)

Not only that, but you get SDL's keyboard and input handling capabilitys. This means you can use a mouse to click on things in your text game if you want to, and it also means that you can use SDL's keyboard handling stuff to get characters instantly (similar to using the getch command in conio) instead of the standard scanf method which requires users to hit enter.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
The c language was designed for writing operating systems. Because of this, ansi c lacks almost any i/o functionality. The standard libraries only provide i/o through files, and there are 3 special files. Standard in for input, standard out for output, standard error for error output. These 3 special files can be connected to any device or file. By default they are connected to the terminal of the user running the program. The only i/o functions that are guaranteed to work are the basic ascii contol characters (for example line feed). Everything else is operating system specific. In case someone writes his own os, the standard library has to be written too. So for standalone c, there is no support for any i/o, not even printf() unless you write it yourself.

You can choose any standard library from the posix or the win32 standards and use them. Posix has various curses, xwindows and opengl. While win32 has gdi, console, directx and opengl.

Viktor

Share this post


Link to post
Share on other sites
If you want to do console graphics under Windows, I heartily recommend downloading Walter Bright's digital mars compiler (google "digital mars") and looking into disp.h. However, reading the keyboard under Win32 apps is a bit more involved than getch() etc if you want to detect shift keys and stuff like that. I have a wrapper for the windows API calls you need but not with me. Will post Monday if you want it.

Share this post


Link to post
Share on other sites
@EasilyConfused,
Sure post it if you want I'll take a look.
First I'll respond to a few posts then ask my last question.


@M2tM,
SDL, *Shutter* I've had my day with that library. It is a fine library but I think its a bit much for the tiny project I have in mind.

@Will F,
Yes, during my google searches on this topic I stumbled across the Inform language. It sounds pretty neat, if I do take that path I'm sure I can find tutorials.

@Adam Hamilton,
Now you are getting closer to what I want. Address of video card, take control of screen?



@Everyone else
So now that the majority of my question has been answered I have another. Now I am not planning to do this, but how was Wolfenstien written for example? I know it was done in 'C'. Was it because Wolfenstien was written in DOS that they where able to produce actual graphics? How did they go about getting control of the video card and taking the screen?

Share this post


Link to post
Share on other sites
I believe wolfenstein was written in assembly routines that would not work today without a lot of work. If you're really interested, look here at the bottom.

Share this post


Link to post
Share on other sites
Assmebly routines for straight DOS if I am correct.

I know for a fact Original Full 6 Episodes of Wolfenstien work on WinXP machines (just played it for many hours).

Obviously the creation of a 3D engine is plausable without OpenGL or DX or even windows for that matter. I know when I used to play DOOM it actually worked better if I didn't boot windows and just let the comp boot into DOS only.

So here is another question: Was it DOS that allowed games such as Wolfenstien to be created? If No then obviously straight 'C' with some ASM can be used to take control of the GPU and begin splotting pixels.

Share this post


Link to post
Share on other sites
Windows does incur a lot of memory overhead above what DOS and Linux do. That being said, most of Doom and Wolfenstein were written in Assembly along with C. The reason they were fast is that Windows memory management sucks and there's no way to deactivate the swap file support.

Accessing the DOS framebuffer may not even work on modern systems unless you use a DOS emulator such as DOS Box. Also you have to trigger some interrupts in the BIOS to switch screenmodes and the highest you'll be able to do from DOS is 320x200x256 color graphics.

Share this post


Link to post
Share on other sites
DOS had nothing to do with it if I remember right (been awhile since I made a 3D engine in a non-Windows environment). You used assembly to directly access the video card (which is no longer available if I remember correctly as no one releases the specs or builds them to the same ones, but I think old Mode 13/Mode X still could be used???).

Wolf3D was a mix of assembly and C code, you can download the code, or even Dooms code from idsoftware.com. If you have older hardware you can do this for sure, if you have newer video cards YMMV I'm not sure. There are still people writing software renderers for the knowledge gained so yes, it is still possible.

Best of luck.

Share this post


Link to post
Share on other sites
In order to get direct access to video hardware directly, you'll need to code in 16 bit DOS mode, in which case you'll be shoved into an emulator and run inside that environment.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Mike2343
DOS had nothing to do with it if I remember right (been awhile since I made a 3D engine in a non-Windows environment). You used assembly to directly access the video card (which is no longer available if I remember correctly as no one releases the specs or builds them to the same ones, but I think old Mode 13/Mode X still could be used???).

Wolf3D was a mix of assembly and C code, you can download the code, or even Dooms code from idsoftware.com. If you have older hardware you can do this for sure, if you have newer video cards YMMV I'm not sure. There are still people writing software renderers for the knowledge gained so yes, it is still possible.
Best of luck.


The good part of using dos was that you got your game into memory from the fat filesystem. After this point you could just forgot dos and wrote anything that you wanted. Even elder novell oses used dos as a bootloader. Most games took direct control of every hardware they wanted to use.

Today this is not possible, since there is no common standard for the hardware. You need device drivers and most manufacturers don't give out the hardware specifications, so you can only use your computer with windows or sometimes linux and other less supported oses.

The c standard allows the writing of operating systems with very little inline assembly. If you have the full hardware specification, you can do it. Otherwise you have to use a supported os and its drivers, and that requires the use of the system specific interfaces and libraries.

Just remember, c is a language and not a predefined set of i/o functions. The language standard doesn't come with a single function predefined. Even the 'standard' libraries are optional.

Viktor

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster

Today this is not possible, since there is no common standard for the hardware.

Viktor


Hmm, actually I feel its more out of being a good programmer and let the OS control the hardware, to help prevent you from screwing up everything, or from others screwing your program over.

As you said, DOS was little more than an bootloader / file I/O library for many games.

Share this post


Link to post
Share on other sites
If every program tried to take over and access the hardware directly, that would screw up multitasking.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by furby100
If every program tried to take over and access the hardware directly, that would screw up multitasking.


The idea behind writing a program that doesn't use any libraries or other external code is to have something that runs without an os. Otherwise one has to use the services offered by the os and the program is not stand alone anymore.

Share this post


Link to post
Share on other sites
If you want to write a standalone program, you either need to use assembly or a compiler with appropriate extensions. Standard C does not include anything to interact with hardware, and you're going to have to do that since you don't have an OS to do it for you. If you want to see a basic bootable program, check out Boot Sector Tic-Tac-Toe

The reason DOS games could take complete control of the hardware is simply that DOS didn't set up the processor to prevent you from doing so. Modern OSes do set up such protections, and that's a very good thing, because it prevents random crashes, restarts, hardware death, some security problems, and many other things. Imagine if you could write a simple script and upload it to your shared web server and take complete control of the machine - you could access anybody's data, alter server-wide configuration information, etc.

The way DOS games made such use of hardware was either through assembly code or through non-standard compiler extensions. Buy any old programming books and you'll find tons of information about BIOS interrupts, memory-mapped hardware, etc. If you want book suggestions, I can check my library when I get home and see which have the most info on such things.

Note that in order to make such use of hardware, games had to have _HUGE_ libraries of 'drivers' because each brand of each hardware device could have it's own interface, and that's why old games only support 5-10 sound cards, low (VGA) resolutions, etc. Things like OpenGL, DirectX, etc are a huge blessing and you really should take advantage of them in general.

If you want to make a 'real' stand-alone game, I'd suggest just using a bootable linux CD. Pack all the drivers you can onto it, then make your game using OpenGL for graphics and similar libraries for sound etc.

Quote:
Original post by Anonymous Poster
Quote:
Original post by furby100
If every program tried to take over and access the hardware directly, that would screw up multitasking.


The idea behind writing a program that doesn't use any libraries or other external code is to have something that runs without an os. Otherwise one has to use the services offered by the os and the program is not stand alone anymore.
"Stand-Alone" doesn't have to mean "works by itself", it could also mean "Works without anything besides what is on the disk", which could include a bootable version of linux or the like. Either way, I don't understand why you'd want a standalone program - besides being a novelty, they don't really offer any benefits, and having to reboot from the installed OS and be unable to use anything else besides that one program is a HUGE step back - multitasking is a _very_ good thing.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement