Hi all,
Just wanted to check if anyone got DirectX working in Window mode… I mean,
in a way where surfaces can be in video memory…
See also my post with the subject ‘Windows: Why is SDL not using hardware
for surfaces in window mode ?’
Best,
Sam
I believe that in a window you are trapped to the bit depth and video mode
that your desktop is running in.
Windows (and all OSes I think) uses software surfaces, and therefore so must
your application, unless you run it fullscreen.> ----- Original Message -----
From: sam@novalicious.com (Sam Nova)
To:
Sent: Thursday, May 16, 2002 6:51 AM
Subject: [SDL] DirectX not using video memory for surfaces in window mode !Hi all,
Just wanted to check if anyone got DirectX working in Window mode… I
mean,
in a way where surfaces can be in video memory…See also my post with the subject ‘Windows: Why is SDL not using hardware
for surfaces in window mode ?’Best,
Sam
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
I believe that in a window you are trapped to the bit depth and video mode
that your desktop is running in.
This sounds VERY right. My card is running in 32 bit mode, so I do
following:
screen = SDL_SetVideoMode(640, 480, 32, SDL_HWSURFACE | SDL_DOUBLEBUF);
Could this be a problem, that SDL might give me RGBA but the card might run
BGRA or something ? If this is the problem, then how do I get the
information ?
Windows (and all OSes I think) uses software surfaces, and
therefore so must
your application, unless you run it fullscreen.
Still DirectX allows window mode to be used with hardware buffers. !!
-Sam>
----- Original Message -----
From: “Sam Nova” <@Sam_Nova>
To:
Sent: Thursday, May 16, 2002 6:51 AM
Subject: [SDL] DirectX not using video memory for surfaces in
window mode !Hi all,
Just wanted to check if anyone got DirectX working in Window mode… I
mean,
in a way where surfaces can be in video memory…See also my post with the subject ‘Windows: Why is SDL not
using hardware
for surfaces in window mode ?’Best,
Sam
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Actually, I would be interested in getting a Direct3D context similar to
how you get an OpenGL context, but using DirectInput and all… Some 3D
stuff lends itself reasonably well to being targetted at both OpenGL and
D3D. Since too many card vendors have crappy OpenGL drivers but decent
D3D, it’s worthwhile for us to consider offering the support even if it
will be faster to use OpenGL.
Serious Sam 2, for example, does this. It doesn’t use SDL I assume, but
Ryan might have a couple of comments about this. Possibly not though, I
don’t know how evil an NDA he was forced to sign to be allowed to work on
porting it… ;)On Wed, May 15, 2002 at 10:51:49PM +0200, Sam Nova wrote:
Just wanted to check if anyone got DirectX working in Window mode… I mean,
in a way where surfaces can be in video memory…
–
Joseph Carter Goldfish don’t bounce
- Knghtbrd notes he has mashed potatoes for brains tonight
yum, can I have some?
um … - Knghtbrd hides from Valkyrie
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020515/e854b913/attachment.pgp
Ah, just what the world needs – a Windows-specific cross-platform
library… :)On Wed, May 15, 2002 at 05:41:35PM -0700, Joseph Carter wrote:
Actually, I would be interested in getting a Direct3D context similar to
how you get an OpenGL context, but using DirectInput and all… Some 3D
stuff lends itself reasonably well to being targetted at both OpenGL and
D3D. Since too many card vendors have crappy OpenGL drivers but decent
D3D, it’s worthwhile for us to consider offering the support even if it
will be faster to use OpenGL.
–
Matthew Miller @Matthew_Miller http://www.mattdm.org/
Boston University Linux ------> http://linux.bu.edu/
That’s not what I want and you know it. =)
What I want is, in the case we have D3D available (Win32), we may use it
in place of OpenGL at the user’s request, since it’s just a back-end to
our renderer. We’re already going to potentially need more than one
back-end unless ATI and NVIDIA pull their heads out and start cooperating
on extensions.On Wed, May 15, 2002 at 09:34:43PM -0400, Matthew Miller wrote:
Actually, I would be interested in getting a Direct3D context similar to
how you get an OpenGL context, but using DirectInput and all… Some 3D
stuff lends itself reasonably well to being targetted at both OpenGL and
D3D. Since too many card vendors have crappy OpenGL drivers but decent
D3D, it’s worthwhile for us to consider offering the support even if it
will be faster to use OpenGL.Ah, just what the world needs – a Windows-specific cross-platform
library…
–
Joseph Carter <-- That boy needs therapy
RFC 882 put the dot in .com, not Sun Microsystems
– Seen on Slashdot
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020515/64f656e3/attachment.pgp
Serious Sam 2, for example, does this. It doesn’t use SDL I assume, but
Ryan might have a couple of comments about this. Possibly not though, I
don’t know how evil an NDA he was forced to sign to be allowed to work on
porting it…
If we’re talking about 2D surfaces, this has nothing in common with the
Serious Engine.
Lots of engines have both GL and D3D support, and what they do is add an
abstraction layer. Instead of glVertex() you’d call
my3DAPI_specifyVertex() or whatnot and then the engine will route that
through the correct API. In practical terms, this is a pain, because you
count on rendering APIs to have similar pipelines or you limit yourself to
more generic 3D stuff (define polygon, map a texture onto it, etc).
If we’re talking about mapping OpenGL calls to Direct3D…nothing I know
of (Serious Engine or otherwise) does that.
–ryan.
If we’re talking about 2D surfaces, this has nothing in common with the
Serious Engine.
We’re not. =)
Lots of engines have both GL and D3D support, and what they do is add an
abstraction layer. Instead of glVertex() you’d call
my3DAPI_specifyVertex() or whatnot and then the engine will route that
through the correct API. In practical terms, this is a pain, because you
count on rendering APIs to have similar pipelines or you limit yourself to
more generic 3D stuff (define polygon, map a texture onto it, etc).
Yes, generally speaking this is what I meant. Though in my case, the
abstraction layer looks more like my3DAPI_CramLotsOfGeometryToCard () most
of the time. 
If we’re talking about mapping OpenGL calls to Direct3D…nothing I know
of (Serious Engine or otherwise) does that.
There is a wrapper to go the other direction. It’s not very good or very
fast, but it works. It was implemented as an exercise to prove it could
be done relatively easily and perhaps annoy someone at Microsoft. I’m not
sure it succeeded in any of these goals, but it actually did run with a
few examples I tried for the sake of trying with only minor porting work.On Wed, May 15, 2002 at 10:22:27PM -0400, Ryan C. Gordon wrote:
–
Joseph Carter You expected a coherent reply?
uh oh, what have I started 
rofl… distro nick wars.
- Slackware just waits for /nick Gnome, /nick KDE, and then world war 4
to break out
:oP
no’one would dare /nick RedHat
mew.
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020515/d732ac89/attachment.pgp
At 06:54 AM 5/16/02 +1000, you wrote:
I believe that in a window you are trapped to the bit depth and video mode
that your desktop is running in.
Windows (and all OSes I think) uses software surfaces, and therefore so must
your application, unless you run it fullscreen.
As far as I’ve seen the only SDL implementation that allow HW surfaces on
windowed mode is the AmigaOS port I’ve done. The problem is that the
application should read the correct pitch value (that is the desktop screen
one and not the window width) and that if you cover the SDL window with
another window the graphics is drawn anyway. The nice thing is that you
have HW acceleration on every mode if you want (and for machines with low
CPU power and slow memory bandwidth like Amigas the HW accel is VERY
important).
I wonder if I should maintain this behaviour or if I should force soft
bitmaps for windowed mode.
Bye,
Gabry (gabrielegreco at tin.it)
‘winex’ does /me runs and hides
-EvilTypeGuyOn Wed, May 15, 2002 at 10:22:27PM -0400, Ryan C. Gordon wrote:
Serious Sam 2, for example, does this. It doesn’t use SDL I assume, but
Ryan might have a couple of comments about this. Possibly not though, I
don’t know how evil an NDA he was forced to sign to be allowed to work on
porting it…
If we’re talking about mapping OpenGL calls to Direct3D…nothing I know
of (Serious Engine or otherwise) does that.
If we’re talking about mapping OpenGL calls to Direct3D…nothing I know
of (Serious Engine or otherwise) does that.‘winex’ does /me runs and hides
No, it doesn’t: WineX maps Direct3D calls to OpenGL.
Not that this matters; doing this in SDL means that we’d have to have not
just GL context creation, but an entire OpenGL wrapper, which would suck
to maintain. (Doubly so if we we started emulating OpenGL with Direct3D
calls inside this wrapper.)
Oh, and blahblahblah, positive reinforcement to driver developers for
supporting closed “standards” better than open ones, blahblahblah.
–ryan.
Oops. Sorry, I was thinking that way, not the other way around My bad.
-EvilTypeGuyOn Thu, May 16, 2002 at 11:16:12AM -0400, Ryan C. Gordon wrote:
If we’re talking about mapping OpenGL calls to Direct3D…nothing I know
of (Serious Engine or otherwise) does that.‘winex’ does /me runs and hides
No, it doesn’t: WineX maps Direct3D calls to OpenGL.
As far as I’ve seen the only SDL implementation that allow HW surfaces on
windowed mode is the AmigaOS port I’ve done. The problem is that the
application should read the correct pitch value (that is the desktop screen
one and not the window width) and that if you cover the SDL window with
another window the graphics is drawn anyway. The nice thing is that you
have HW acceleration on every mode if you want (and for machines with low
CPU power and slow memory bandwidth like Amigas the HW accel is VERY
important).
I wonder if I should maintain this behaviour or if I should force soft
bitmaps for windowed mode.
I’ve forced soft bitmaps for windowed mode on the principle that if you’re
running in windowed mode, you should be a nice windowed app and not write
all over other windows. If you can get hardware accelerated blitting and
clipping working together, then by all means, allow hardware surfaces.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
At 08:45 AM 5/16/02 -0700, you wrote:
I wonder if I should maintain this behaviour or if I should force soft
bitmaps for windowed mode.
I’ve forced soft bitmaps for windowed mode on the principle that if you’re
running in windowed mode, you should be a nice windowed app and not write
all over other windows. If you can get hardware accelerated blitting and
clipping working together, then by all means, allow hardware surfaces.
Sadly clipping, as you correctly thought, doesn’t work, I’ve received just
today a mail by a user about the fact that some ports use to write on the
other desktop windows. I think I’ll change that, since most apps simply do:
SDL_SetVideoMode(x,x,x,SDL_HWSURFACE | x);
…both for windowed and fullscreen modes and this bring inconsistent
behaviours on straight ports…
Bye,
Gabry (gabrielegreco at tin.it)
As far as I’ve seen the only SDL implementation that allow HW
surfaces on
windowed mode is the AmigaOS port I’ve done. The problem is that the
application should read the correct pitch value (that is the
desktop screen
one and not the window width) and that if you cover the SDL window with
another window the graphics is drawn anyway. The nice thing is that you
have HW acceleration on every mode if you want (and for
machines with low
CPU power and slow memory bandwidth like Amigas the HW accel is VERY
important).I wonder if I should maintain this behaviour or if I should force soft
bitmaps for windowed mode.I’ve forced soft bitmaps for windowed mode on the principle that if you’re
running in windowed mode, you should be a nice windowed app and not write
all over other windows. If you can get hardware accelerated blitting and
clipping working together, then by all means, allow hardware surfaces.
Sorry, I don’t follow you (I’m NOT saying you are wrong). But when looking
at Allegro that uses hardware (DirectX) to do window modes, I get confused.
Okay, they stop the application when it isn’t the active one !!! (or at
least this is what they did on the examples I looked at). Please let me know
what clippings you are talking about, so I can follow you.
best,
Sam>
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
No comments ?
And one question to Sam Lantinga, do you plan to change the window mode to
use hardware for the next big release (2.0) ?
-Sam Nova> -----Original Message-----
From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of Sam
Nova
Sent: Thursday, May 16, 2002 10:42 PM
To: sdl at libsdl.org
Subject: RE: [SDL] DirectX not using video memory for surfaces in window
mode !As far as I’ve seen the only SDL implementation that allow HW
surfaces on
windowed mode is the AmigaOS port I’ve done. The problem is that the
application should read the correct pitch value (that is the
desktop screen
one and not the window width) and that if you cover the SDL
window withanother window the graphics is drawn anyway. The nice thing
is that youhave HW acceleration on every mode if you want (and for
machines with low
CPU power and slow memory bandwidth like Amigas the HW accel is VERY
important).I wonder if I should maintain this behaviour or if I should force soft
bitmaps for windowed mode.I’ve forced soft bitmaps for windowed mode on the principle
that if you’re
running in windowed mode, you should be a nice windowed app and
not write
all over other windows. If you can get hardware accelerated
blitting and
clipping working together, then by all means, allow hardware surfaces.Sorry, I don’t follow you (I’m NOT saying you are wrong). But when looking
at Allegro that uses hardware (DirectX) to do window modes, I get
confused.
Okay, they stop the application when it isn’t the active one !!! (or at
least this is what they did on the examples I looked at). Please
let me know
what clippings you are talking about, so I can follow you.best,
Sam
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
No comments ?
And one question to Sam Lantinga, do you plan to change the window mode to
use hardware for the next big release (2.0) ?
Yes, it will be an option on some platforms.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment