Thread: turbo? clean? basic? Is C still a contender?

  1. #16
    Registered User
    Join Date
    Mar 2002
    Posts
    18

    C can do Anything VS Portability

    I forgot to log in.
    "Anyone have an apt analogy?" was me...
    Alex

  2. #17
    S­énior Member
    Join Date
    Jan 2002
    Posts
    982
    Wrong. C can be used to do _anything_, including a graphics engine as sophisticated as you could imagine. No third party libraries necessary.
    snip...
    So, if you know this, it is very easy to see how C or C++ for that matter, may be used to write a graphic engine of any level of sophistication-- all you're doing is changing data in RAM based on a specific set of rules which allow interpretation what those data changes mean (why is one pixel yellow, and the other turquois, for example).
    While this is possible. It can in no way be described as portable (unless you plan to write alot more than interactive graphic programs). There's nothing in the C standard that guarantees that you'll have access to the video memory of whatever platform you're working on.

  3. #18
    Unregistered
    Guest
    >C can be used to do _anything_, including a graphics engine as sophisticated as you could imagine.

    Yes C can be used to do _anything_. But why you would like to reinvent a wheel.

    There is joke i receid as a mail forward:
    "How to recuite the programmers?.
    The answer is to ask them to hunt an Elephant.

    If the guy takes steel pipes and a mobile machine shop to Africa to build a perfect gun to suit the need, Then he is a
    --------who else, a C programmer. :-)."


    >There's nothing in the C standard that guarantees that you'll have access to the video memory of whatever platform you're working on.

    this is correct. Even if the platfrom which you are working on gives access to you to play with the Video RAM, the first best thing you can produce is a "Bruned down Monitor".

    Yes palying with VRAM can actually burn your monitor.


    --cheers

  4. #19
    Registered User xds4lx's Avatar
    Join Date
    Nov 2001
    Posts
    630
    Not everyone writes graphics libraries this way becauase they dont know the tricks that are being used in GL or DX. They are sooooooooooooo optimized to take advantage of the hardware that it would take someone like you or me years and years to even just start to come close to the optimizations in a library like that.
    "only two things are infinite, the universe and human stupidity, and im not sure about the former." - albert einstein

  5. #20
    Mayor of Awesometown Govtcheez's Avatar
    Join Date
    Aug 2001
    Location
    MI
    Posts
    8,823
    Is there even any guarantee in the standard that your platform will have VRAM?

  6. #21
    Unregistered
    Guest

    VRAM~platforms~?

    /*I am a newbie...*/
    Let's see if I understand something:
    - C could write a graphics program.
    - There are no standardized graphics libraries in "clean" C.
    - There are third party graphics libraries.
    - If I write code using these libraries (or, even make that african gun) there is no guarantee that my executable will run on any given, specific computer????
    Alex

  7. #22
    Registered User
    Join Date
    Mar 2002
    Posts
    18

    Hmmmmmmmm.....

    I logged-in.
    I posted.
    It came out as unregistered...
    Hmmmm....
    Alex

  8. #23
    Mayor of Awesometown Govtcheez's Avatar
    Join Date
    Aug 2001
    Location
    MI
    Posts
    8,823
    Right.

  9. #24
    Registered User
    Join Date
    Mar 2002
    Posts
    18

    Graphics Portability

    So...
    How would one write a program with interactive graphics and have it be widely portable; is it just the way it's compiled?
    Alex

  10. #25
    Mayor of Awesometown Govtcheez's Avatar
    Join Date
    Aug 2001
    Location
    MI
    Posts
    8,823
    Depends on how widely portable you mean. Like I said, I don't think that the standard ever guarantees the system you're on will even have VRAM.

  11. #26

  12. #27
    Sayeh
    Guest
    Sorry I've been away from this. I've read all the exciting replies and my fundamental statement is still true-- most of you still don't understand how a computer works.

    Having written entire graphic libraries many times that cross-compile to as many as 12 platforms without code modification, using ISO/ANSI standard C... I know something of what I speak.

    Let's start off with basics--

    ------------------------
    a) What is VRAM.

    VRAM = "Video Random Access Memory". Every computer has it on the video hardware. You, as a programmer never have to access it directly-- that's what the video hardware is there for-- copying information out of RAM into VRAM.

    Have any of you ever heard the term "overlay"? or "memory mapped"?-- that is what this is. All post 1980 micro-computers do it. Essentially, your O/S is written so that when things start up and get interesting, it sets aside an address range from your normal RAM. This contains your "screen buffer" (your desktop, if you will).

    For our purposes, we will throw out arbitrary addresses. The actual address isn't important, just the concept:

    0x00003BC1
    ########################### <- RAM bytes

    No when the video card starts up, part of it's configuration tells it where in memory your screen RAM is allocated (0x00003BC1). It then 'virtually' maps its own VRAM addressing to the screen RAM. This is transparent to you. Hardware is _always_ faster than software, that's why this is done this way. It ends up "mapping" the VRAM to the RAM this way:

    0x00003BC1
    ########################### <- screen RAM bytes

    ########################### <- video VRAM bytes
    0x00000000

    If you change any value at an address in your 'screen RAM', that value is immediately and instantly copied into VRAM by the video hardware.

    How did you think DirectX or any other graphics library you use works? It's just that easy, and you can prove it to yourself, by locating the address for your screen RAM, make a loop that counts to a thousand, and then just start changing the contents of consecutive addresses in screen RAM to an arbitrary value (like 0x00), and watch the screen when it runs. You'll see a line appear. If you are dealing with VGA or EGA style graphics. video ram is organized differently (RGB planes), but the same principle still applies.

    What makes libraries like DirectX or OpenGL useful, is that the designers have gone to the effort to put all the other code in, that checks for hardware compatibility, clipping, off-screen bitmap support, etc. A daunting task, but doable. They cannot write code that works any faster than you can, so that's not the reason graphics libraries are special. You just have to know what you're doing.

    So in truth, you're not directly accessing VRAM, you're changing it indirectly through directly changing screen RAM. This keeps you safe so you can't damage anything and don't have to worry about performing the low-level stuff you'd actually have to do to write to the VRAM itself. You _cannot_ damage your hardware by writing to screen RAM. It isn't possible. Anyone who says otherwise, is again, confused.

    ----------------------
    2) All video memory isn't the same

    Well, that's not exactly true anymore. Thank you to Apple Computer for developing the 'indexed color model' that all PCs use today. It was the _only_ way to support the massive number of colors while still allowing a reasonable ability to move all that data.

    If you want to understand indexed-color, color-lookup tables, and palettes, I am happy to explain that in another posting-- it is fairly exhaustive. For the moment, suffice to say that an 8-bit 'depth' means that each byte in screen RAM is used to display 1 pixel. If it was 16-bit color, then every 2 consecutive bytes would be required for a single pixel, and so on...

    ----------------------
    3) Why don't you (Sayeh) enlighten us as to how to write our own graphic libraries?

    Actually, in one of my first 2 postings, I already did. I've explained more, in #1, above.

    Look, if I were to write a routine to plot a pixel in a GUI environment today, it would look something like this (pseudocode), albeit much different and tighter for performande reasons:

    Code:
    void DrawDot(int x,int y)
       {
       unsigned char   *screenBits;
       long                   rowBytes;
       unsigned char   *dotByteP;
       int                     depth;
       long                   color;
    
       dotByteP = nil;                                /* init vars */
    
       screenBits = GetScreenRAM();        /* get address to display RAM */
       depth = GetDepth();                       /* get device's depth */
       depth/=8;                                       /* convert to bytes */
    
       dotByteP = screenBits->pixmap;    /* actual screen data base RAM address */
    
       if(y)                                                 /* need to account for 'y'? */
          {
          rowBytes = screenBits->width;   /* how wide is screen */
          rowBytes *= (long)depth;           /* account for pixel-size */
    
          dotByteP += (((long)y-1)*rowBytes);    /* calc y position in screen RAM */
          };
    
       dotByteP += ((long)x * (long)depth);   /* calc x position in screen RAM */
    
       color = GetColor();                         /* whatever color user set with fictitious function SetColor() */
    
       switch(depth)
          {
          case 0:                                        /* less than 8-bit depth */
            MaskAndShiftColor;
            break;
          case 1:                                        /* 8-bit color */
             *dotByteP = (unsigned char)color;
             break;
          case 2:                                        /* 16-bit color */
             *dotByteP = (unsigned short int)color;
             break;
          case 3:
             /* yada yada for a 24-bit value */
             break;
          case 4:
             /* and so on for a 32-bit value */
             break;
          };
       }
    That's how it works. Very straightforward (like most things in a computer), and not at all beyond any of your skills. You just have to have a _overview_ of how things work. None of it is 'magical'. You can do it too, frequently better than the author of whatever library you're using, because you have a specific objective/use in mind, whereas that author had to write _general_ code that could be applied to any use it might be subjected to.

    That is essentially a 'primitive' graphic library routine (create your own linkable library) to plot a pixel. I could do the same with a line, using Bresnehem's line algorithm. Same for an arc (which can be used to form a circle), a box, a fill, a polygon, and so on.

    ------------------
    4) How would one write a program with interactive graphics and have it be widely portable; is it just the way it's compiled?

    To answer one poster's question: almost that easy. You need to know two things: How does that specific platform display graphics (eg. how is the screen RAM accessed-- it might use 24-bit RGB octets, RGB planes, or indexed color. It might only like to work with long-words. screenRAM might need to have every row long-word aligned (for performance), and so on). The other thing you need to know, is how to write your code so that it compiles differently for the platform it's being compiled for.

    It's just that easy...

    Have fun, all!

  13. #28
    Registered User
    Join Date
    Mar 2002
    Posts
    18

    Sayeh Appears To Know Something...

    Hmmm...
    I'm tempted to copy that pseudocode but only after some of the others comment...
    I don't know enough to judge, yet.
    ----------------------------------------------
    Seems like posts are flushed here after about a month. Is this true?
    Alex

  14. #29
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145
    Now this was an interesting thread
    MagosX.com

    Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime.

  15. #30
    S­énior Member
    Join Date
    Jan 2002
    Posts
    982
    Care to elaborate how most of what you've just posted will work in a protected mode enviroment?

    Also isn't your explanation a over-simplification of how OpenGL and DirectX work? I don't believe either of them were primarily designed to create software renderers. Even alot of the GUI (non-3d) api calls are implemented in hardware, and accessed via the driver.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 10
    Last Post: 11-23-2007, 12:13 AM
  2. Remember Turbo? It is comming back
    By Mario F. in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 08-14-2006, 01:26 PM
  3. [ANN] New script engine (Basic sintax)
    By MKTMK in forum C++ Programming
    Replies: 1
    Last Post: 11-01-2005, 10:28 AM
  4. what are your thoughts on visual basic?
    By orion- in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 09-22-2005, 04:28 AM