Lets say someone wants to make a game engine from scratch.That means assembler.Here are some questions about that: 1.GPU: Everyone knows GPUs are way faster than CPUs.Eveyone wants smooth graphics.The question is how can we access the GPU and its functions ? How can we send data to it and see the result on screen ? 2.Any idea about how to make protected mode apps in BC++ 3.1 ? 3.Double buffering: "What is it ?",a popular question i''ve seen on this forums.But (maybe i''ve missed) i''ve never seen something about,let''s say,where from to allocate enough memory for buffers,(conventional,XMS,EMS,PM,V86 ?),what kind of memory do most games use for double buffering,and many other questions. Maybe these are stupid questions but i didnt find any answers to them.Thank you.

OK. Here''s how I know it:

quote:Original post by Andrew S
That means assembler.

Not nowadays, generally C/C++ coupled with todays hardware is quick enough for most games.

quote:Original post by Andrew S
1.GPU: Everyone knows GPUs are way faster than CPUs.Eveyone wants smooth graphics.The question is how can we access the GPU and its functions ? How can we send data to it and see the result on screen ?

Graphics programmers are able to use programmable vertex and pixel shaders using assembly for GPUs or using tools such as Cg or HLSL.
Also, currently, CPUs are still faster GPUs by quite a fair gap.

quote:Original post by Andrew S
3.Double buffering: "What is it ?",a popular question i''ve seen on this forums.But (maybe i''ve missed) i''ve never seen something about,let''s say,where from to allocate enough memory for buffers,(conventional,XMS,EMS,PM,V86 ?),what kind of memory do most games use for double buffering,and many other questions.

AFAIK, both buffers (current frame buffer & secondary, maybe more..) are kept in video memory on the graphics card. Although, I guess that depends on where you want it to be kept.

Are you referring to creating a game engine which would not need OS-level interfaces such as the Windows API and DirectX to run under? Or creating a game engine which will run under MS-DOS? you''ll have to clarify your questions. Also, what is your current experience level in programming?

"Sneftel is correct, if rather vulgar." --Flarelocke

henrym:
*Are you sure about that c++ speed ? Ill presume my code isnt super optimized,but im getting 140 clears/sec.Gl goes like 400 with a rotating cube.See the difference ?
*And CPUs arent faster than GPUs(talking bout graphics).Eveyone knows games have better performances in D3D,GL than in software.
*Anyway,you still didnt answer my question.I knew they use assembly (for GPU,isnt that normal assembly ?) but i was asking if you know any source code that does that,i mean to access those buffers or to send data to them if i cannot access them.

johnbolton:
*Yeah i know GL but i don like it.And i know what n-buffering is,except i dunno to implement it.But if henrym is right,then look at my reply for him.

Sneftel:
Mmmm,experience...Lets say i didnt do anything special till now but im documenting.I,personally,tend to say i know enough about GRAPHICS.Don think about algebra that involves the 2D or 3D.Thats pure math and isnt that difficult to understand.Im talkin bout the basic graphics.Anyway u can call be a beginner,i wont mind.Maybe this way u have to explain some things twice
And im talkin bout a general engine,like GL ie.Although i dont understand how does GL put a pixel in a window''s DC,but yeah,if is possible then the engine will be for a few platforms not for a specific one.

Anyway,i still didnt get an answer.The question is,i believe,very clear: "How to program the GPU ?" That means without any help,CG,HLSL.I.e. write my own code for glVertex3f, IF thats possible.

The answer to the question "How do I program the GPU, without any sort of API help":

You can''t. The details of each GPU are proprietary, exported only through the drivers the manufacturers make available. Some effort has been made towards reverse-engineering certain chipsets, for example to write drivers under linux, but that''s extremely limited. Nobody really does it on PC''s. And you''d have to rewrite the code for every different GPU. In conclusion: No.

"Sneftel is correct, if rather vulgar." --Flarelocke

There must be something about ports.Everything is about ports in the computer when talkin bout I/O devices.Even interrupts use ports.Do they have anything to do with the GPU ?

so openGL and D3D aren't "engines", they are graphics libraries.

the short on how they access the GPU is that each video card vendor writes its OWN code (called a driver) to allow openGL and D3D to write to the card. drivers are specific to the chipset of the card (at a base level NVIDIA or ATI chipsets, but there can be specialized hardware that is unique to certain vendors). moreover much of the GPU architecture is secret to the vendor, i.e. you can't learn how it works so you can't write the driver. this pretty much makes it impossible for a lay-developer to write any kind of code to use the GPU effectively without using the D3D or openGL libraries. you'd have to write different code for each possible video card on the market if you wanted to use your program on any computer that has a different video card than you do. plus you'd have to understand the hardware to the deepest level in order to get anywhere near the performance that vendor drivers get. and like mentioned earlier, that information is secret.

basically, use openGL or D3D, don't try to write your own drivers unless you really want to and unless you have infinite amounts of time to learn about the innerworkings of the hardware.

-me

[edited by - Palidine on March 29, 2004 6:29:05 PM]

sneftel:
VESA SVGA works on all video cards.That means that all cards have something in common.But i think u may be rite bout the drivers.Then the games companies buy those drivers codes or they make their engines just like me,with what they have ?

game companies make their 3D accelerated engines with either D3D or openGL. that''s it. there are no other 3D APIs that will be accelerated by the GPU.

yes, the cards have underlying commonalities for displaying older graphics modes. however all of the GOOD stuff for us, i.e. the 3D acceleration, is the secret stuff that you can''t write a driver for.

-me