Age | Commit message (Collapse) | Author |
|
Graphics::PixelFormat, instead of relying on color masks -> should fix bug #2537212, possibly at a slow down on low-end systems (a regression which we certainly could resolve, though). Note: I left the PixelType template param in on purpose, in case we want one day to compile in both 16 and 32 bit pixel support simultaneously
svn-id: r36288
|
|
system, plain sqrt is 50x faster -- on highest optimization levels, otherwise it is something like 200x)
svn-id: r36277
|
|
svn-id: r36257
|
|
svn-id: r36185
|
|
Fixed alpha blending in the UI dialogs by adding alpha
computation to the blendPixelPtr() function. To minimize
impact, pre-multiplied alpha is assumed, meaning that the
blending of the R, G and B components is the same both
with and without hardware alpha.
svn-id: r36177
|
|
VectorRenderer::bytesPerPixel(): the latter was not used, for the former it is silly to go through a virtual method to compute that value; all in all, this code performs too many unnecessary divisions ;)
svn-id: r36151
|
|
svn-id: r36148
|
|
svn-id: r36143
|
|
like 'while(cond);' by inserting newlines
svn-id: r36127
|
|
svn-id: r36115
|
|
svn-id: r36099
|
|
svn-id: r36090
|
|
svn-id: r36089
|
|
svn-id: r36088
|
|
svn-id: r36087
|
|
old code (with some variable name changes to match the other interpolators)
svn-id: r36086
|
|
'plain' x86 code. Advantage: got rid of a 256kb table (reduces cache load, so over here the code is about as fast as before; in particular, since the affected interpolators are not used that often, it seems). Moreover, the new code is more accurate than the old ASM code, which actually differed from what our C++ HQx did (sacrificing precision for speed, i.e., cheating ;-)
svn-id: r36078
|
|
svn-id: r36075
|
|
svn-id: r36074
|
|
svn-id: r36060
|
|
svn-id: r36054
|
|
svn-id: r36049
|
|
interpolation macros (they are meant to speed up things, but in reality cause a slowdown -- branches are expensive on modern CPUs)
svn-id: r36047
|
|
make it possible to adjust them for 555 vs. 565 mode (555 mode is still a bit buggy, due to the interpolation code they use)
svn-id: r36046
|
|
svn-id: r36034
|
|
svn-id: r36026
|
|
svn-id: r36025
|
|
svn-id: r36024
|
|
svn-id: r36021
|
|
svn-id: r36008
|
|
svn-id: r35998
|
|
to be taken now is first, least likely is last
svn-id: r35996
|
|
svn-id: r35995
|
|
the process)
svn-id: r35994
|
|
into methods, and added an operator==
svn-id: r35993
|
|
svn-id: r35965
|
|
svn-id: r35951
|
|
svn-id: r35819
|
|
svn-id: r35818
|
|
svn-id: r35817
|
|
- Split the video player from the video decoders. It's now possible to have one video player for multiple decoders
- Added the palette weight calculation from the BS1 engine into VideoPlayer::setPalette. It's now possible to find the values of the white and black colors via getWhite() and getBlack() (useful for subtitle overlays)
- Adapted FTA2's movie playing code to the new changes to video player
- Fixed a slight bug in the DXA decoder (_videoinfo.startTime was not initialized)
svn-id: r35816
|
|
- Merge is perfromed in order to not let rotting the code
- Makefile modifications were avoided
Stuff to resolve:
- Circular dependency of common/vkeybd from graphics/
- Make it compilable (?)
- Add some keyboards
- Decide on the key bindings
svn-id: r35813
|
|
svn-id: r35781
|
|
svn-id: r35777
|
|
meant to play full screen videos)
svn-id: r35776
|
|
svn-id: r35775
|
|
svn-id: r35774
|
|
- Added a new class, VideoPlayer(), from which both the SMK and the DXA player inherit. This class provides generic functions and public methods for the inherited video classes. Default implementations have been made for these public methods, and the virtual ones can be overriden in inherited classes
- There is now a default implementation of the function that sets the video palette
- A basic video player for inherited classes has been added with method playVideo(). This is able to play a fullscreen non-interactive video, which can be skipped with events set by the caller. Postprocessing methods, which draw upon each frame (e.g. subtitles) can be done by implementing performPostProcessing()
- The FTA2 movie player now uses the new playVideo() method
- The new video player code is compatible with the old one (i.e. no changes to the existing engine code are necessary), but it's now possible to reduce engine code for video playing considerably
svn-id: r35772
|
|
yet) - step 1
svn-id: r35757
|
|
svn-id: r35755
|