Jump to content
  • Advertisement
Sign in to follow this  

game programming without libraries

This topic is 4232 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

hi there, im on an ubuntu ppc system. i want to write an interactive game or a simple demo,with sound/graphics and user input. but i dont want to use any libraries at all.(i want to go as low as possible). and i will consider it a success,if i manage to draw a single pixel,or make a sound. i will be using C and assembly. why? just curios...i tried gba before,and it felt great to have unlimited control over the hardware..but i want to do it on a real computer system this time.. im not aiming to develop a game like this,i'd definitely use libraries if i wanted that. this is like a big mystery to me,and i want to solve it,that's all. my current goal is: a black screen some geometric shape in the middle user taps some key at a tempo, at each tap,the average time is taken,and the geometric shape cycles colors and the sound hardware beeps,at that time interval. far future goal: run this program on a virtual pc,without an operating system i wrote something similiar to this using openGL, i used time.h for timing and glut for interrupts/idle processes. this time i want to do it as raw as possible. for now,it could be a linux console application. like old dos games (i thought about dos,but 1- im on a ppc,i dont want the cross compiling hassle, 2- im already in linux,it should be easier to reach hardware) where do i start? i inspected the quake source,but i need something much simpler to start with. are there files in my system,or in the linux source code,that can help me with this? (to see how the memory is mapped etc..) ** best thing would be a simple demo source code for a powerpc,that is pure c/assembly (no opengl,no sdl,no allegro etc..) thank you in advance, (would inspecting an open source game library help?,like allegro?)

Share this post

Link to post
Share on other sites
To talk to graphics cards and sound cards you need drivers. You can talk to drivers through libraries: in the case of graphics cards the drivers are written by the manufacturers, and the library is either OpenGL or DirectX. You could only bypass the use of common libraries if you write your own drivers: which would then only work for one specific brand and type of graphics card.

Typically to do anything with component hardware, you have to use a library.

If you find the Quake source too complicated, i can promise you that writing your own driver when you don't have access to information about the specific hardware is much much harder.


Share this post

Link to post
Share on other sites
Its basically impossible to do without using any library what-so-ever on modern operating systems because to get the level of access required you would have to steal primary control of the hardware away from the OS, which its obviously not going to allow. If you were on an x86 machine, I'd say to download FreeDOS and give that a go. It was pretty common for game programmers to write bare-metal code for teh VGA and Sound controller in those days; but, to the best of my knowlege, there is no OS that provides similar freedom for PPC machines.

Your best bet, for graphics, would be to simply get a linnear framebuffer from the OS, and call on the OS to blit it to the screen. This will require some libraries, but the desired effect (which I presume to be that you get some satisfaction doing low level stuff like writting your own graphics routines - which I share in myself) is the same.

You might be able to do something similar with sound. Get a soundbuffer, write your own software mixer that writes to it, and use the OS to play the soundbuffer once you're done.

This is probably as close as you can get on a modern OS withought delving into writing drivers. If, however, you enjoy this kind of thing for the same reasons I do, I suspect you'll be happy with what you can accomplish.

Share this post

Link to post
Share on other sites
hmm..thank you,i knew it wouldnt be easy,thats why it's attractive,im not aiming at a modern OS though,im trying to make the hardware "work",and i dont care what hardware it is...
my motivation is rather "learning" than making something portable,that does cool stuff,as i said before,i consider it success if it "beeps" for now.
and if it works,my motivation would be making that work efficiently in that current system,
im not a professional programmer,and noone's expecting anything from me,i just love doing this,i love learning new things,solving problems,improving current solutions etc...i dont have a "super game idea",or "not satisfied with current systems/libraries",or anything like that,i just love inspecting and figuring out how stuff works.
all i need is a place to start,and it is the most frustrating part..
i have freedos running under qemu in my system,
it is emulating a standard vga card and a standard sound card.
reaching information on those cards shouldnt be hard,(i have a very old book on fractal programming in dos,which i believe explains lots of vga stuff),
should i go that way?? emulate an old-pc with common hardware(so it'll be easy to find documentation,since all these years people have been writing dos games)
maybe find few simple games with sourcecode and inspect them?
how about an atari st system?
thank you very much

Share this post

Link to post
Share on other sites
Since you're on Linux anyway, personally, I'd stop at the Framebuffer and ALSA (or OSS, take your pick). You won't be on "bare metal", but you'll be close, and you'll be avoiding all the userspace libraries like X, OpenGL, etc. I think going much lower will get frustrating fast, as the majority of docs you'll find for going directly to the card will be written for x86, not PPC. But that's just me.

If after doing Framebuffer and ALSA you still want to go lower, you could always dig into the kernel sources and see what it takes to go directly to the hardware for your architecture.

Share this post

Link to post
Share on other sites
i found this nice tutorial
and it looks like im gonna be involved in x86 assembly,which is not bad,im planning to move to an intel system in the future anyway.
i got dosbox running vga examples right now,which means,my ppc will be able to handle my programs,next step is a cross-compiler..i will try to compile the examples on that website,once i succeed,i shall start my journey

thank you all again

Share this post

Link to post
Share on other sites
Linux will definately be a better environment to code in, so I hope you're able to get a working cross-compilation setup going. Failing that, there are editors/compilers for DOS. Probably the most modern of which would be DJGPP (a DOS port of GCC) or the Digital Mars C/C++ compiler. Some editors support multiple code windows, or something similar to tabbed editing - though neither approach is as nice as a properly-windowed environment like X.

Just a fall-back option for you, in case the cross-compiler proves to be trickier than its worth.

Share this post

Link to post
Share on other sites
here's what i did:
i failed preparing a cross-compiler,
unless im mistaken,easy way to make djgpp work,is thru owning an x86 system,there is always the hard way,and after spending hours,i decided it's time change the strategy.
i installed a C compiler under qemu/freedos

it might help other people who are interested,
step by step:

-i installed qemu to emulate an x86 machine with standard vga and sound.
-downloaded the freedos cd image
-created a 400MEG raw format disk image which should be enough for my case
-booted my new virtual machine with the cd and using hd image
-installed freedos
-played some games to test it,worked fine
-downloaded pkunzip
-downloaded borland turbo C compiler 2.01 (free at their website)
-if you unzip the borland compiler in linux,it creates 3 disk folders,
and when your going thru the installation in dos,you'll be asked to swap floppies,
in this case,there's nothing to do but stare at the monitor,because the installer only lets you specify the path once,then it assumes the rest will be on the same drive/path.so when you start with disk1,you're stuck with it.
a painful way of doing this could be preparing 3 different floppy images with qemu-img,each containing related borland files,
but,there is good old pkunzip.
i went into dos,
i simply created a folder,copied my zip file there,and pkunzip..it unzipped all the disk contents under one directory,and finally,it did install correctly.
(unzipping everything in linux,and putting them under the same directory does NOT work,and i dont know why)
-i tried compiling few c files,
-it worked!

i'll be back with updates/bugs etc...

Share this post

Link to post
Share on other sites
Problem is, you're trying to bypass the OS. The OS will not let you bypass it.

If you want to talk to the metal you're going to have to nerf the OS completely. It doesn't matter if you're targetting PPC or i386. You can either target an unhosted (standalone) environment -- which is what ye olde DOS-days games effectively did, except they relied on the built-in machine monitor called the BIOS for a lot of stuff -- or you can write your own basic OS. Really, it comes to the same thing.

Here's a suggestion. Try a simple hello-world style program (put your name on the screen in green, say). To get this far, you'll need some sort of bootloader, a working knowledge of some hardware interfacing, and either a cross-compiler targetted at a freestanding implementation of your CPU or one that will compile to pure binary format (rather than, say, MACH-O or ELF or COFF). Building a cross-compiler toolchain isn't really that hard, especially for a freestanding environment (hint: grab the GCC sources, binutils toolchain, and newlib runtime).

Anything else will require some sort of library, of only because the OS requires it in a hosted implementation.

Of course, once you've accomplished this, you might consider going really hardcore.

Share this post

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

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!