OS Graphics

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
User avatar
bewing
Member
Member
Posts: 1401
Joined: Wed Feb 07, 2007 1:45 pm
Location: Eugene, OR, US

Post by bewing »

Brynet-Inc wrote:You have very little hope to use any of the proprietary hardware 2D/3D acceleration abilities. (Or other features..)
vanillasnake21 wrote:but is there any way to port the drivers to a custom OS? Or at least configure the os in a certain way that it will be able to use the driver written for a different os?
Brendan wrote:That wouldn't necessarily be easy either. To support Windows drivers you'd need to implement half of Windows ...
Brendan & Brynet -- are you sure about that? If I were writing a super fast accelerated graphics driver for Windoze, for my proprietary graphics card, the very last thing I'd do is call many Windoze APIs -- if I could possibly avoid it. I've been thinking that I am intending to try to do precisely what vanillasnake21 is suggesting? Maybe just for one specific board. But it seems to me that the number of API calls that I'd have to mimic within my OS, to get a particular graphics driver running should be smallish -- and therefore doable. I certainly don't want to have to port WINE onto my OS, I admit.
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Post by Combuster »

It has nothing to do with WINE. Drivers run in kernel land and are built with the DDK. You should check that for a list of calls the host should provide. Given the multilevel nature of windows drivers, and the amount of control bestowed on the drivers, that is probably a lot.

But then again, everything is relative. One should actually try it to see how many 'undefined reference''s there appear on the screen :wink: If you find the keyboard controller difficult, then this is most certainly nothing for you.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
jnc100
Member
Member
Posts: 776
Joined: Mon Apr 09, 2007 12:10 pm
Location: London, UK
Contact:

Post by jnc100 »

How about something along the lines of ndiswrapper?

Regards,
John.
Tyler
Member
Member
Posts: 514
Joined: Tue Nov 07, 2006 7:37 am
Location: York, England

Post by Tyler »

bewing wrote: Brendan & Brynet -- are you sure about that? If I were writing a super fast accelerated graphics driver for Windoze, for my proprietary graphics card, the very last thing I'd do is call many Windoze APIs -- if I could possibly avoid it. I've been thinking that I am intending to try to do precisely what vanillasnake21 is suggesting? Maybe just for one specific board. But it seems to me that the number of API calls that I'd have to mimic within my OS, to get a particular graphics driver running should be smallish -- and therefore doable. I certainly don't want to have to port WINE onto my OS, I admit.
By "Windows API" they mean the Kernel Exported Functions available to Kernel Mode Objects like drivers, as opposed to the Win32 API available to Applications. Basically it means implementing all functions exported by the ntoskrnl.exe, a serious job. Plus you need to implement a compatable Driver Model that means Windows Drivers won't conflict with native ones.

My operating system has a Userland ntoskrnl.exe that runs Windows Driver's (currently supporting only the WDM Graphics Model) in a manner similar to a microkernel, in order to protect the rest of my system. They run slower but i don't want permement support, only to make my system somewhat usable before i write the drivers.
User avatar
AndrewAPrice
Member
Member
Posts: 2311
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Post by AndrewAPrice »

Why do people keep wanting "32-bit colour"? Learn about video modes first. You have to implement 32-bit colour or higher in your OS yourself over the top of a 24-bit video mode, and just ignore the 8-bit alpha channel while rendering it (or blend it with the colour already occupying that pixel and claim you have "true" 32-bit colour).
jnc100
Member
Member
Posts: 776
Joined: Mon Apr 09, 2007 12:10 pm
Location: London, UK
Contact:

Post by jnc100 »

MessiahAndrw wrote:Why do people keep wanting "32-bit colour"? Learn about video modes first. You have to implement 32-bit colour or higher in your OS yourself over the top of a 24-bit video mode, and just ignore the 8-bit alpha channel while rendering it (or blend it with the colour already occupying that pixel and claim you have "true" 32-bit colour).
I haven't got this far yet, but I'd always assumed the difference (apart from the ability to do alpha blending) was that 32-bit was always dword aligned whereas 24-bit was packed and so required some interesting calculations to do bitblts? In that case, 32 bit colour seems easier.

Regards,
John.
User avatar
bewing
Member
Member
Posts: 1401
Joined: Wed Feb 07, 2007 1:45 pm
Location: Eugene, OR, US

Post by bewing »

Thanks for the tips, guys. When I get to that part, I'll let you know what I find. :wink:
Tyler wrote:Basically it means implementing all functions exported by the ntoskrnl.exe, a serious job. Plus you need to implement a compatable Driver Model that means Windows Drivers won't conflict with native ones.
Well, if it's implemented as a wrapper, then it only means implementing the exported functions that are actually used by a particular driver -- a not-quite-so-serious job. Plus emulating all implemented parts of the Windows Driver model. I would guess that it also would force me to use rectangles as my GUI primitive, ala Windows -- but that's OK, since I haven't gotten to the point of choosing my GUI primitive yet.
pcmattman
Member
Member
Posts: 2566
Joined: Sun Jan 14, 2007 9:15 pm
Libera.chat IRC: miselin
Location: Sydney, Australia (I come from a land down under!)
Contact:

Post by pcmattman »

MessiahAndrw wrote:Why do people keep wanting "32-bit colour"? Learn about video modes first. You have to implement 32-bit colour or higher in your OS yourself over the top of a 24-bit video mode, and just ignore the 8-bit alpha channel while rendering it (or blend it with the colour already occupying that pixel and claim you have "true" 32-bit colour).
32-bit takes four channels worth of information, hence it uses the full size of the type. I know from experience that 24-bit is a lot harder, because you have alignment issues.
I would guess that it also would force me to use rectangles as my GUI primitive, ala Windows -- but that's OK, since I haven't gotten to the point of choosing my GUI primitive yet.
Rectangles are used because they are the most spacious possible method of fitting data into a window. Circular (or any other shape) windows may look cool, but they just don't work nicely with the user. If you have some other primitive that works and gives more space than a rectangle, please mention it.
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

To solve the problem of Vesa or Vga or OpenGL other other driver, just use the abstract factory pattern. If you implement this from the beginning then your gui code does not need to change only add a driver and voila works.

as an example:

Code: Select all

#include <stdio.h>
#include <string.h>

typedef class Line {
    protected:  int _x1, _y1, _x2, _y2;
    public:     Line(int x1, int y1, int x2, int y2) : _x1(x1), _y1(y1), _x2(x2), _y2(y2) {}
    public:     virtual void draw(void) = 0;
} Line;

typedef class DrawDibLine : public Line {
    public:     DrawDibLine(int x1, int y1, int x2, int y2) : Line(x1, y1, x2, y2) {}
    public:     virtual void draw(void) {
                    printf("DrawDib::Line(%d, %d)-(%d, %d)\n", _x1, _y1, _x2, _y2);
            }
} DrawDibLine;

typedef class OpenGLLine : public Line {
    public:     OpenGLLine(int x1, int y1, int x2, int y2) : Line(x1, y1, x2, y2) {}
    public:     virtual void draw(void) {
                    printf("OpenGL::Line(%d, %d)-(%d, %d)\n", _x1, _y1, _x2, _y2);
            }
} OpenGLLine;

typedef class VesaLine : public Line {
    public:     VesaLine(int x1, int y1, int x2, int y2) : Line(x1, y1, x2, y2) {}
    public:     virtual void draw(void) {
                    printf("Vesa::Line(%d, %d)-(%d, %d)\n", _x1, _y1, _x2, _y2);
            }
} VesaLine;

typedef class GUIFactory {
    public: static  GUIFactory *    GetInstance(char *);
    public: virtual Line *          CreateLine(int x1, int y1, int x2, int y2) = 0;
} GUIFactory;

typedef class GUIDrawDibFactory : public GUIFactory {
    public: virtual Line *          CreateLine(int x1, int y1, int x2, int y2) {
        return(new DrawDibLine(x1, y1, x2, y2));
    }
} GUIDrawDibFactory;

typedef class GUIOpenGLFactory : public GUIFactory {
    public: virtual Line *          CreateLine(int x1, int y1, int x2, int y2) {
        return(new OpenGLLine(x1, y1, x2, y2));
    }
} GUIOpenGLFactory;

typedef class GUIVesaFactory : public GUIFactory {
    public: virtual Line *          CreateLine(int x1, int y1, int x2, int y2) {
        return(new VesaLine(x1, y1, x2, y2));
    }
} GUIVesaFactory;

GUIFactory * GUIFactory::GetInstance(char * type) {
    if(type != 0) {
        if(strcmp(type, "DrawDib") == 0) {
            return(new GUIDrawDibFactory);
        }
        else
        if(strcmp(type, "OpenGL") == 0) {
            return(new GUIOpenGLFactory);
        }
        else
        if(strcmp(type, "Vesa") == 0) {
            return(new GUIVesaFactory);
        }
    }
    return(new GUIDrawDibFactory);
}

int main(int argc, char * argv[]) {
    GUIFactory *        guiFactory = GUIFactory::GetInstance(argv[1]);

    /* actual gui calls for instance, button, window, etc.
    Line * line = guiFactory->CreateLine(10, 10, 246, 246);
    line->draw();

    return(0);
}
when you compile this you get and application say gui.exe and you can switch between modes with the first argument being either DrawDib, OpenGL or Vesa (case sensitive). The main function will not change however the behaivour does.
Author of COBOS
User avatar
AndrewAPrice
Member
Member
Posts: 2311
Joined: Mon Jun 05, 2006 11:00 pm
Location: USA (and Australia)

Post by AndrewAPrice »

pcmattman wrote:32-bit takes four channels worth of information, hence it uses the full size of the type. I know from experience that 24-bit is a lot harder, because you have alignment issues.
Create a char pointer and * it by 3.
My OS is Perception.
User avatar
os64dev
Member
Member
Posts: 553
Joined: Sat Jan 27, 2007 3:21 pm
Location: Best, Netherlands

Post by os64dev »

MessiahAndrw wrote:Create a char pointer and * it by 3.
Which is exactly why to use 32 bit, faster because you can multiply by 4 or shift left 2 for addressing and using 32 bit mov for setting/getting the pixel value.

24-bit on the other hand can be done by shifting left 1 and adding to original value for addressing and using 8 bit mov for setting/getting the pixel value. or 32 bit mov and anding the value with a 24 bit mask, but that mask is different for pixel on offset 0, 1, 2, 3.

If you want speed use 32 bit. if you want even more speed use 16-bit. If you want to implement it fast use 32 bit.
Author of COBOS
User avatar
JAAman
Member
Member
Posts: 879
Joined: Wed Oct 27, 2004 11:00 pm
Location: WA

Post by JAAman »

24-bit on the other hand can be done by shifting left 1 and adding to original value for addressing
which is slower than multiplying by 3 (single half-clock on prescott -- not sure about core2 or any A64s)
User avatar
Combuster
Member
Member
Posts: 9301
Joined: Wed Oct 18, 2006 3:45 am
Libera.chat IRC: [com]buster
Location: On the balcony, where I can actually keep 1½m distance
Contact:

Post by Combuster »

what about using LEA? most compilers will optimize x*3 to that
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
User avatar
bewing
Member
Member
Posts: 1401
Joined: Wed Feb 07, 2007 1:45 pm
Location: Eugene, OR, US

Post by bewing »

I agree with Combuster. LEA reg, [reg + reg*2] is just as fast, under most circumstances. So I don't see any reason to avoid 24-bit color modes.
Post Reply