nanogui: Thread: X-games, doom, hexen ...

Dear Fellow hackers,

On the nanogui list I found
http://www.linuxhacker.org/cgi-bin/ezmlm-cgi/5/4126, that xbill, xroach,
xpenguins ... has been ported (claim by Jordan). Is there a way to get hold
of those sources?

We have nxdoom running on out Set-Top Box (powerpc, 75 Mhz), it seems a
little slow in updating the scene. Is that reasonable? Can we tweak more out
of doom ya think?

nxdoom has really ugly colors, the STB supports truecolor. Can I utilize
that? 

nxdoom in the version we have is 320x200, and we run nano-X in 640x480. Can
we get fullscreen out of nxdoom? I have tried to change 320 to 640 in
doomdef.h (etc), but to no avail. When I grep for 320 in the code it appears
everywhere, so maybe I cannot get around it.

Has anyone tries hexen or other doom-like games on nano-X?

K. Nikolaj Berntsen  Technical Consultant
--------------------------------------------------------------
AGENCY.COM Interactive TV

Islands Brygge 57, DK-2300 Copenhagen S
T: +45 3693 6000  F: +45 3693 6001  
Direct: +45 3693 6120  
E: ####@####.####  www.agency.com 
 

On Wednesday 15 August 2001 05:41, Nikolaj Berntsen mentioned:
> Dear Fellow hackers,
>
> On the nanogui list I found
> http://www.linuxhacker.org/cgi-bin/ezmlm-cgi/5/4126, that xbill, xroach,
> xpenguins ... has been ported (claim by Jordan). Is there a way to get hold
> of those sources?

Are you doubting me? :)

XBill has been ported, I will put the source for that on the FTP site.
XRoach has been ported, you can get it from the Microwindows CVS
Xpenguins has been ported, but I haven't run it in a month of Sundays.  I'll 
have to get back to you on that.

> We have nxdoom running on out Set-Top Box (powerpc, 75 Mhz), it seems a
> little slow in updating the scene. Is that reasonable? Can we tweak more
> out of doom ya think?

Sorry...  The way that Microwindows currently works is that we have to do 
lots of memory copies in the client program, and that takes time.  We 
probably could get a little more performance if we started optimizing for 
specific processors, but we have always favored compatability and portablity.
Microwindows will soon provide a client side framebuffer for speed, but thats 
still a couple of releases away.

> nxdoom has really ugly colors, the STB supports truecolor. Can I utilize
> that?

Acutally, the nxdoom has its own palette colors, so what you have is what you 
get.

> nxdoom in the version we have is 320x200, and we run nano-X in 640x480. Can
> we get fullscreen out of nxdoom? I have tried to change 320 to 640 in
> doomdef.h (etc), but to no avail. When I grep for 320 in the code it
> appears everywhere, so maybe I cannot get around it.

320x200 *IS* fullscreen for the Ipaq.. :)  You will need to change both the 
defines that you did, and also go through and hack on i_video.c.    Maybe you 
can find some speed improvements that I missed.

Jordan

> XRoach has been ported, you can get it from the Microwindows CVS

Thanx. Didn't notive that there was CVS. I can see, clearly now [singing],
nxroach. Thanx.

> XBill has been ported, I will put the source for that on the FTP site.

appreciate that. Why not in CVS too?

> Xpenguins has been ported, but I haven't run it in a month of Sundays.
I'll 
> have to get back to you on that.

I'll hold my breath (no, it is neither a threat nor a promise:)

> Sorry...  The way that Microwindows currently works is that we have to do 
> lots of memory copies in the client program, and that takes time.  We 
> probably could get a little more performance if we started optimizing for 
> specific processors, but we have always favored compatability and
portablity.
> Microwindows will soon provide a client side framebuffer for speed, but
thats 
> still a couple of releases away.

How does releases work? I only see very old announcements on
microwindows.org. How much is in pathces on the mailing list and who
contribute on CVS?

> nxdoom has really ugly colors, the STB supports truecolor. Can I utilize
> that?

> Acutally, the nxdoom has its own palette colors, so what you have is what
you 
> get.

You are saying it is ugly because nxdoom has a bad choice of builtin colors?
Nothing I can do about it without getting my hands really dirty :-?

> 320x200 *IS* fullscreen for the Ipaq.. :)  You will need to change both
the 
> defines that you did, and also go through and hack on i_video.c.    Maybe
you 
> can find some speed improvements that I missed.

I'll see what happens :-> core dump :-! I'll get back if something else
happens.

I was wondering on the license of nxdoom. There is a file saying it is only
for non-commercial use, but I had the impression that doom was GPL. What
goes?

Regards
Nikolaj


K. Nikolaj Berntsen  Technical Consultant
--------------------------------------------------------------
AGENCY.COM Interactive TV

Islands Brygge 57, DK-2300 Copenhagen S
T: +45 3693 6000  F: +45 3693 6001  
Direct: +45 3693 6120  
E: ####@####.####  www.agency.com 
 

: > nxdoom has really ugly colors, the STB supports truecolor. Can I utilize
: > that?

Doom runs only in 256 color palette mode.  You could translate the colors
for 16 or 32bpp, but then it would be even slower.


: > nxdoom in the version we have is 320x200, and we run nano-X in 640x480. Can
: > we get fullscreen out of nxdoom? I have tried to change 320 to 640 in
: > doomdef.h (etc), but to no avail. When I grep for 320 in the code it
: > appears everywhere, so maybe I cannot get around it.

Doom will only run in 320x200, but you can double the pixels when
doing the final scene copy.  Look at the code I wrote in i_video.c,
I have a double pixel blitter in there.

> We have nxdoom running on out Set-Top Box (powerpc, 75 Mhz), it seems a
: > little slow in updating the scene. Is that reasonable? Can we tweak more
: > out of doom ya think?
:
: Sorry...  The way that Microwindows currently works is that we have to do
: lots of memory copies in the client program, and that takes time.  We
: probably could get a little more performance if we started optimizing for
: specific processors, but we have always favored compatability and portablity.
: Microwindows will soon provide a client side framebuffer for speed, but thats
: still a couple of releases away.

Actually, this is mostly the way that Doom works, not Microwindows.  Doom
always creates its scenes in 320x200x8bpp.  If your screen isn't running
256 color (most STB's aren't), then you'll have to do a memory copy, which
is exactly the way I had to implement it for the iPAQ since, it runs 16bpp.
The client-side framebuffer mapping is in the CVS, and could possibly
speed up your copy, rather than using GrArea.  But it's still pixel-by-pixel,
and will likely require 8bpp->16bpp translation per pixel.

Regards,

Greg

: How does releases work? I only see very old announcements on
: microwindows.org. How much is in pathces on the mailing list and who
: contribute on CVS?

Send any patches to me, I update the CVS.  And yes, I am working
on getting the next version out.

Regards,

Greg

On Wed, 15 Aug 2001, Nikolaj Berntsen wrote:
> I was wondering on the license of nxdoom. There is a file saying it is only
> for non-commercial use, but I had the impression that doom was GPL. What
> goes?

The Doom engine itself was released more than once under different
licenses. One of them was non commercial only, another was GPl. On the 
other hand, apart from the shareware demo version, the game data is still
not freely available.

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

The original ID licence was (and remains) non-commercial.  I'm not sure if it 
was ever GPLed (but there may have been some GPLed apps that were "inspired 
by" the doom source).

Jordan

On Wednesday 15 August 2001 12:00, Alex Holden mentioned:
> On Wed, 15 Aug 2001, Nikolaj Berntsen wrote:
> > I was wondering on the license of nxdoom. There is a file saying it is
> > only for non-commercial use, but I had the impression that doom was GPL.
> > What goes?
>
> The Doom engine itself was released more than once under different
> licenses. One of them was non commercial only, another was GPl. On the
> other hand, apart from the shareware demo version, the game data is still
> not freely available.

On Wed, 15 Aug 2001, Jordan Crouse wrote:
> The original ID licence was (and remains) non-commercial.  I'm not sure if it 
> was ever GPLed (but there may have been some GPLed apps that were "inspired 
> by" the doom source).

They re-released it under the GPL in 1999. Some of the ports retain the
original license and some are based on the GPL release (there seems to be
some confusion as to whether the modifications which were made to the
pre-GPL ports can be relicensed as GPL or not).

-- 
------- Alex Holden -------
http://www.linuxhacker.org/
 http://www.robogeeks.org/

Hi Jordan and others :-)

> XBill has been ported, I will put the source for that on the FTP site.

where? I cannot see it (yet?)

> 320x200 *IS* fullscreen for the Ipaq.. :)  You will need to change both
the 
> defines that you did, and also go through and hack on i_video.c.    Maybe
you 
> can find some speed improvements that I missed.

I tried the simple things to do in i_video.c, multiply=2, and flip=0.
Suddenly the game cannot start (the menus work fine), it just quits when I
try to start playing. Then I tried to reset flip=1, and start ./doom -flip,
now it core dumps.(I also tried without -flip, same result).

I will play around, but it would be nice to get a confirmation that you have
actually had been playing with multiply=2, e.g., and maybe also with flip at
the same time.

If we were to use doom for any commercial purpose (after sorting out
licensing purposes), we would definitely re-skin it. I tried to get doom on
my linux PC to run publicly available WAD's, but it declined. Do you know
whether it is capable of running other than the sharewad? Maybe after a
quick hack, no fundamental changes?

Regards,
Nikolaj

K. Nikolaj Berntsen  Technical Consultant
--------------------------------------------------------------
AGENCY.COM Interactive TV

Islands Brygge 57, DK-2300 Copenhagen S
T: +45 3693 6000  F: +45 3693 6001  
Direct: +45 3693 6120  
E: ####@####.####  www.agency.com