making a 3d "api"

Started by
5 comments, last by bilsa 20 years, 4 months ago
Hia! Ok, I have been thinking on making my own little 3D api just for fun. But I have no clue at all where to start, heh What I'm aiming for is making it possible to draw pixels to the screen, making up 3d objects, printing textures on the objects etc... And I don't want to use DX functions or something like that to draw lines and pixels, I would actually want to send the vertices - or pixels or whaterer directly to the Graphic card. With this I dont mean that I want to use OP codes and send them directly to the graphics cards... since i would want it to work on as many cards a s possible... I'm guessing that I should learn how to use the graphic cards drivers installed on a particular OS and try to make an application that uses the installed grapchi card drivers? Actually thats the part that I got no clue about how to make... The 3d maths and other stuff I think I will be able to handle on my own. Would appreciate any help on this topic! thank you ! [edited by - bilsa on November 27, 2003 11:56:07 AM]
Advertisement
I could be wrong here, but as far as I''m aware there are only two 3d graphics api''s that hardware vendors generally incorporate into their graphics drivers: OpenGL and DirectX.
If you wanted to create your own 3d api that could access 3d routines, you would have to reverse compile the graphics drivers to find out how they access the card.

I hope that''s a least vaguely helpful, but as I say, i''m probably incorrect :/
Seems like your idea of a driver is wrong. A driver is an interface between the graphics card hardware (all its ports, AGP bus access etc) and OpenGL/DirectX API calls. So "using the driver" would be to write an OpenGL or DirectX application. At least that is how I see it. So either you write something totally low-level working directly with the card, or you have to work with DirectX or OpenGL using existing drivers.
This is a noble goal, but sadly I don''t think its possible. Manufacturers guard the details of their drivers and hardware very, very closely, and so the chances of an independent developer managing to write an API that can communicate with all the various drivers in production is very slim. The whole point of DX/OGL is to protect developers from the nastiness of video hardware anyways; I for one still remember the old days of writing specific drivers for each video card you wanted to support, and my memories are not fond.

To do this you''d literally have to reverse engineer every video card you want to support and write a custom interface to the card''s drivers. You could quite likely do this for a few cards, but you''d end up spending all your time trying to talk to the drivers instead of getting your API written. Besides, there''s a good chance you could be sued for reverse-engineering trade secret technology.

Its a big risk, and I doubt you''d manage to get a working API without a huge amount of effort; regardless, you''d never have a chance of competing with DX/OGL. If you''re interested in the learning experience of hacking apart drivers and working with low-level hardware, then by all means, go for it; I learned a lot about video hardware doing that myself (unfortunately all of my knowledge is 6 years old and entirely worthless). But if you just want experience writing an API of some kind, there are better ways; I''d suggest writing a plugin API for a small application, or a custom GUI library, etc.

Please don''t take this as a flat out "you can''t do it" - just be warned of the risks involved, and be prepared to put out a huge effort and maybe not see much return. If you''re up for it, I wish you good luck; the industry needs more people with the insanity to tackle this kind of challenge just to learn a few things.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Yeah, an opengl driver is simply an opengl interface to the graphics card... that API IS the general interface to each different graphics board, so if you write an API and want it to support multiple graphics board, you''d either A.) have to use d3d/opengl for hardware access (until you or someone else can fill in the hardware interface later), or B.) write a lot of drivers for each board (rather than reverse engineering drivers, you could find documention from linux and other sources).
Plus, if you don''t know what you''re doing, you could potentially damage the GFX card hardware by sending weird signals, etc.
If you feel the need to be able to access video HW features without DX or OGL in your way just for fun, you could try messing with some videogame consoles. Recently their design became a lot more similar to PCs''.

Major options are the Playstation2, the X-box and the Dreamcast.

The PS2 has a more unique hardware, but you have an official tool for homebrew dev experiences: the Linux kit. You can buy that and have loads of fun messing with the HW.

The X-box offers lotsa power, and looks a lot like a PC, but I''m not sure you can get really low level on it''s video hardware. You''ll also need some obscure gear to get your own code to run on it.

The Dreamcast is very cheap nowadays, has a PC-ish design, but it''s possible to go low-level on it (it''s dev docs - including the video card''s register mappings and other stuff - are all over the net). You can also build a cable to test your code without using CDRs, and there are some libraries out there that can help you. There is the illegal WinCE dev kit, but there are also open-source libraries, like KOS, that also come with source, so you can find out how it''s controlling the system.

This topic is closed to new replies.

Advertisement