Battlescape in high resolution

[michal]

I was curious how battlescape will look in higher resolution

[luke83]

Its been a while  since this topic come up so i am curious is this possible in game  yet ( for us non-programming people )?

[bubblecannon]

I was curious how battlescape will look in higher resolution

Looks good daiky.  I'd love to see an option that allowed higher resolution scaling to allow more of the battle to be available on screen.  (Scrolling gets really painful fast).

Questions:
* how does performance scale with resolution? (ie. animation and scrolling performance)
* could it be tricky and support scaling to aspect ratio? (ie. for 4:3, you set say 800x600 and it works how based on aspect ratio a view dimension?  rather than just scaling to screen resolution) (if what I'm saying makes any sense)

But to be honest, this is where us armchair commentators could help out anyway - aspect ratio scaling would be a minor patch.

[Daiky]

@bubblecannon. It was actually michal who was first to come up with this layout (still don't know how he did it :p).

Performance drops a lot if I recall correctly, which was the point I didn't even bother looking into this any further before some kind of hardware acceleration is supported.

Although, it might be still interesting for people with recent PCs where it still works OK in software mode on high resolution. Maybe some day

[shuuk]

Hmm is it possible to go higher with the whole game? Maybe 1650x1200 ?
I think ufo tts got a higher res. to? or?

[michal]

Hello,

I've decided to try again with that ugly hack. Here's patch and some screenshots.
Notes:
* breaks every screen beside battlescape main screen (engine would need to handle multiple internal resolutions for different screens)
* battlescape mostly works
* performance drops dramatically

Here's whole patch - yeah! only couple of lines had to be changed

Code: [Select]

diff --git a/src/Battlescape/BattlescapeState.cpp b/src/Battlescape/BattlescapeState.cpp
index c38b6ba..5b89bbc 100644
--- a/src/Battlescape/BattlescapeState.cpp
+++ b/src/Battlescape/BattlescapeState.cpp
@@ -84,8 +84,8 @@ namespace OpenXcom
 BattlescapeState::BattlescapeState(Game *game) : State(game), _popups()
 {
  https://game->getScreen()->setScale(1.0);
- int mapWidth = int(game->getScreen()->getWidth() / game->getScreen()->getXScale());
- int mapHeight = int(game->getScreen()->getHeight() / game->getScreen()->getYScale());
+ int mapWidth = int(game->getScreen()->getWidth());
+ int mapHeight = int(game->getScreen()->getHeight());
  int iconsWidth = 320;
  int iconsHeight = 56;
 
@@ -235,7 +235,7 @@ BattlescapeState::BattlescapeState(Game *game) : State(game), _popups()
  Surface *s = _game->getResourcePack()->getSurface("ICONS.PCK");
  SDL_Rect *r = s->getCrop();
  r->x = 0;
- r->y = mapHeight - iconsHeight;
+ r->y = 200 - iconsHeight;
  r->w = iconsWidth;
  r->h = iconsHeight;
  s->blit(_icons);
diff --git a/src/Engine/Screen.cpp b/src/Engine/Screen.cpp
index 23af959..4778029 100644
--- a/src/Engine/Screen.cpp
+++ b/src/Engine/Screen.cpp
@@ -29,8 +29,8 @@
 namespace OpenXcom
 {
 
-const double Screen::BASE_WIDTH = 320.0;
-const double Screen::BASE_HEIGHT = 200.0;
+const double Screen::BASE_WIDTH = 640.0;
+const double Screen::BASE_HEIGHT = 480.0;
 
 /**
  * Initializes a new display screen for the game to render contents to.
diff --git a/src/main.cpp b/src/main.cpp
index c8fd319..ea164f9 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -49,7 +49,7 @@ int main(int argc, char** args)
  {
 #endif
  Options::init(argc, args);
- game = new Game("OpenXcom " + Options::getVersion(), 320, 200, 8);
+ game = new Game("OpenXcom " + Options::getVersion(), 640, 400, 8);
  game->getScreen()->setFullscreen(Options::getBool("fullscreen"));
  game->getScreen()->setResolution(Options::getInt("displayWidth"), Options::getInt("displayHeight"));
  game->setVolume(Options::getInt("soundVolume"), Options::getInt("musicVolume"));


[Volutar]

Performance drop happens because of full-rerender paradigm (original used dirty-box-like technique). To get into more modern graphics (even for going 640x480) project needs new approach. OpenGL also may help.
michal, for such ui panel position there could be issues for down-scrolling and click-area of buttons.

[Bomb Bloke]

I'm not at all confident I'm reading the source correctly, or understand much about how modern rendering engines work, but:

It appears OpenXcom decompresses all sprites at startup then renders the unpacked versions. If so, there's a good chance it could be sped up a fair bit by only storing the packed versions in RAM, then decompressing them directly to the screen each time they are to be rendered.

This is because the packed sprites are stored using RLE, meaning that rendering them this way has the engine entirely skipping most transparent pixels in one leap instead of checking each one to see if it should be rendered or not. I was able to get a significant speed increase in my battlescape editor when I gave up pre-unpacking the sprites, which makes sense when you consider that well over 50% of most of them consists of empty space.

[Daiky]

I would do it the other way around: first opengl and then look what techniques you need to implement to optimise. Especially that RLE trick, that sounds like something you only do in software rendering.

[luke83]

These look really good , i cant wait for this to be fully supported

[michal]

I think there are just to many blitting between surface in Openxcom drawing engine.

For example battlescape map:
1) Individual map tiles are drawn on map's surface.
2) Whole map surface is blitted on screen's "buffer" surface. (that's big surface to blit)
3) Screen's "buffer" surface is blitted to screen. (again big surface to blit)

Maybe we could gain some performance if map's surface would be just some kind of viewport of screen's "buffer" surface. That way map rendering could render directly to screen "buffer" surface.

Probably it would be even faster if map rendering could render directly to screen (without that "buffer" surface - but there would be problem with scaling whole game screen).

Anyway every option require changes to openxcom surface / drawing engine.

[Yankes]

code I used for globe shading was created to work with dirty-box in mind. Reducing draw range is very simple you only need add one line of code and rest stay the same.