Messages

466

Suggestions / Re: opengl

« on: August 23, 2011, 01:11:53 pm »

I agree with michal that in the end it would probably be best to have everything rendered in OpenGL (once it has no disadvantages over SDL rendering), both retro and modern. Supporting various graphics APIs would become a maintenance nightmare.

Shouldn't there be a backup option if your system does not support OpenGL (properly)?

Also if switching entirely to OpenGL is the way to go, there is no reason to first waste time on implementing a system that can support both and then throwing all that code away to go back to a system that only supports one of them...

467

Suggestions / Re: opengl

« on: August 22, 2011, 11:01:05 am »

That sounds a bit too advanced to me... Any examples of opensource projects that did what you described Yankes?

468

Suggestions / opengl

« on: August 17, 2011, 06:47:06 pm »

This is not really a suggestion, as I'm already working on it (in my own sandbox not in the official openxcom repository): people that are on IRC already know all of this, they are already totally bored with my rambling.
But I just wanted the forums opinion or comments too, regarding the implementation of it.

So the idea is to keep support for SDL, Pallettes, 8bit graphics, software blitting, 320x200 - the oldskool stuff.
But on top of that have the option for OpenGL, truecolor graphics, hardware blitting and higher resolutions.

Apart from the differences in intialisation, support for both opengl/sdl is done by abstracting the Surface class and creating two new implementations: SDLSurface and OGLSurface. The second one will load the surfaces as textures into video memory: blitting (and shading) surfaces will be done in video memory. (when it makes sense, because video memory has its limits)
New blitting functions, text & simple geometry rendering functions will have to be written in openGL versions.

I got the basic lines and pieces of code for the most part. I must give credit to the FIFE engine for it, as I take a lot of inspiration from there.
For testing I'm currently using UFO:TTS's graphics (which I converted to PNG, because I wanted to make sure SDL could handle that format also).

On the geoscape part we got another fun new toy to play with: drawing teh globe in opengl. In theory it would dramatically simplify the globe code (also the shading of the day/night cycle, which could be done simply by adding a rotating light to the scene), while dramatically increase the fps.
However I did not try anything on that front yet... it's just theory and ideas.

469

Programming / Re: Code problems

« on: August 16, 2011, 05:08:35 pm »

About the "mul"(tiplier):

The font bitmap of x-com has 6 shades of grey = 0 to 5.
(using palette offsets you can blit text in all kinds of colors)
The mul has a max value of 3, because you only can go up to 15 : it sets the contrast higher, as the darker shades get darker.
If you would set it to 4 you end up in the next color range with very weird results.

470

Programming / Re: Code problems

« on: August 16, 2011, 11:06:37 am »

The malloc I copied that from Palette::loadDat ... not sure why it's used, I guess it's more C-like which fits SDL, maybe it's from an example in the SDL tutorials?

paletteShift is always called once and then paletteRestore after that, so currently there are no memory leaks. But you are right, if someone else wants to use this function it should be made a little more foolproof.

About the "mul", I'm not sure how that works, I copied it from the original function Surface::offset, and it seemed to me it still works?

471

Programming / Re: Battlescape performance

« on: August 15, 2011, 04:49:44 pm »

After 2 days of experimenting with different methods. I decided to go back to the previous method of caching tiles... at the cost of memory usage. But at least it worked and is very simple :p
What this means is, that the terrain is cached in memory. Terrain = floor tile+wall tiles+objects+items. So if terrain does not changes, it saves 4 blits & 5 palette changes per tile on the screen.

On my system (high-end) I got :
previous build : 890fps static screen - 650fps during walking
current build: 950fps static screen - 920fps during walking

It will be more interesting to see the results on normal systems

472

Programming / Re: Battlescape performance

« on: August 15, 2011, 02:20:49 pm »

Been experimenting with dirty rectangles, so far it just gives me loads of artifacts

473

Programming / Re: Battlescape performance

« on: August 14, 2011, 11:03:24 pm »

So, I was thinking, each tile corresponds to a rectangle of 32x40, when a tile goes invalid this is the rectangle that needs to be re-blitted. But the tiles that need to be redrawn are actually not just the invalid tile, but also the 3 tiles in front of it?
You also see that with a soldier movement or projectile, there is always a begin-tile and end-tile - so maximum two rectangles to update. (if a soldier just turns around or kneels, it's only one)
And these two rectangles can be merged into one.



edit: actually it's not just the 3 tiles in front of it... It's more like everything in front of it

474

Programming / Re: Battlescape performance

« on: August 14, 2011, 09:36:17 pm »

Yankes, the light changes only at the very end of the walking cycle, so only one frame out of the 8 or 16 (diagonal step) frames - so I still think a performance gain is possible.

The idea to group drawings that have the same palette is good, but I'm not sure how to implement the Z-buffer you mention.

475

Programming / Battlescape performance

« on: August 14, 2011, 06:35:11 pm »

Anyway it's a good thing.

In theory at least
But when moving to higher resolution screens, it becomes even more important, so I hope to get good results after I manage to implement it.

476

Programming / Battlescape performance

« on: August 14, 2011, 02:26:29 pm »

yes, I'm kinda desperate if changing the palettes is really taking so much time. The problem is, you can not access the internal palette map directly to just set the colors. (Which was certainly possible in the old days)

If I look into the SDL code, the call to set the SDL_SetPalette , it seems to do so many weird things like allocating a new memory,  running through all colors and map it to something. So it's a pretty busy function.
Knowing that a battlescape screen easely can have around 300 objects to draw...

You will notice that a mission in full daylight will go faster, because I already added an optimization that if the palette does not need to be changed, it doesn't call the palette change function.

The default rate at which the whole screen is redrawn is 10fps (which is the speed of the animation of for example the little arrow above the soldier's head, or animation of fire, smoke and other stuff). All the other frames in between are drawn from the buffer.
The walking animation is at 25fps - unfortunatly it also redraws the whole screen (on top of the 10fps of the animation drawing) - which is 35 times it draws 300 objects from scratch. So yeah, that's more than 1000 calls per second the setPalette function - if it really is allocating and deallocating memory at 1.000 times per second, it is not surprising it has time to only get 150 frames shown on the screen within that second.


I got another trick up my sleeve... which also is used in almost every 2D game (almost certainly in the original x-com as well).... It is called "dirty rects" - it's as nasty to implement as it sounds.
The idea is to only redraw the parts of the screen that have changed on the new frame and get all the rest from the last frame...

477

Troubleshooting / Re: OpenXCom very slow even on good pc?

« on: August 10, 2011, 12:31:27 am »

Istrebitel, I did a small optimisation in the text drawing, it might help. Could you test the latest autobuild and see?

478

Troubleshooting / Re: OpenXCom very slow even on good pc?

« on: August 09, 2011, 02:52:59 pm »

actually F5 is the FPS counter, F12 creates screenshots 

479

Troubleshooting / Re: OpenXCom very slow even on good pc?

« on: August 09, 2011, 12:45:45 pm »

I think I might have an idea of something that could be done more efficiently - I'll have a look at it this evening.

480

Troubleshooting / Re: OpenXCom very slow even on good pc?

« on: August 08, 2011, 10:04:38 pm »

Is this a binary you build yourself, or an exe from the auto-build, if yes, which one?
I know if you build a debug version in visual studio it's also slow on my quad core.
There was an issue with text rendering a few builds ago, where I also noticed hickups, due to inefficient use of surface locking to manipulate pixels... sigh
But that should be better in the latest builds.
PS. graphics card will not make any change as it is not using any (it uses software rendering)