Linux full screen modes?

[Barry Mead]

Does anyone know how to get ROTT to display a larger screen mode than 320 x 200 in Linux? I can resize my screen to many sizes as low as 640 x 480 with the Ctrl Alt + and - keys, but 320 x 200 is very small. I looked into all of the configuration (.rot) files in the ~/.rott/darkwar directory and there is no mention of screen resolution.
I found hundreds of direct references to the numbers 320 and 200 hard coded in the source code, so my guess is that it is not going to be easy to change the screen resolution with a header file change or a recompile. Any advice or insight would be greatly appreciated. [img]images/icons/rolleyes.gif[/img]

[theoddone33]

See here:

http://forums.3drealms.com/ubb/ultim...;f=24;t=000031

[DrLex]

Originally posted by Barry Mead:
Does anyone know how to get ROTT to display a larger screen mode than 320 x 200 in Linux?

<font size="2" face="Verdana, Arial">I first thought to start replacing all those 320 and 200 numbers too, but this soon showed to be pure hell. I haven't tried the 'full screen hack' from the other thread yet, but apparently the only thing it does right is giving you a larger game image and all the rest is displayed incorrectly.
I did a much simpler trick which works surprisingly well: I replaced the screen update call with a scaling function which copies an upscaled version of the image buffer into the actual screen buffer. The function rescales the 320x200 buffer to a 640x480 one, so if the monitor is set to this resolution (which SDL should do automatically when activating full screen mode), you have real full screen.
Of course this does not give you a higher 'resolution' but now the game looks (almost) exactly like the good old DOS version. The drawbacks are that this is not super-fast (although I did my best to optimize the code to the max), and that the scaling is not 'pure' (due to the fact that you're scaling the vertical size of 200 to a new size of 480, requiring adding 2 extra copies every 5 lines).

If you want to give it a shot, just replace the modexlib.c file with the one from this link.

A better solution would be to use hardware acceleration, which would both avoid the overhead of the scaling function and allow to do e.g. bilinear interpolation for a smoother image. However, I don't know how this can be done elegantly in a cross-platform way...

[Barry Mead]

Thanks DrLex this is more what I had in mind. I like the way your patch keeps all of the menus and everything perfect.

Well, I haven't tried out either of the patches mentioned here yet, but from the sounds of it, DrLex's patch is very similar to the one I wrote. All I did was added a extra SDL surface thats 320x200 and initialized the real SDL screen surface to whatever size you want, then I added a call to the zoomSurface function of the SDL_gfx library to resize the 320x200 buffer to the screen size, then blit that surface to the screen. Its not the most efficient way to do things, but I'm running on a 1 Ghz and don't notice any performance issues versus the origional one, and this also allows for running at any resolution you want. If anyone is interested in the source to this let me know and I'll put it up someplace. The next thing I'm gonna work on is the networking code, but thats pretty scarry code, so much so, that I'm thinking the whole engine could use a rewrite from scratch.

[Barry Mead]

If you rewrite the engine, take a look at the prboom engine. It makes a higher resolution image than the old doom and smoothes the image using the hardware acceleration features that DrLex mentioned.

[DrLex]

Originally posted by orcle:
Its not the most efficient way to do things, but I'm running on a 1 Ghz and don't notice any performance issues versus the origional one, and this also allows for running at any resolution you want.

<font size="2" face="Verdana, Arial">FYI: the code in the modexlib.c you can download above is about the fastest I could get it. I think it's theoretically impossible to make it any faster (except for a few more invisible percents), because it has the minimum required accesses for the job. With this code, there is no noticeable slowdown on an 800MHz G3 processor, but it's visible on a 400Mhz one.
Someone proposed to use OpenGL to do the resizing. The game would then be rendered in an OpenGL texture which would then simply be rendered on a rectangle the size of the screen...

[theoddone33]

Rott isn't based on Doom.

[Barry Mead]

I didn't imply that rott was based on doom. What I was referring to is that prboom represents a modern implementation of the 3d acceleration and enhanced graphics system that would be an excellent example of how to implement the same features in rott. Prboom is a rich source of examples, even it rott is not based on doom. I stand by my statement and I know I am right. I am a contributor to the prboom project and I know what I am talking about.

[theoddone33]

Originally posted by Barry Mead:
I didn't imply that rott was based on doom.

<font size="2" face="Verdana, Arial">I guess not.

Excellent name-dropping though.

Also:

Originally posted by DrLex:
Someone proposed to use OpenGL to do the resizing. The game would then be rendered in an OpenGL texture which would then simply be rendered on a rectangle the size of the screen...

<font size="2" face="Verdana, Arial">For the record I think that's a horrible idea.

[ 08-10-2003, 12:26 AM: Message edited by: theoddone33 ]

[Barry Mead]

As you are the senior developer of the rott port and cheif maintainer of the hheretic and hhexen ports, I respect your opinion and wouln't think of dissagreeing with you. I am not familiar with all of the inner workings of prboom either. I just contributed a few tiny bug fixes around the edges of prboom. I was curious about why prboom is not a preferred source of input for your porting contributions. There are a few features that prboom implements that would help the hheretic project for example. Using the "Shadow of the serpent riders" version of the heritic.wad file and the ./configure --enable-gl version of hheretic, I found that hheretic crashes on episode 4 mission 9 when you enter the room with all of the torches and moving walls. I traced the bug down to the fact that the recursive bsp tree algorythm is allocating a new version of each 3 or 4 byte pallette expanded color wall image for each and every texture of the room regardless of whether the same texture has already been expanded before. prboom uses caching of the 3 or 4 byte palette expanded wall textures so that for each unique wall texture in the room there is an expanded texture, but not for every one. When hheretic expands every wall texture in the room the deep recursive stack allocation simply runs out of memory and causes a seg fault. I tried issuing commands to allocate up to 250 megs to the stack, but that was still not enough for this really deeply nested bsp tree. I am not saying that hheretic should be rewritten to be like doom, only that some of the prboom ideas that eliminate bugs might help improve these games in some touble spots. By the way I ran a converter program that converts heretic levels to doom levels and ran this same deeply nested level in prboom and it does not hang (the caching helps a great deal) in this particular area. I hope I have not made you angry by my observations, I respect you a great deal and would like to learn from you. I really wish to thank you for your excellent contributions to the open source concept and for bringing some of my favorite games back to life in the linux environment.

[ 08-19-2003, 03:01 AM: Message edited by: Barry Mead ]

[Barry Mead]

DrLex: I hope you don't mind, I incorporated your 640x480 patch into a new patch that I added which allows the -fullscreen command line option to start rott up with the screen sized to 640x480. If you start rott like this from the ~/rot/rott directory type:
./rott -fullscreen
Then rott will automatically change to the full screen mode without the need to use the <ALT> <Enter> key sequence, which still works as a toggle of course. The file can be downloaded from:
www.geocities.com/barrymead0
Then copy the file to the ~/rott/rott directory and patch it like this:
patch -p0 <rottfullscreenpatch.txt
and recompile with make. I find this way of switching to full screen mode more convenient than the key sequence, because you can define an icon on your desktop to run rott in full screen mode.

[ 08-24-2003, 07:41 PM: Message edited by: Barry Mead ]

[DrLex]

Of course I don't mind [img]images/icons/smile.gif[/img]