Quote:Original post by Stompy9999
The "water in fullscreen" issue is still weighing on my mind. I don't consider myself very skilled with graphics programming(hence why I'm using SDL for graphics), but I can identify where a problem is. The way I see it, to keep alpha blending, I have to find a way to not be required to redraw the alpha tiles over and over.

The other, more obvious solution, is to not use alpha blending at all. Although it won't look as cool, at least it will work. And after all, I'd rather it be functional, even at the cost of a nice looking effect. This choice is looking better by the minute.

I don't know how it works in SDL or OpenGL, but 2D programming in Direct3D is pretty simple, especially if you use the sprite interface. But, that brings up portability issues and such.

Maybe as an alternative you could include frames for him when he's underwater so that you can tell that he's underwater.

Is it possible to make each section of water be one big rectangle instead of many tiles?

Im not sure how alpha blending works in SDL but if by some of chance im correct, this might help. Possibly, each water tile is rendered along with what is behind it at the same time. If your background is made up of small tiles like the foreground, then that might mean that for each water tile up to 8 (not sure how your multilayered background works) background tile texture are being loaded, then worked on, then unloaded. So for a water section of 40 tiles, you would be loading a total 360 tiles compared to ~80 tiles if you were to use a big water tile.

Then again that is all my uninformed and uneducated hypothesis. Just hope it helps. *crosses fingers*

I'm not all that knowledgeable about the internal details of SDL and OpenGL too even though I use them, but I remember that transparency effects were pretty easy to do with sprites rendered with OpenGL. In my case I'm assuming that everyone will have enough hardware acceleration to cope.

Since you probably want to stick with SDL only for Blocky Man I did a quick search on the problem and according to this Q&A at this website it might be worth trying software surfaces and seeing if that makes a difference in performance.

Does it also slow down in windowed mode also? Maybe not as much as fullscreen, but some?

Quote:Original post by envy3d
Does it also slow down in windowed mode also? Maybe not as much as fullscreen, but some?

I believe that he said it works fine in windowed mode, just not in fullscreen.

It only seems to slow down in fullscreen mode. I've tried using software surfaces, but they don't seem to speed it up. I also tried using DisplayFormatAlpha, which didn't work either. I'll probably just end up taking out the alpha blending, and using an underwater frame for Blocky Man.

An excerpt from the SDL mailing list, you might want to try some of these:

Quote:
hi, sorry i'm sure there was something on this or similar recently on this group
but i cant find it.

i have written a game with very slack plotting routines and alot of alpha
blending.

it runs fine in windows xp windowed, but when i set if for full screen it slows
down alot, what steps do i take to rectify this?

Quote:
SDL in fullscreen will be using VSync, check your "slowdown" isn't due
to that.

Also, if you are doing alpha blending, this probably means you are
reading from a surface. If you are, make sure that surface isn't in
video ram or it will be slow as the AGP bus is optimised for writes,
but very slow for reads. In windowed mode, the surfaces won't be in
video ram.

Quote:
SDL no longer uses DirectDraw by default which may be slowing down your
blitting. Adding this before SDL_Init() may help:

SDL_putenv("SDL_VIDEODRIVER=directx")

Are you using per-pixel or per surface alpha?
If you aren't already doing so, try using a per-surface alpha of 128, its optimised. (see here)

Un-related to this issue but a post you made further down, I thought I'd post it here so you will most likely read it :)

Someone mentioned the camera following too sharply so you might not be able to see things on the ground, here's a nice idea of how to implement it.

Attach your camera centre point to the player via a damped spring so when the player moves the camera springs back in to place depending on how quickly the player is moving from the centre :D