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" <g...@censoft.com>
To: "Georg Potthast" <mail...@georgpotthast.de>; <nanogui@linuxhacker.org>
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: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org



---------------------------------------------------------------------
To unsubscribe, e-mail: nanogui-unsubscr...@linuxhacker.org
For additional commands, e-mail: nanogui-h...@linuxhacker.org

Reply via email to