Duke4.net Forums: Eduke32 missing original 320x200 video mode on software renderer - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Eduke32 missing original 320x200 video mode on software renderer

User is offline   gaula92 

#1

Hi there,

I am trying (again) to build a satisfactory version of Eduke32 for the Raspberry Pi3.
The Pi3 should be perfectly capable of silk-smooth 60fps *if no software scaling is used* (that's why the Pi3 has an adequate GPU!)
Take into account that SDL2 on the Pi is ALWAYS fullscreen. There's nothing like a windowed mode: it runs on the SDL2 KMSDRM driver, no X server involved. So setting a windowed mode will simply make SDL2 upscale in hardware whatever window size we want to the physical resolution in use.
As things are:
-I have to set ScreenMode=1 on the eduke32.cfg. Setting it on the game menu is ignored and Full Screen is disabled on next boot.
-There's no way to tell the game to render to 320x200 and let SDL2 upscale in hardware, as other SDL2 programs do (Doom Retro, SDLPop, etc). It insists on producing hi-res frames: if I try to set a 640x480 video mode, boom! black screen and I have to killall Eduke32 on the SSH session and reboot the system. My guess is that it's trying to free up something it shouldn't be freeing on dynamic screen resolution changes, thus causing the SDL2 KMSDRM driver to go nuts.
-I can force a 640x or 320x mode in eduke.cfg, but then the game only shows a small corrupt graphics band on the upped side of the screen (thicker on 640x).

Thus, I thing screen mode management is utterly broken as things are. I guess most Windows users just use whatever they are thrown at and that's all, for for special cases like devices that only have fullscreen modes and need to disable all software scaling, it's in a very bad shape. Is it somehow fixable, please?
2

User is online   Phredreeke 

#2

PCs are generally fast enough to run the software renderer without resorting to lower resolutions.

I recall Hardware scaling being added a few months ago. I have no idea if it works on the Pi though.
0

User is offline   necroslut 

#3

I was also wondering about this and why the game can't even be set to 320x200 or 320x240 in windowed mode. Using the console command to force resolution seems to mess up things, seemingly the game interprets 320x200 or 640x400 as widescreen resolutions making HUD and sprites squished?
Upscaling also doesn't seem to be able to produce a "clean" upscale (2x pixels) as the game is drawn for 320x200...
1

User is offline   TerminX 

  • el fundador

  #4

View Postnecroslut, on 28 February 2019 - 11:12 AM, said:

Upscaling also doesn't seem to be able to produce a "clean" upscale (2x pixels) as the game is drawn for 320x200...

We've noticed this, but unfortunately it's consistent with the original DOS version and we haven't been able to put the work in to fix it yet.
0

User is offline   gaula92 

#5

Original 320x200 mode would be REALLY usefull for low-powered ARM platforms, where Eduke32 runs but with low framerates. 320x200, scaled fullscreen using SDL2 hardware scaling capabilities using it's internal GLES renderer, would make Eduke32 really shine in that kind of hardware, which is very common.

This post has been edited by gaula92: 02 March 2019 - 05:14 AM

0

User is offline   necroslut 

#6

View PostTerminX, on 28 February 2019 - 12:54 PM, said:

We've noticed this, but unfortunately it's consistent with the original DOS version and we haven't been able to put the work in to fix it yet.

Not sure what you're trying to say here... DOS Duke looks perfectly clean in 320x200, and although there's some minor scaling distortions in other reasons it nowhere near as garbled as when upscaling in ED32.
0

User is offline   TerminX 

  • el fundador

  #7

View Postnecroslut, on 08 March 2019 - 06:14 AM, said:

Not sure what you're trying to say here... DOS Duke looks perfectly clean in 320x200, and although there's some minor scaling distortions in other reasons it nowhere near as garbled as when upscaling in ED32.

I mean we looked at the game in DOSBox and the result at, say, 800x600 was more or less identical to the result you get when running EDuke32 at 1600x1200 with 2x scaling. The sprites in the HUD do get mangled, but they get mangled in DOS too. I bitched about it to pogokeen, thinking that we had done something wrong, and was very surprised that the DOS version was as bad.
0

User is offline   necroslut 

#8

View PostTerminX, on 08 March 2019 - 01:57 PM, said:

I mean we looked at the game in DOSBox and the result at, say, 800x600 was more or less identical to the result you get when running EDuke32 at 1600x1200 with 2x scaling. The sprites in the HUD do get mangled, but they get mangled in DOS too. I bitched about it to pogokeen, thinking that we had done something wrong, and was very surprised that the DOS version was as bad.

Ah, yeah, But something like 640x480 with 2x looks way worse than 320x200 in DOS, and 640x400 is a complete mess.
0

User is offline   gaula92 

#9

Any news on original 320x200 mode for small systems like the Pi?
Also, using any resolution other than the default one in fullscreen mode corrupts the screen in every system where I tried eduke32.
0

User is offline   TerminX 

  • el fundador

  #10

There are MINXDIM/MINYDIM/MAXXDIM/MAXYDIM preprocessor definitions in build.h that can be used to control which video modes are available.
0

User is offline   gaula92 

#11

View PostTerminX, on 09 April 2020 - 12:01 PM, said:

There are MINXDIM/MINYDIM/MAXXDIM/MAXYDIM preprocessor definitions in build.h that can be used to control which video modes are available.


I have been taking a look at source/build/include/build.h, but I can not figure out how to force the engine to run in 320x200 there. Can you please give me a hint?
0

User is offline   gaula92 

#12

@TerminX (or whoever): Can you please give me that hint regarding getting Eduke32 running at 320x200 by editing build.h?
0

User is offline   necroslut 

#13

On the topic; are we going to get upscaling for Polymost?
0

User is offline   Darkus 

#14

I don't think that recent monitors have support for 320x200 anymore, but with some tricks, I actually managed to run EDuke in 320x200 in full screen, here's how to proceed:

- First use a bigger resolution that is a multiple of 320x200 (640x400, 960x600, 1280x800...). Use the 'vidmode' console command to change manually (keep in classic mode)

- Go to the options, turn widescreen off

- Open the console, and set 'r_rotatespritenowidescreen' to 1

- Set 'r_upscalefactor' to the multiple of the 320x200 resolution you're using. For example, if you're using a resolution of 960x600, then it should be 'r_upscalefactor 3'

Example of EDuke32 running Alien Armaggedon in 320x200 (I used 1280x800, but the capture was automatically resized because of the upscale):

Posted Image

The only problem is that my monitor interpret those resolutions like widescreen, and I have no options to correct the aspect ratio...
2

User is offline   necroslut 

#15

View PostDarkus, on 01 May 2020 - 12:35 PM, said:

I don't think that recent monitors have support for 320x200 anymore, but with some tricks, I actually managed to run EDuke in 320x200 in full screen, here's how to proceed:

Yes, this is how I run it when running software and it looks great (once I found out about "r_rotatespritenowidescreen"). Upscaling doesn't seem to be available for Polymost though, which is a shame, since there are a lot of situations where you'd want Polymost.

This post has been edited by necroslut: 01 May 2020 - 02:55 PM

0

User is offline   Darkus 

#16

I would rather see some kind of OpenGL render to display original classic render in 320x200 scaled to 4:3, like some modern emulators does. And why not some shaders like scanlines or CRT-Geom ;)
0

User is offline   gaula92 

#17

View PostDarkus, on 01 May 2020 - 12:35 PM, said:

I don't think that recent monitors have support for 320x200 anymore, but with some tricks, I actually managed to run EDuke in 320x200 in full screen, here's how to proceed:

- First use a bigger resolution that is a multiple of 320x200 (640x400, 960x600, 1280x800...). Use the 'vidmode' console command to change manually (keep in classic mode)

- Go to the options, turn widescreen off

- Open the console, and set 'r_rotatespritenowidescreen' to 1

- Set 'r_upscalefactor' to the multiple of the 320x200 resolution you're using. For example, if you're using a resolution of 960x600, then it should be 'r_upscalefactor 3'

Example of EDuke32 running Alien Armaggedon in 320x200 (I used 1280x800, but the capture was automatically resized because of the upscale):

Posted Image

The only problem is that my monitor interpret those resolutions like widescreen, and I have no options to correct the aspect ratio...


Of course modern displays do not support 320x200. Why should they?
What sane 320x200 SDL2 programs do (like DoomRetro, Chocolate Doom, SDLPop = Prince of Persia engine running on SDL2, RawGL, ReMiniscence, HODE engine, and a LONG etc) is rendering to a 320x200 buffer and let SDL2 scale it to fullscreen FOR FREE, since SDL2 renders each frame using OpenGL/ES.
There is no need to support 320x200 externally, who would like its monitor go into that mode with modern displays? Only internal frames have to be rendered in 320x200, and SDL2 should simply take each 320x200 frame an upscale it, as all those engines do.

I just dont get why, if SDL2 scales 320x200 to whatever physical mode is in use for free, Eduke32 cant just accept that resolution for the internal rendering instead of physically trying to setup that resolution. It makes no sense.

This post has been edited by gaula92: 07 May 2020 - 04:01 PM

0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options