I've been searching high and low for a graphics library that can be used that doesn't need an operating system to run. Even if it's something simple like a 2D library that allows the ability to draw lines, quadrilaterals, triangles, and maybe even circles with the ability to alter their colors, and possibly even pixel manipulation.
Is there anything of the sort that can run without an operating system?
C or Assembler Graphics Library independent of an OS
I'm not sure why you want this, but you're probably looking for something like Mode 13h...
You realise that to run a renderer without an operating system though, means that your renderer is an operating system. You'll be talking to the hardware directly, so you're now no longer dependent on an OS, but you are dependent on a certain hardware architecture.
You realise that to run a renderer without an operating system though, means that your renderer is an operating system. You'll be talking to the hardware directly, so you're now no longer dependent on an OS, but you are dependent on a certain hardware architecture.
Author
You realise that to run a renderer without an operating system though, means that your renderer is an operating system. You'll be talking to the hardware directly, so you're now no longer dependent on an OS, but you are dependent on a certain hardware architecture.
I do. Essentially, I've always been curious about the idea of putting a CD\DVD in a computer to play a game and using a hard drive\flash drive for storing things like saved data. Or perhaps having an entire game on a USB device that works as a "key" to play a game.
I've asked around on here before about the idea of making an operating system, and this is what I've been thinking about. I'm aware of mode 13h, and I'm clearly not qualified to build from it or something. That's why I'm looking for a library of sorts that may have some functionality built in already that's basically its own operating system that is capable of true color, which as far as I know mode 13h isn't capable of.
you will be writing your own operating system complete with its drivers.
or,
get a permissive open source OS like OpenBSD. (if you want to sell your game)
strip away all the components you dont need.
this way you may boot up your game directly.
and good part is you will have opengl to work with.
or,
get a permissive open source OS like OpenBSD. (if you want to sell your game)
strip away all the components you dont need.
this way you may boot up your game directly.
and good part is you will have opengl to work with.
[quote name='Hodgman' timestamp='1345649755' post='4972231']
You realise that to run a renderer without an operating system though, means that your renderer is an operating system. You'll be talking to the hardware directly, so you're now no longer dependent on an OS, but you are dependent on a certain hardware architecture.
I do. Essentially, I've always been curious about the idea of putting a CD\DVD in a computer to play a game and using a hard drive\flash drive for storing things like saved data. Or perhaps having an entire game on a USB device that works as a "key" to play a game.
I've asked around on here before about the idea of making an operating system, and this is what I've been thinking about. I'm aware of mode 13h, and I'm clearly not qualified to build from it or something. That's why I'm looking for a library of sorts that may have some functionality built in already that's basically its own operating system that is capable of true color, which as far as I know mode 13h isn't capable of.
[/quote]
you could go with VESA which allows a bit higher resolutions, beyond that nothing is standardized though, you could bundle your game with a Linux distro to get it booting from a CD or DVD but you can't ship drivers for hardware that doesn't exist yet. (Yes, you can sell a Linux distro bundled with proprietary software)
There are tools for creating live CDs and DVDs with a variety of Linux flavors. It'd be easier to live-boot a minimal Linux that goes directly into your game -- however, it's difficult to support the wide variety of hardware out there, especially if you don't want to bloat your image.
If you're not interested in or capable of writing your own OS, and you're not interested in or capable of writing the low-level graphics routines you'll need, then building on an existing OS is really the only option that's even remotely viable.
If you're interested in making a game, just target a standard OS and get on with it.
If you're not interested in or capable of writing your own OS, and you're not interested in or capable of writing the low-level graphics routines you'll need, then building on an existing OS is really the only option that's even remotely viable.
If you're interested in making a game, just target a standard OS and get on with it.
If you're looking to make your own OS for a limited purpose such as a game, I highly recommend considering Minix3 rather than a more generalized system. Minix3 is designed to be small and stable.
You realise that to run a renderer without an operating system though, means that your renderer is an operating system. You'll be talking to the hardware directly, so you're now no longer dependent on an OS, but you are dependent on a certain hardware architecture.[/quote]
I actually read this question white differently than what Hodgman interpreted this as. Of course you need an OS, unless you want to boot directly off a CD to run your program. I interpreted this as asking for something that isn't tied to a particular OS (say Windows GDI), a popular library (GL), or to a particular flavor of hardware (Pixel Shaders > 2.0, etc)
My answer to this would be a software rendering graphics library that draws off-screen to a virtual framebuffer. A generic C library that just mallocs a block and ram and draws into it as if it's a framebuffer. A renderer written like this which uses a nearly ubiquitous format such as R8G8B8 or R8G8B8A, etc would be very powerful, because you can write very custom pixel-perfect 2D graphics without being dependent on any particular graphics capabilities. If you're writing a 2D platformer, an arcade shooter, etc, software rendering is more than enough power.
I would suggest you start with something simple that run on your platform (are you Mac, PC?), something like SDL or PixelToaster that will just let you write a simple 'main loop' that quickly displays the contents of a bitmap onto the screen. Then write all your drawing routines. Drawing lines and shapes pixel-by-pixel into a bitmap will give you the experience of developing your own graphics routines as if you were drawing 'into the hardware,' but without a lot of the frustration of actually talking with the hardware. And, if your graphics routines are well-separated from the main program, you would have succeeded in both knowing how graphics really works AND have created the OS-agnostic, hardware-agnostic graphics library it sounds like you are looking for.
Suggested organization:
Main Program Loop:
-process gameplay logic
-calls functions to SoftRenderer to do all drawing
-passes output framebuffer of SoftRenderer to Outputter
-repeat
SoftRenderer:
-contains functions such as drawline, bitblt, which draw into the 'virtual framebuffer'
-contains no 'system' functions (maybe just malloc/free and thats it!)
-does NOT call SDL or any other graphics library
Outputter:
-takes whatever SoftRenderer did and puts it on the screen
Do the above, and you can keep Main and Softrenderer, and just change Outputter to fit whatever OS you want to port your code to!
One thing I do find surprising: I spent a couple of minutes on Google with this, and while Qt, Win32 GDI, Cocoa, GTK all let you render just about anything that would go into the screen to a bitmap, I can't find a generic (draw me lines, circles and bitblits to some generic framebuffer) library out there! Someone has to have done this before, or am I just crazy?
One thing I do find surprising: I spent a couple of minutes on Google with this, and while Qt, Win32 GDI, Cocoa, GTK all let you render just about anything that would go into the screen to a bitmap, I can't find a generic (draw me lines, circles and bitblits to some generic framebuffer) library out there! Someone has to have done this before, or am I just crazy?
It isn't too difficult to code something like this yourself if you know some math and geometry (of course you'll be spending time polishing it, adding anti-aliasing, etc...). Though I suspect the reason there is none is because it is far too generic a library, so unlikely to be of much use to anyone.
Also, don't overestimate the performance of a software renderer. Sure, drawing a few lines here and there, blitting a texture, aren't computationally expensive tasks. But consider people who want to add post-processing to some sections of their game (which is a fairly iconic component of retro games, wiggly distorted "heat effect" anyone?) - this would require iterating over a significant fraction (sometimes the totality) of the framebuffer, which can very quickly defeat even the fastest processor. There is a reason GPU's exist, and it's not just the triangle count.
Of course, it would be interesting as an experimental project... both as a proof of concept and as valuable programming experience (not really "cross-platform" though, evidently)
Also, don't overestimate the performance of a software renderer. Sure, drawing a few lines here and there, blitting a texture, aren't computationally expensive tasks. But consider people who want to add post-processing to some sections of their game (which is a fairly iconic component of retro games, wiggly distorted "heat effect" anyone?) - this would require iterating over a significant fraction (sometimes the totality) of the framebuffer, which can very quickly defeat even the fastest processor. There is a reason GPU's exist, and it's not just the triangle count.
It shouldn't be underestimated either, though -- It's not too hard to push a few million average-sized, flat-colored triangles per second on a software renderer at moderate resolutions. Blits and texturing aren't too onerous if you're mindful of the cache either.
And emulating the old affects like the heat-wave you mention isn't a problem if you model your graphics engine after the graphics chips of the day, instead of drawing everything immediately to a framebuffer. If you retain the draw calls and allow parameters to be manipulated between scan lines you can get most of those effects for free. Even the SNES's famous mode 7 was just a roto-zoom with its control registers changed between scan lines.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
