We are required to do pixel level manipulation for contrasts, affine transformations, etc. Right now I'm struggling with simple fixed axis rotation :{
Something is wrong with my matricies. :{ Tomorrow I"ll have to fix that, then I have to impliment linear and bilinear interpolation into the mix.. sigh.
OpenGLDirect3DSDLAllegroWin32 GDI
I personally use OpenGL, but there's no best choice.
I know that Win32 is an API. There is a DOS API, and I believe that Swing and AWT are Java API's. In fact, most anything can be an API. But those are probably the most widely used. Here's an instance of your own API. Say you have a GUI built on Win32 or Windows Forms(C#/VB), and then you had a SQL server in the background to throw out some infor when you needed it. Well, let's say you were a smart programmer, who didn't write stored procedures on the SQL server, and didn't embed SQL calls inside your GUI. :p But instead you decided to create an interface between the two distinctly different realms.GUI <---> ? <---> SQL DBWhat goes in that '?'Well, that's where your own API comes in. You write an interface class(object) to sit between them. For instance, if it dealt with customers, your GUI would call.. maybe Query.GetCustomer( ).This Query class would abstract EVERYTHING DB related away from the GUI. The GUI would have no clue that it's talking to a Database. Which is nice.. because what if it's not.. Let's think about that. So now we have to think.. Is Query itself an true concrete class? No, why should it be. It should be an Interface, or Abstract class. Now we can build a whole bunch of classes that can extend Query. DBQuery, SQLDBQuery, FlatFileQuery, ODBQuery, etc. They would all inherit from Query, so your GUI wouldn't know the difference. Now let me redraw the picture..GUI <---> Query <---> ?Now the ? is in a great place. That means the GUI has no clue whats in the ?. You can put ANYTHING there. As long as you write an appropriate Query class for it. So now I've built a Query API for my application. It's just an interface, so you MUST implement the methods in each inherited class. But this is very very powerful.I talk to much.
Here's an instance of your own API.
Say you have a GUI built on Win32 or Windows Forms(C#/VB), and then you had a SQL server in the background to throw out some infor when you needed it. Well, let's say you were a smart programmer, who didn't write stored procedures on the SQL server, and didn't embed SQL calls inside your GUI. :p But instead you decided to create an interface between the two distinctly different realms.
GUI <---> ? <---> SQL DB
What goes in that '?'
Well, that's where your own API comes in. You write an interface class(object) to sit between them. For instance, if it dealt with customers, your GUI would call.. maybe Query.GetCustomer( ).
This Query class would abstract EVERYTHING DB related away from the GUI. The GUI would have no clue that it's talking to a Database. Which is nice.. because what if it's not..
Let's think about that. So now we have to think.. Is Query itself an true concrete class? No, why should it be. It should be an Interface, or Abstract class. Now we can build a whole bunch of classes that can extend Query. DBQuery, SQLDBQuery, FlatFileQuery, ODBQuery, etc. They would all inherit from Query, so your GUI wouldn't know the difference. Now let me redraw the picture..
GUI <---> Query <---> ?
Now the ? is in a great place. That means the GUI has no clue whats in the ?. You can put ANYTHING there. As long as you write an appropriate Query class for it.
So now I've built a Query API for my application. It's just an interface, so you MUST implement the methods in each inherited class. But this is very very powerful.
I talk to much.
Wow that was concise and it makes me want to get a book even more but im still poor lol. Thanks for the info
automatic program intro? lol... i find this useful... so i will have an idea has to what i will learn next school year!