Ok, I was reading the discussion of "2600, DOS, and yes, game programming" and i have a few questions. 2600 and XCHG were talking about programming directly to hardware instead of using APIs or libraries and a big deabte over assembly. My question is how is this done? How do you program directly to a graphics card instead of using an API? Is this faster? Is knowledge of assembly needed, or is C/C++ fine? And what does John Carmack do do get such stunning graphics at such great framerates? Does he do something along these lines? I know he uses the OpenGL API because I''ve heard it everywhere and he got an award for best use of OpenGL. I also read in an article of his that if he could, he''d write staright to the metal? Anyways, yes try to answer as many of these questions as possible, all info would be appreciated.

How is this done? It''s not... pay no attention to them Stick with C/C++ and learn it well... The only benefit I see from assembly comes from what you learn about how a program actually works (the stack, overhead from function calls, and lots of other things)... though reading a good book on computer architecture will help with this too and teach other more advanced topics (cache hit/miss ratio, hazards, branch prediction/misprediction overhead, etc)... in order to write assembly better than a compiler could you have to understand these things cause compilers are pretty damn smart nowadays (eg Intel''s new release of ICC).. anyway...

Back in the day you were able to write directly into video memory... this was just how it worked... devices would read data directly out of main memory that a program could write into... nowadays you couldn''t do this even if you wanted to... even if there were RAM directly mapped to the video memory (which there isn''t) the operating system wouldn''t let you access it (operating systems nowadays distinguish between a Real Mode and a Protected mode.. or User and Kernel mode.. or whatever you want to call it which hide a good bit of the machine (for example - a large chunk of memory) from your process for safety/stability/ease of use etc etc reasons)...

As for John Carmack... he knows his stuff... and has been programming games since I can remember playing them... the Quakes were all done in C (and possibly some assembly I''d imagine) using OpenGL... he just uses some of the best emerging technologies and does them well, plus some very efficient use of the hardware, and things end up being fast (go figure)

As for writing directly ''to the metal''... he was probably just feeling nostalgic or something Besides, I really doubt that''ll ever be the case on a desktop PC again and I can safely say I''m glad

peez out - noh

quote:Original post by CannoN346
Ok, I was reading the discussion of "2600, DOS, and yes, game programming" and i have a few questions. 2600 and XCHG were talking about programming directly to hardware instead of using APIs or libraries and a big deabte over assembly. My question is how is this done? How do you program directly to a graphics card instead of using an API? Is this faster? Is knowledge of assembly needed, or is C/C++ fine? And what does John Carmack do do get such stunning graphics at such great framerates? Does he do something along these lines? I know he uses the OpenGL API because I''ve heard it everywhere and he got an award for best use of OpenGL. I also read in an article of his that if he could, he''d write staright to the metal? Anyways, yes try to answer as many of these questions as possible, all info would be appreciated.

To program hw directly, you would have to know the actual hw specifications (pretty much trade secret these days). And on protected mode systems like WinNT, you can''t do this directly through your application code, you will need to go through a kernel-level driver. As to whether asm is needed, well that depends on how the hw is accessed I guess. hw which supports memory mapped io can be accessed using C pointers and directly hardwiring the pointer to the mem-map addresses. hw which uses port access will require some kind of asm-level io instruction to access hw ports. vc has the inp/outp functions but that''s kindof compiler specific.

And no, I doubt JC would "pedal to the metal" anymore these days. Given today''s processing speeds, most optimizations are done at the architectural and algorithmic level, unless perhaps you''re working w consoles where asm optimizations is still a necessary thing.

Today I wouldn''t program a grpshics hardware directly. For each video card you would have to programm your own layer that translates the needs of your application to the correct HW manipulations. So unless you develop your software for a particular HW I don''t think you would gain much additional performance, since you always need some sort of layer.

And you would never be able to use nvidia cards, since this company makes a vere big secret around their HW specs (see linux drivers).

And beating a good compiler with your own assembly isn''t that easy anymore with todays complex CPUs. There are so many components working in parallel that it is hard to see the dependencies of instructions by just looking at the code. But most compilers don''t automatically use the vector extensions supported by the latest CPUs (ISSE, MMX, Altivec,...)

So my conclusion:
- You can''t reach a broad audience when you programm video HW directly.
- Use assembly only when you kno exactly what you''re doing and then only in the most time critical parts of your code (don''t waste time with optimizing code that will almost never be called).

Ok, thank you very much so far for the replies. Also, I''m pretty sure the article I read where Carmack said that was from 1996. Were APIs just starting to hit the scene at this time, and maybe a comment such as writing staight to the metal made more sense?

quote:Original post by CannoN346
Ok, thank you very much so far for the replies. Also, I''m pretty sure the article I read where Carmack said that was from 1996. Were APIs just starting to hit the scene at this time, and maybe a comment such as writing staight to the metal made more sense?

I believe if u read the article more carefully, he said something along the lines of "if there was one similar line of hw which majority of the market was using, I would write straight to the metal". Well, given the fragmented nature of today''s hw, this is clearly not the case. It would be impossible to get any kind of compatible hw acceleration without a standardized api to write to.