nanogui: Thread: Compile with DJGPP or MSC


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Compile with DJGPP or MSC
From: "Georg Potthast" ####@####.####
Date: 5 May 2011 20:25:54 -0000
Message-Id: <003f01cc0b62$a1037280$a900a8c0@SCHREIBTISCHGP>

I tried to compile Microwindows 0.92 with DJGPP. As far as I understand the documentation and the config.dj file this should be possible.

So I copied config.dj as config into the src directory, set NANOX=N plus NANOXDEMO=N to simplify things, and got the following message when running djgpp-make:

E:\djgpp\mwin\src>make
e:/djgpp/mwin/src/Makefile.rules:568: *** multiple target patterns.  Stop.

The line 568 is:
.PHONY: subdirs $(dirs:%=subdir-%)

DJGPP MAKE apparently does not know how to handle that line.

So what can I do to compile 0.92 with DJGPP or should I give that no try at all?


Using Microsoft-C I could compile version 0.88 after some changes to the makefile. I did not get Version 0.89 or later versions to compile using MSC.

Georg


Subject: Re: [nanogui] Compile with DJGPP or MSC
From: "Greg Haerr" ####@####.####
Date: 8 May 2011 20:15:29 -0000
Message-Id: <079701cc0dbc$a9f35110$6964a8c0@winXP>

Georg -

Microwindows hasn't been tested with DJGPP for years, and
as of 0.92, it was officially deprecated.  I don't have DJGPP
over here so I can't test your makefile changes.  I would suggest
looking at the ChangeLog and going back to an older version
that was reported to be working for DJGPP.  Of course, this
could also require older DJGPP tools.

Do you require building on Windows, or can you use Linux or Mac
to build?

Regards,

Greg





I tried to compile Microwindows 0.92 with DJGPP. As far as I understand the 
documentation and the config.dj file this should be possible.

So I copied config.dj as config into the src directory, set NANOX=N plus 
NANOXDEMO=N to simplify things, and got the following message when running 
djgpp-make:

E:\djgpp\mwin\src>make
e:/djgpp/mwin/src/Makefile.rules:568: *** multiple target patterns.  Stop.

The line 568 is:
.PHONY: subdirs $(dirs:%=subdir-%)

DJGPP MAKE apparently does not know how to handle that line.

So what can I do to compile 0.92 with DJGPP or should I give that no try at 
all?


Using Microsoft-C I could compile version 0.88 after some changes to the 
makefile. I did not get Version 0.89 or later versions to compile using MSC.

Georg



Subject: Re: [nanogui] Compile with DJGPP or MSC
From: "Georg Potthast" ####@####.####
Date: 16 May 2011 19:53:36 -0000
Message-Id: <004101cc1402$f0bed4b0$a900a8c0@SCHREIBTISCHGP>

Greg -

I used and modified the make files from Victor which came with version 0.87 and got version 0.88patch to work with DJGPP after a few changes to the code. I can run some of the mwin and nanox demos in DOS using the DPMI driver that comes with DJGPP. DPMI allows to use 4 GB of memory in DOS.

I tried to get version 0.89 to work, but the malpha.c demo displays the car in wrong colors.

Maybe these compiler warnings point to the cause of the problem:
drivers/kbd_djgr.c:24: warning: initialization from incompatible pointer type [line 24 is-> static PSD DJGR_open(PSD psd);]
drivers/kbd_djgr.c:25: warning: initialization from incompatible pointer type [line 25 is-> static void DJGR_close(PSD psd);]

Georg
Subject: Re: [nanogui] Compile with DJGPP or MSC
From: "Georg Potthast" ####@####.####
Date: 16 May 2011 20:47:53 -0000
Message-Id: <004d01cc140a$87e9b290$a900a8c0@SCHREIBTISCHGP>

I did get version 0.89 to work with DOS too now. Had to change the colors in scr_djgr.c back to 16 as had been the case in the previous versions. I don't quite understand this since the grx20 lib supports true color.

Georg
Subject: Re: [nanogui] Compile with DJGPP or MSC
From: "Georg Potthast" ####@####.####
Date: 22 May 2011 14:06:47 -0000
Message-Id: <001301cc1889$7aede920$a900a8c0@SCHREIBTISCHGP>

I managed to get version 0.91 to compile with DJGPP and most of the samples run OK.

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.

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. Why did you drop the code that supported these drivers and could it not be made optional instead? Can I just replace the new fblinxx drivers with the old ones or has the code also changed that used these?

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? 

Georg


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

Subject: Re: [nanogui] Compile with DJGPP or MSC
From: "Georg Potthast" ####@####.####
Date: 22 May 2011 19:54:31 -0000
Message-Id: <001401cc18ba$0e99b5c0$a900a8c0@SCHREIBTISCHGP>

I expanded Victor's makefiles which came with one version of 0.87 in the 
contrib/djgpp directory dated 24th of May 2000. The makefiles that come with 
versions 0.88 and above I could not get to run.

In version 0.92 the malpha demo did work, just the window title text was 
gone. The other samples which I qualified as not working just showed a black 
screen.

With 0.91 I did get 16bpp truecolor to work. So old drivers also supported 
truecolor! However, 24bpp and 32bpp truecolor did display the wrong colors. 
I do not know if this is caused by the grx20 library or Nano-X. Also the 
palette colors are not set properly, I have to look into that.

>You need to implement a direct memory mapping, or a blit driver entry point

I tried to write a new screen driver for DOS but that did not work yet. How 
do I implement a blit driver entry point? I would really like to do that. If 
I look at the screendevice structure, there is no entry point for a blit 
driver. E.g.:

SCREENDEVICE scrdev = {
0, 0, 0, 0, 0, 0, 0, NULL, 0, NULL, 0, 0, 0, 0, 0, 0,
gen_fonts,
X11_open,
X11_close,
X11_setpalette,
X11_getscreeninfo,
gen_allocatememgc,
gen_mapmemgc,
gen_freememgc,
gen_setportrait,
X11_update,
X11_preselect,
};

Regards

Georg 

Subject: Re: [nanogui] Compile with DJGPP or MSC
From: "Greg Haerr" ####@####.####
Date: 22 May 2011 20:22:53 -0000
Message-Id: <026701cc18be$04d85100$6964a8c0@winXP>

: In version 0.92 the malpha demo did work, just the window title text was
: gone.

Yes, font drawing won't work without blit.


: The other samples which I qualified as not working just showed a black
: screen.

Which samples


:: I tried to write a new screen driver for DOS but that did not work yet. 
How
: do I implement a blit driver entry point? I would really like to do that. 
If
: I look at the screendevice structure, there is no entry point for a blit
: driver.

Sorry, I mispoke.  With the new driver architecture the blitting is
all handled internally to the graphics engine using the new conversion
blit routines (engine/convblit*.c).  Then, for systems that aren't
actually implementing a framebuffer, the screen device Update
routine is automatically called by these conversion blits to output
the font or image display data to the screen.  X11 is a good example
for this, and the contents of the internal memory are copied
to the display using X11 calls.  See drivers/scr_x11.c for the Update
entry point.  Note that you won't have to implement update for
every bit depth, just the default bit depth you want to implement.
X11 handles all of 'em, so its more complicated.

Regards,

Greg 

Subject: Re: [nanogui] Compile with DJGPP or MSC
From: "Georg Potthast" ####@####.####
Date: 25 May 2011 21:00:30 -0000
Message-Id: <002701cc1b1e$c73c7a20$a4bffa5c@SCHREIBTISCHGP>

Hi Greg,

you asked which samples worked and which did not work with 0.92 compiled 
with DOS DJGPP. I did some tests now and here are the results:

malpha - works, no title text
mterm - does not compile
mtest - crash with stack fault

NanoX demos:
demo - ok
move - ok
landmine - crash with general protection fault
world and nterm - return immediately without displaying anything
nxclock - is displayed, but does not move
demo2 - shows box with frames and error messages regarding some font lib not 
found
grabdemo - shows box with frame and a message
demo4 - does not compile
demo5 - ok
demo6 - just mouse on black screen
ntetris,info - do not compile
nxeyes - ok

I did not take the time yet to modify the samples that did not compile to 
get them to run.

Don't know if that is what you wanted to know ;-)

As I said, the results were much better with 0.91.

Regards

Georg

----- Original Message ----- 
From: "Greg Haerr" ####@####.####
To: "Georg Potthast" ####@####.#### ####@####.####
Sent: Sunday, May 22, 2011 10:22 PM
Subject: Re: [nanogui] Compile with DJGPP or MSC


>: In version 0.92 the malpha demo did work, just the window title text was
> : gone.
>
> Yes, font drawing won't work without blit.
>
>
> : The other samples which I qualified as not working just showed a black
> : screen.
>
> Which samples
>
>
> :: I tried to write a new screen driver for DOS but that did not work yet.
> How
> : do I implement a blit driver entry point? I would really like to do 
> that.
> If
> : I look at the screendevice structure, there is no entry point for a blit
> : driver.
>
> Sorry, I mispoke.  With the new driver architecture the blitting is
> all handled internally to the graphics engine using the new conversion
> blit routines (engine/convblit*.c).  Then, for systems that aren't
> actually implementing a framebuffer, the screen device Update
> routine is automatically called by these conversion blits to output
> the font or image display data to the screen.  X11 is a good example
> for this, and the contents of the internal memory are copied
> to the display using X11 calls.  See drivers/scr_x11.c for the Update
> entry point.  Note that you won't have to implement update for
> every bit depth, just the default bit depth you want to implement.
> X11 handles all of 'em, so its more complicated.
>
> Regards,
>
> Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.