Questions about SDL 1.3

Zamliman · October 22, 2010, 3:40pm

i have the same problem as the 6th

Edward_Byard · October 27, 2010, 1:16pm

If you’re using Windows, try this:

Code:

#include “SDL.h”
#include “SDL_image.h”
#include <stdio.h>

using namespace System;
using namespace System::Text;
using namespace System::IO;

int wmain(int argc, char *argv[])
{
int numdisplays, defaultdisplay, i;
int nummodes, j;
int * scalemode;

SDL_Surface *testImg;
SDL_Rect srcRect,dstRect;
SDL_Texture *testTxu;

SDL_DisplayMode mode;

if (SDL_Init(SDL_INIT_VIDEO) != 0) 
{
	printf("Error initializing SDL: ");
	return 1;
}

IMG_Init(IMG_INIT_PNG);
testImg = IMG_Load("test.png");
if (testImg == NULL)
{
	printf("Error loading file %s",IMG_GetError());
	return 1;
}
SDL_DisplayFormat(testImg);

atexit(SDL_Quit);

SDL_SelectVideoDisplay(0);
SDL_Window *window1 = SDL_CreateWindow("Window 1",0,0,640,480,SDL_WINDOW_SHOWN|SDL_WINDOW_MAXIMIZED);
SDL_CreateRenderer(window1,-1,SDL_RENDERER_ACCELERATED|SDL_RENDERER_SINGLEBUFFER|SDL_RENDERER_ACCELERATED);
SDL_SelectRenderer(window1);

testTxu = SDL_CreateTextureFromSurface(0,testImg);
SDL_RenderClear(); /* clear the screen */
SDL_RenderCopy(testTxu,NULL,NULL); /* render the area of the texture defined by textureRegion (use NULL for the full thing)

to the area of the screen defined by screenRegion (use NULL for the full screen) NOTE: the texture API performs scaling automatically. Make sure you want the texture to be stretched to fit the specified region!/
SDL_RenderPresent(); / update the screen */

SDL_SelectVideoDisplay(1);
SDL_Window *window2 = SDL_CreateWindow("Window 2",0,480,640,480,SDL_WINDOW_SHOWN|SDL_WINDOW_MAXIMIZED);

SDL_CreateRenderer(window2,-1,SDL_RENDERER_ACCELERATED|SDL_RENDERER_SINGLEBUFFER|SDL_RENDERER_ACCELERATED);
SDL_SelectRenderer(window2);

testTxu = SDL_CreateTextureFromSurface(0,testImg);
SDL_RenderClear(); /* clear the screen */
SDL_RenderCopy(testTxu,NULL,NULL); /* render the area of the texture defined by textureRegion (use NULL for the full thing)

to the area of the screen defined by screenRegion (use NULL for the full screen) NOTE: the texture API performs scaling automatically. Make sure you want the texture to be stretched to fit the specified region!/
SDL_RenderPresent(); / update the screen */

numdisplays = SDL_GetNumVideoDisplays();
defaultdisplay = SDL_GetCurrentVideoDisplay();
printf("Currently using display %d.\n", defaultdisplay);

for (i = 0; i < numdisplays; ++i) 
{
	printf("\nEnumerating modes for display %d\n", i);
	nummodes = SDL_GetNumDisplayModes();
	for (j = 0; j < nummodes; ++j) 
	{
		SDL_GetDisplayMode(j, &mode);
		printf("  Mode %d:  %dx%d %dHz %d bpp\n", j, mode.w, mode.h, mode.refresh_rate, SDL_BITSPERPIXEL(mode.format));
	}
	printf("  %d modes.\n", nummodes);
}
SDL_FreeSurface(testImg);

IMG_Quit();
SDL_SelectVideoDisplay(defaultdisplay);
SDL_DestroyWindow(window1);
SDL_DestroyWindow(window2);
return 0;

}

Zamliman · October 27, 2010, 8:48pm

Would that work with opengl code, i mean only using opengl

Benjamin_Xiao · November 3, 2010, 8:09am

So it seems like the only functions I am not using are the SDL_SelectVideoDisplay calls. Is this needed for multi-windows?

Micah_Brening · November 4, 2010, 1:19am

Benjamin Xiao wrote:

I’ve compiled SDL 1.3 rev 4634 and I have ported my project to use the new API. However I have a few questions.

1.) How do I draw stuff directly to a SDL_Texture? Currently I am blitting to a SDL_Surface then using SDL_CreateTextureFromSurface to convert it for SDL_RenderCopy. I feel that there should be a more efficient way to do this, but I can’t find a function that does direct drawing to a texture in the new api documentation.

2.) Since we’re using SDL_Textures, do we still need to convert our surfaces with SDL_DisplayFormatAlpha, or can we go ahead and convert it to a texture directly?

1.) I am about 98% sure the answer to this is that you can’t. In SDL1.2 and using OpenGL you had to modify the surface, and generate the new texture. The issue had to do with the textures reside in video memory rather than system memory, etc. If it is causing a problem, you could use two textures and double buffer it, so you show one texture, upload the new texture, and flip. (I don’t know if that makes sense) There was a way to modify a texture with OpenGL, if I remember correctly, but every documentation said not to use it because it was extremely slow. I don’t know if threading would be an option. Build up a buffer of textures and flip through them. Might be a bad idea on low memory video cards.

2.) This should be handled with the creating of textures. SDL_DisplayFormat and SDL_DisplayFormat are only needed if you are blitting the surface to the screen.

I’m still learning 1.3, and it is still in heavy development, so I may be right today, wrong tomorrow

Pavel_Kanzelsberger · November 5, 2010, 10:26pm

I guess that function is used to selected another (other than main) display for creating your windows in multi-display setup.

PavelOn 3.11.2010, at 9:09, Benjamin Xiao wrote:

So it seems like the only functions I am not using are the SDL_SelectVideoDisplay calls. Is this needed for multi-windows?

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Edward_Byard · December 27, 2010, 4:59pm

1.) How do I draw stuff directly to a SDL_Texture? Currently I am blitting to a SDL_Surface then using SDL_CreateTextureFromSurface to convert it for SDL_RenderCopy. I feel that there should be a more efficient way to do this, but I can’t find a function that does direct drawing to a texture in the new api documentation.

I have had to do this on a project. It is horrifically inefficient - ~58ms to convert a 1024x768 surface to a texture and display it, and I have 2 windows, so double that. I really do not know how to fix this.

If SDL 1.3 is made to be able to be a “frame” based system then there needs to be a way to either:

render a surface directly to a window
convert a surface to a texture very quickly
copy a portion of a texture to another texture quickly, which can then be rendered to the screen

There’s also a big question mark over scaling in 1.3 - I can see no fast /easy way to draw a new frame and then scale it. I draw lots of small rectangles from a large texture on to the screen - problem is you can’t scale with this method as there is no way to fast-copy between textures.

Mason_Wheeler · December 27, 2010, 5:37pm

I had similar problems, so I wrote up a patch to implement #3. I submitted it
back in April, and apparently it’s never been touched or looked at since.

http://bugzilla.libsdl.org/show_bug.cgi?id=983

This is for the OpenGL renderer only, but similar concepts exist in Direct3D and
you shouldn’t have too much trouble extending it if that’s what you’re using.________________________________
From: e_byard@yahoo.co.uk (Edward Byard)
To: sdl at lists.libsdl.org
Sent: Mon, December 27, 2010 8:59:14 AM
Subject: Re: [SDL] Questions about SDL 1.3

Quote:

1.) How do I draw stuff directly to a SDL_Texture? Currently I am blitting to a
SDL_Surface then using SDL_CreateTextureFromSurface to convert it for
SDL_RenderCopy. I feel that there should be a more efficient way to do this, but
I can’t find a function that does direct drawing to a texture in the new api
documentation.

I have had to do this on a project. It is horrifically inefficient - ~58ms to
convert a 1024x768 surface to a texture and display it, and I have 2 windows, so
double that. I really do not know how to fix this.

If SDL 1.3 is made to be able to be a “frame” based system then there needs to
be a way to either:

render a surface directly to a window
convert a surface to a texture very quickly
copy a portion of a texture to another texture quickly, which can then be
rendered to the screen

There’s also a big question mark over scaling in 1.3 - I can see no fast /easy
way to draw a new frame and then scale it. I draw lots of small rectangles from
a large texture on to the screen - problem is you can’t scale with this method
as there is no way to fast-copy between textures.

Santiago_Radeff · December 27, 2010, 7:14pm

----- Reply message -----De: “@Santiago_Radeff” <@Santiago_Radeff>
Fecha: lun., dic. 27, 2010 20:11
Asunto: Re: [SDL] Questions about SDL 1.3
Para: “Mason Wheeler”

----- Reply message -----
De: “Mason Wheeler”
Fecha: lun., dic. 27, 2010 18:37
Asunto: [SDL] Questions about SDL 1.3
Para:

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Mason_Wheeler · December 27, 2010, 7:40pm

Render targets (intermediate textures) are incredibly useful when you need to do
things more complicated than simply rendering predefined images directly to the
screen.

For example, let’s say you want to create a text box that displays text one
character at a time. Without render targets, your display code would read like
this, in psedudocode:

procedure RenderTextBox
DisplayedCharacterList.Append(GetNextCharacter(CurrentMessage))
RenderTextBoxImage(TextBoxLocation)
for i from 0 DisplayedCharacterList.length
RenderCharacter(DisplayedCharacterList[i],
ScreenCoordinatesToTextboxCoordinates(CalculateCharacterPosition(i)))
end

But if you’re storing the text box in a render target, you can update it as you
go:

procedure RenderTextBox
RenderCharacter(GetNextCharacter(CurrentMessage), TextBoxTexture,
CalculateCharacterPosition(MessageCounter))
Inc(MessageCounter)
RenderToScreen(TextBoxTexture, TextBoxLocation))
end

Simpler code and no need for a loop inside the rendering.________________________________
From: santiago at dragontech.net (Santiago Radeff)
Subject: Re: [SDL] Questions about SDL 1.3

Why do you need an intermediate texture? Use a sdl rect to render a portion of
it to there screen.

Enviado desde mi HTC
----- Reply message -----
De: “Mason Wheeler” <@Mason_Wheeler>
Fecha: lun., dic. 27, 2010 18:37
Asunto: [SDL] Questions about SDL 1.3
Para:

I had similar problems, so I wrote up a patch to implement #3. I submitted it
back in April, and apparently it’s never been touched or looked at since.

http://bugzilla.libsdl.org/show_bug.cgi?id=983">http://bugzilla.libsdl.org/show_bug.cgi?id=983

This is for the OpenGL renderer only, but similar concepts exist in Direct3D and
you shouldn’t have too much trouble extending it if that’s what you’re using.

From: e_byard@yahoo.co.uk (Edward Byard)
To: sdl at lists.libsdl.org
Sent: Mon, December 27, 2010 8:59:14 AM
Subject: Re: [SDL] Questions about SDL 1.3

Quote:

1.) How do I draw stuff directly to a SDL_Texture? Currently I am blitting to a
SDL_Surface then using SDL_CreateTextureFromSurface to convert it for
SDL_RenderCopy. I feel that there should be a more efficient way to do this, but
I can’t find a function that does direct drawing to a texture in the new api
documentation.

I have had to do this on a project. It is horrifically inefficient - ~58ms to
convert a 1024x768 surface to a texture and display it, and I have 2 windows, so
double that. I really do not know how to fix this.

If SDL 1.3 is made to be able to be a “frame” based system then there needs to
be a way to either:

render a surface directly to a window
convert a surface to a texture very quickly
copy a portion of a texture to another texture quickly, which can then be
rendered to the screen

There’s also a big question mark over scaling in 1.3 - I can see no fast /easy
way to draw a new frame and then scale it. I draw lots of small rectangles from
a large texture on to the screen - problem is you can’t scale with this method
as there is no way to fast-copy between textures.

Edward_Byard · December 27, 2010, 7:58pm

Intermediate textures are very useful indeed.

My big problem is that my target systems will be one of three screen sizes (2x 512x384, 2x1600x1080 and 2x1024x768). I need to be able to draw a finished “frame” to the window - something I can’t do at the moment as you can’t draw Rects to the renderer.

Code:

SDL_RenderCopy(mgtTextures[scrNum],&srcRect,&dstRect);

…will draw stuff to the renderer, sure, but you can’t do any scaling with this. If you could copy to an intermediate texture, and then just do the line above with NULL as the destination rectangle, everything would be OK. Even then, the scaling stuff needs work as the quality is very poor. I can’t get 3 different sets of graphics made for each screen size

Mason_Wheeler · December 27, 2010, 8:02pm

Wait, what do you mean you can’t scale with this? When you draw a rect to the
renderer, if you make the width and height of srcRect different from the
dimensions of dstRect, it will scale.________________________________
From: e_byard@yahoo.co.uk (Edward Byard)
Subject: Re: [SDL] Questions about SDL 1.3

Intermediate textures are very useful indeed.

My big problem is that my target systems will be one of three screen sizes (2x
512x384, 2x1600x1080 and 2x1024x768). I need to be able to draw a finished
"frame" to the window - something I can’t do at the moment as you can’t draw
Rects to the renderer.

Code:

SDL_RenderCopy(mgtTextures[scrNum],&srcRect,&dstRect);

…will draw stuff to the renderer, sure, but you can’t do any scaling with this.
If you could copy to an intermediate texture, and then just do the line above
with NULL as the destination rectangle, everything would be OK. Even then, the
scaling stuff needs work as the quality is very poor. I can’t get 3 different
sets of graphics made for each screen size

Ken_Rogoway · December 27, 2010, 8:04pm

I’ve pointed that out in another post as well. I keep hearing that scaling
doesn’t work, but it works well and just as you (Mason) describe.

KenFrom: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Mason Wheeler
Sent: Monday, December 27, 2010 2:03 PM
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Questions about SDL 1.3

Wait, what do you mean you can’t scale with this? When you draw a rect to
the renderer, if you make the width and height of srcRect different from the
dimensions of dstRect, it will scale.

From: e_byard@yahoo.co.uk (Edward Byard)
Subject: Re: [SDL] Questions about SDL 1.3

Intermediate textures are very useful indeed.

My big problem is that my target systems will be one of three screen sizes
(2x 512x384, 2x1600x1080 and 2x1024x768). I need to be able to draw a
finished “frame” to the window - something I can’t do at the moment as you
can’t draw Rects to the renderer.

Code:

SDL_RenderCopy(mgtTextures[scrNum],&srcRect,&dstRect);

…will draw stuff to the renderer, sure, but you can’t do any scaling with
this. If you could copy to an intermediate texture, and then just do the
line above with NULL as the destination rectangle, everything would be OK.
Even then, the scaling stuff needs work as the quality is very poor. I can’t
get 3 different sets of graphics made for each screen size Sad
http://forums.libsdl.org/images/smiles/icon_sad.gif

Edward_Byard · December 27, 2010, 9:11pm

Wait, what do you mean you can’t scale with this? When you draw a rect to the renderer, if you make the width and height of srcRect different from the dimensions of dstRect, it will scale.

Maybe I’m not explaining myself very well. You’re correct in what you say, but my problem is that I draw many individual small rectangles to the renderer, from a large texture, for which you have to supply both the source and destination rectangles. This is fine if you use one fixed window size.

If not, then you’ll need to do a load of math on the destination rectangle to get everything scaled correctly - which I haven’t figured how to do. Examples are very, very welcome.

I’d like to be able to draw a whole new frame on an intermediate texture (of size, let’s say 1024x768), and then pass that texture to the renderer with NULL as the destination rectangle, and so a full screen render on whatever window size I’m using.

Make sense?!?

Thanks
Ed

Mason_Wheeler · December 27, 2010, 9:28pm

I see. You’re working with windows of different resolutions, but you want them
to all behave as if they were a fixed, predefined resolution and scale
everything properly to the actual resolution.

That’s another problem I had to solve for my game engine, but I haven’t
submitted the patch for it yet. Basically, I implemented a way to give a
SDL_Window a “logical resolution” property independent of the physical
resolution. This is trivial to implement on the GL renderer (and probably on
the D3D one as well) by simply setting the viewport to a different size than the
window’s pixel size and letting the GPU handle the conversions.

I’d like to submit the patch, but it contains changes in a lot of the same files
as my render targets patch, and until that’s applied to the source tree it’ll be
really messy to make a patch containing only the “logical size” change set.________________________________
From: e_byard@yahoo.co.uk (Edward Byard)
Subject: Re: [SDL] Questions about SDL 1.3

Quote:

Wait, what do you mean you can’t scale with this? When you draw a rect to the
renderer, if you make the width and height of srcRect different from the
dimensions of dstRect, it will scale.

Maybe I’m not explaining myself very well. You’re correct in what you say, but
my problem is that I draw many individual small rectangles to the renderer, from
a large texture, for which you have to supply both the source and destination
rectangles. This is fine if you use one fixed window size.

If not, then you’ll need to do a load of math on the destination rectangle to
get everything scaled correctly - which I haven’t figured how to do. Examples
are very, very welcome.

I’d like to be able to draw a whole new frame on an intermediate texture (of
size, let’s say 1024x768), and then pass that texture to the renderer with NULL
as the destination rectangle, and so a full screen render on whatever window
size I’m using.

Make sense?!?

Thanks
Ed

Edward_Byard · December 27, 2010, 10:14pm

Got it. I’m being a dunce.

Code:

			dstRect.w = (float)srcRect.w * ((float)viewportWidth / 1024.0);
			dstRect.h = (float)srcRect.h * ((float)viewportHeight / 768.0);
			dstRect.x = (float)xPos * ((float)viewportWidth  / 1024.0);
			dstRect.y = (float)yPos * ((float)viewportHeight / 768.0);
			SDL_RenderCopy(mgtTextures[scrNum],&srcRect,&dstRect);

Ed