Bob Pendleton wrote:
I don’t want scaling. ?I want to be able to specify logical and physical
resolution separately so that I can avoid scaling. ?I want black bars.
What you want implies scaling. It can only be done using a
transform that scales and translates to make the logical match the
physical.
I DO NOT WANT THE LOGICAL RESOLUTION TO MATCH THE PHYSICAL RESOLUTION!!!
Suppose I have a 640x480 game running on a 1024x768 LCD. ?What I want is
to is this:
?- Set the screen resolution to 1024x768 to prevent hardware scaling.
?- Run the game in a 640x480 portion of the screen.
?- Put a black border around the 640x480 portion of the screen that I
am using.
Now, I could do all of that on top of SDL. ?However, there are some
significant advantage to letting SDL handle of this:
?- I don’t need to adjust all of my graphics operations to render to
the center of the screen.
?- SDL only needs to allocate a 640x480 backbuffer.
?- SDL already contains most of the code required to make this work, so
this would be a relatively small change on the SDL side.
That’s called a view port transformation. Again, a 40+ year old
technique. It gives you exactly what you want.
Just take over the screen, set the transform, and draw. You don’t have
to change anything in your code to adapt to different screen sizes.
OTOH, if you plop a 640x480 window in the middle of my 1440x1050
screen it is going to be really small…
Bob PendletonOn Sat, May 2, 2009 at 9:29 PM, Rainer Deyke wrote:
On Sat, May 2, 2009 at 6:17 PM, Rainer Deyke wrote:
–
Rainer Deyke - rainerd at eldwood.com
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
I really hate it when people say things like that. The cost of doing a
vertex transformation is well known. You measure it in terms of
floating point multiplies and adds. The cost of software and hardware
texture mapping is also well defined, also measured in terms of
floating point multiplies and adds. The performance cost of doing it
in the GPU by use of OpenGL and/or DirectX is also well known.
SDL already does all this very nicely by use of OpenGL. If you want to
do it on a box without hardware acceleration well then there are
literally hundreds of libraries out there that will do it that can be
adapted to work with SDL with very little effort. Take a look as
software mesa, of poke around some of the ancient graphics code left
over from the 386/486 era.
Bob PendletonOn Sun, May 3, 2009 at 8:50 AM, Rainer Deyke wrote:
Gerry JJ wrote:
Den Sat, 02 May 2009 20:29:43 -0600
skrev Rainer Deyke :
I DO NOT WANT THE LOGICAL RESOLUTION TO MATCH THE PHYSICAL
RESOLUTION!!!
Suppose I have a 640x480 game running on a 1024x768 LCD. ?What I want
is to is this:
? - Set the screen resolution to 1024x768 to prevent hardware scaling.
? - Run the game in a 640x480 portion of the screen.
? - Put a black border around the 640x480 portion of the screen that I
am using.
Sure, but what if it’s a 1280x960 LCD? ?You can do a 2x nearest
neighbour scale, and there’ll be no blurring, and no need for black
bars either. ?It’d be just like a 640x480 LCD. ?Better than wasting
75% of the screen, no?
To clarify: I do think that automatic scaling is a useful option, if and
when SDL can perform it efficiently.
±----------------------------------------------------------
Bob Pendleton wrote:> On Sat, May 2, 2009 at 9:29 PM, Rainer Deyke wrote:
Now, I could do all of that on top of SDL. However, there are some
significant advantage to letting SDL handle of this:
- I don’t need to adjust all of my graphics operations to render to
the center of the screen.
- SDL only needs to allocate a 640x480 backbuffer.
- SDL already contains most of the code required to make this work, so
this would be a relatively small change on the SDL side.
That’s called a view port transformation. Again, a 40+ year old
technique. It gives you exactly what you want.
I know how to do it. I already have my own wrapper around SDL that
provides me with a viewport. I think SDL should handle this, and I gave
my reasons, which you didn’t address at all.
–
Rainer Deyke - rainerd at eldwood.com
Bob Pendleton wrote:
SDL already does all this very nicely by use of OpenGL. If you want to
do it on a box without hardware acceleration well then there are
literally hundreds of libraries out there that will do it that can be
adapted to work with SDL with very little effort. Take a look as
software mesa, of poke around some of the ancient graphics code left
over from the 386/486 era.
Scaling isn’t a problem. Scaling as the backbuffer is sent to video
memory, without requiring a scaled-up copy of the backbuffer, is more
difficult (read: impossible without modifying the SDL internals).–
Rainer Deyke - rainerd at eldwood.com
Bob Pendleton wrote:
Now, I could do all of that on top of SDL. ?However, there are some
significant advantage to letting SDL handle of this:
?- I don’t need to adjust all of my graphics operations to render to
the center of the screen.
?- SDL only needs to allocate a 640x480 backbuffer.
?- SDL already contains most of the code required to make this work, so
this would be a relatively small change on the SDL side.
That’s called a view port transformation. Again, a 40+ year old
technique. It gives you exactly what you want.
I know how to do it. ?I already have my own wrapper around SDL that
provides me with a viewport. ?I think SDL should handle this, and I gave
my reasons, which you didn’t address at all.
Yeah, I haven’t addressed your reasons because honestly, none of the
ones you have listed make any sense to me. The only reasonable way to
accomplish what you want is to use a hardware accelerated API. SDL
provides that through OpenGL. That is the way SDL works. You want to
make major changes. Ok, do it. Nothing stopping you.
Bob PendletonOn Sun, May 3, 2009 at 7:18 PM, Rainer Deyke wrote:
On Sat, May 2, 2009 at 9:29 PM, Rainer Deyke wrote:
–
Rainer Deyke - rainerd at eldwood.com
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
Bob Pendleton wrote:
SDL already does all this very nicely by use of OpenGL. If you want to
do it on a box without hardware acceleration well then there are
literally hundreds of libraries out there that will do it that can be
adapted to work with SDL with very little effort. Take a look as
software mesa, of poke around some of the ancient graphics code left
over from the 386/486 era.
Scaling isn’t a problem. ?Scaling as the backbuffer is sent to video
memory, without requiring a scaled-up copy of the backbuffer, is more
difficult (read: impossible without modifying the SDL internals).
We’re talking past each other here. I am talking about scaling as you
draw, not scaling after you draw. But, hey there is a simple way to do
what you want, make your “backbuffer” into a texture and then scale it
as you render it to the screen. Or, you can do it the simple way and
use a renderbuffer. Or even simpler, just set the scaling transform
when you do your rendering.
And, yes, I know a lot about the SDL internals and how hard they are
to modify. I added a windowing API to 1.2 under X. It was part of my
campaign to get Sam to add windows to the SDL API.
Bob PendletonOn Sun, May 3, 2009 at 7:21 PM, Rainer Deyke wrote:
–
Rainer Deyke - rainerd at eldwood.com
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------