nanogui: Compile with DJGPP or MSC
Subject:
Re: [nanogui] Compile with DJGPP or MSC
From:
"Greg Haerr" ####@####.####
Date:
22 May 2011 18:23:46 -0000
Message-Id: <018b01cc18ad$62479910$6964a8c0@winXP>
> I managed to get version 0.91 to compile with DJGPP and most of the
> samples run OK.
Was this with no changes to makefiles?
>However, when compiling 0.92 only a few samples still work. The 0.92
>snapshot does compile but the > samples do not work at all any more.
Significant changes in drivers were starting to happen in 0.92, with the
very
major changes happening just after 0.92 was released. When you say
"doesn't work" much more description is required to reply with anything
meaningful.
> Since the documentation describes Nano-X as a modular architecture, is it
> possible to use the old drivers with the 0.92 versions? They have moved to
> the depreciated directory.
The code remains modular but major driver changes were made for speed
gains. The older drivers were moved to deprecated because there was little
use of the platforms in the last 5+ years, and noone was around for testing
them. Simple movement of the drivers back won't work without porting
the changed SCREENDEVICE structure members etc. You'll want to
study the new vs the old before starting.
> Why did you drop the code that supported these drivers and could it not be
> made optional instead?
In most cases, the older systems didn't support truecolor, and few are
interested
in palette support these days. Palette support is still there, but I tried
to clean
up the release and only include files that would compile.
> Can I just replace the new fblinxx drivers with the old ones or has the
> code also changed that used these?
The new fblinxx drivers are a required part of the 0.92 and subsequent
architectures,
which now always use them to draw offscreen, then use the new driver blit
functions
to move/display bits rapidly. In the older architecture, all the drawing
was attempted
by the drivers, which ended up getting problematic as the requirement for
alpha blending, differing-bits-per-pixel, and complete ROP implementations
for all bpp drivers grew. Thus, the new architecture has standardized
fblinxx
drivers for all portrait mode drawing, with a new conversion blit
implementation
that works for almost all bpps. These are all handled internal prior to
getting to
the screen driver level.
You need to implement a direct memory mapping, or a blit driver entry point
in the older driver structure to allow the internal drawing to be displayed
(required for fonts and images).
> I have seen there is a member in the MWSCREENINFO structure:
> MWBOOL fbdriver; /* true if running mwin fb screen driver*/
> What does Nano-X do if you set this to FALSE?
That's an old kluge that will need to be moved. I think it was originally
included for a way for clients to know whether there was a real framebuffer
when being requested to map a window to a framebuffer for fast
video display. It has no effect for the issues you're discussing.
Regards,
Greg
