Jump to content

  • Log In with Google      Sign In   
  • Create Account


C or Assembler Graphics Library independent of an OS


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
14 replies to this topic

#1 Spirrwell   Members   -  Reputation: 263

Like
0Likes
Like

Posted 22 August 2012 - 09:33 AM

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?

Sponsor:

#2 Hodgman   Moderators   -  Reputation: 29304

Like
0Likes
Like

Posted 22 August 2012 - 09:35 AM

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.

Edited by Hodgman, 22 August 2012 - 09:43 AM.


#3 Spirrwell   Members   -  Reputation: 263

Like
0Likes
Like

Posted 22 August 2012 - 12:22 PM

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.

#4 saejox   Members   -  Reputation: 714

Like
0Likes
Like

Posted 22 August 2012 - 12:35 PM

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.

#5 SimonForsman   Crossbones+   -  Reputation: 6035

Like
0Likes
Like

Posted 22 August 2012 - 12:51 PM


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 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)
I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#6 Ravyne   Crossbones+   -  Reputation: 7116

Like
1Likes
Like

Posted 22 August 2012 - 01:55 PM

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.

#7 nfries88   Members   -  Reputation: 259

Like
0Likes
Like

Posted 22 August 2012 - 02:25 PM

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.
Looking for paid or open-source C++ programming work. Been programming since 2005. No degree.

#8 carangil   Members   -  Reputation: 490

Like
0Likes
Like

Posted 22 August 2012 - 02:31 PM

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 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?

#9 Bacterius   Crossbones+   -  Reputation: 8483

Like
0Likes
Like

Posted 22 August 2012 - 02:56 PM

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)

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#10 Ravyne   Crossbones+   -  Reputation: 7116

Like
1Likes
Like

Posted 22 August 2012 - 04:58 PM

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.

#11 carangil   Members   -  Reputation: 490

Like
0Likes
Like

Posted 22 August 2012 - 05:13 PM

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.


Yeah, but I can play one of those retro games in a 100% software emulator at full speed! cough, DOSBOX, cough. There is however a difference between rendering at 640x480 (or even 320x240, which was very popular in the DOS days) vs targeting a modern 1080p display, and I realize that.

But...

1920×1080 = 1.7 megapixels
640x480= .3 megapixels

1.7/.3 = 5.6 times more pixels

This is only a guess, but if DOSBOX can play an emulated 2D game at 640x480, I would have to guess similar quality software rendering running natively in C ought to be at least 5 times faster. Probably even more. You're not going to get graphics-card level of alpha blending and anti-aliasing, but a lot of games got away without it. Fancy acceleration wasn't really necessary until 3D. (There were accelerated bitblt calls for 2D, sometimes with masking, rarely with alpha, but anything specific, like special wiggly effects, were done pixel-by-pixel in software.)

#12 Spirrwell   Members   -  Reputation: 263

Like
0Likes
Like

Posted 22 August 2012 - 05:16 PM

Okay, there seems to be a lot of routes I can take, far too many. I do like the idea of using a Linux operating system with the ability to use OpenGL. Basically all I need right now is a Linux OS that comes with all of the GNU compiling stuff. If I wanted to write a program with something like OpenGL or using the SDL API, can this be done without a desktop environment\window manager so all I'm working from is the console erminal with no GUI whatsoever?

Also, is there any IDE or text editor with syntax highlighting and whatnot that can run from within the console erminal, something similar to Turbo C++ for DOS?

#13 nfries88   Members   -  Reputation: 259

Like
0Likes
Like

Posted 22 August 2012 - 05:47 PM

SDL 1.2 supports rendering to the Linux framebuffer, so yes you can do that.

However, I'm not sure about SDL+OpenGL in that situation, and I don't know of any syntax-highlighting editors that run from the terminal.

Edited by nfries88, 22 August 2012 - 05:48 PM.

Looking for paid or open-source C++ programming work. Been programming since 2005. No degree.

#14 carangil   Members   -  Reputation: 490

Like
0Likes
Like

Posted 22 August 2012 - 06:30 PM

If I wanted to write a program with something like OpenGL or using the SDL API, can this be done without a desktop environment\window manager so all I'm working from is the console erminal with no GUI whatsoever?


What's your motivation to not use the GUI? It sounds painful. To someone new, this will be almost impossible to follow. I do programming on a 'pure' console all the time at work: I'm often logged in over ssh to a server where my code actually lives, and can I do a lot with screen, cscope, vim, gdb and make. I spend 90% of my time on the console. But, even with all that 'console goodness', I still fire up a graphical source control app to browse the code tree, and I use a GUI diff program! And if I'm logged into multiple machines, I don't try to multiplex them all down 1 screen instance; I open a new console window! GUIs are meant to save you time and confusion.

Here's the bad news: All the 'good' graphics drivers will require X, and just about anything that will create an opengl context for you will be assuming you're doing it in X. OpenGL on Linux without X will most likely be a no-go. Maybe you can get DirectFB working, but that's mostly for embedded devices.

Embrace the GUI. If you want something minimal look at OpenBox.

Also, is there any IDE or text editor with syntax highlighting and whatnot that can run from within the console erminal, something similar to Turbo C++ for DOS?


VIM or Emacs, but trying to learn those while at the same time learning programming will be an exercise in frustration.

Edited by DracoLacertae, 22 August 2012 - 06:32 PM.


#15 Spirrwell   Members   -  Reputation: 263

Like
0Likes
Like

Posted 22 August 2012 - 07:10 PM

Well it's not so much that I don't want X, it's more of a learning experience. Plus, I don't even know how to make Linux boot directly into a program or game with X... Come to think of it I don't know how to do it without X either. Also it's not that I'm learning how to program, it's that I'm learning the different things I can do with programming. I've programmed with SDL and OpenGL before, but not for this purpose.

Anyway, let's assume I have a small program made with OpenGL\SDL that displays a picture, a box, or whatever. What utility would I use to strip down a Linux distribution and give it the sole purpose of running that program so I could run it from a Live CD\USB? That's what I really need to know.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS