Quote:
|
Originally Posted by Shamus
Ah, stars. Cool. 
I'll tag CVS as soon as I can and put an announcement on icculus.  One thing that would be very useful would be the ability to stretch different parts of the screen independently, so that, say, the top half of the screen could have twice the horizontal resolution as the bottom. I'm not sure what the overhead would be (especially if it could be done on a per scanline basis), but it would be a nice thing to have. Even if you could only do 2 different horizontal stretches at the same time.  |
LOL @ remark stars
Before I begin with babbling about scaling or OpenGL, I've been looking in the latest code I could found on my harddrive (being VJ/SDL v1.0.6) and it really shocked me. Did I write this? (since the SDL graphics is almost my handy work I think so) In that case I apoligize and I hope to write a more understanding version what people can use and exploit.
Concerning the scaling. Ofcourse I can write scaling based upon horizontal or vertical base or a mix. The overhead is twice less then when using complete scaling and it's infact a copy of the exact scaling code, only it's directed to X or Y instead of X and Y.
OpenGL is a different mather. The inialisation code (in sdlemu_opengl.c and video.cpp) is infact incorrect and I know the problem why OpenGL is slower then normal SDL blitting:
1. The use of an ackward resolution (instead of 320x240, 640x480, etc);
2. The conversion from a 16bpp surface to a 32bpp (<- SLOW!);
3. OpenGL initialisation items that aren't done.
For VJ (or other projects as well) 1 is not a problem. In fact, this solves the problem when the switch/expension of width and height are made when you use a resolution of for instance 640x480. The textures are smaller then the resolution and will "automaticly" scale to the new resolution ( so your OpenGL hack isn't needed any more). 3 is also not a problem, some simple initialisation are not used or are incorrect. This can easily be fixed.
2, well this is the main problem. The conversion from 16bpp (surface, our renderbuffer) to 32bpp ( src, our OpenGL texture) and then render it to our 16bpp screen ( mainsurface, our main SDL_Display ) takes up most of the time (also mainly because of some missing initalisations) and this has got to be fixed/rewritten. How this will be done, I do not know yet but I have some idea's. And I'll consult the SDL library mailinglist for some pointers.
Shamus, when you've released the source to the public, could you please send it to me ( shalafi.nospam [AT] xs4all [DOT] nl ) so I can work with the latest codebase? I've kinda lost my login information from icculus :/
Regards,
Niels Wagenaar