I finally got around to writing this up. Here’s the rough roadmap for
SDL 1.3 (eventually, 2.0) …
http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&date=2007-10-07§ion=sdl13
Nothing is set in stone, so comments are welcome. Sam has already rocked
through an alarmingly high percentage of this list, even though the list
talks about things that will be done as opposed to things that ARE done
in most cases.
–ryan.
The atomic operations API… has anyone gotten the chance to look over
my patch? If so, comments?On Sun, 07 Oct 2007 17:01:18 -0400 “Ryan C. Gordon” wrote:
I finally got around to writing this up. Here’s the rough roadmap for
SDL 1.3 (eventually, 2.0) …http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&date=2007-10-07§ion=sdl13
Nothing is set in stone, so comments are welcome. Sam has already
rocked through an alarmingly high percentage of this list, even
though the list talks about things that will be done as opposed to
things that ARE done in most cases.–ryan.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Antonio S.J. Musumeci
bile at landofbile.com
http://www.landofbile.com/blog
Ryan C. Gordon wrote:
- A basic API to read/write from the system clipboard would be nice.
- A basic API to support drag’n’drop with the system would be nice.
- Probably other stuff! Let Ryan know what you want!
if you add a basic API for clipboard stuff, i also would like to see a
ver basic api - merely just a function
bool open_url(const char* url);
wich opens the url-string in the systems default browser. this is
definitely a thing that comes handy for most apps and is also a thing
that needs an abstraction via SDL because every platform handles this
completely differently.
if you agree to add that function / mini-api, i could provide some
source code snippets i have collected for win32 and linux.
Yes, this would be very nice. I’d also request to add something like in
the SDL scrap demo. Basically just being able to copy and paste text
would be fine for most people; copying and pasting images would be more
problematic, I think.
SteveOn October 7, 2007 7:16:25 pm Andre Krause wrote:
Ryan C. Gordon wrote:
- A basic API to read/write from the system clipboard would be
nice. - A basic API to support drag’n’drop with the system would
be nice. - Probably other stuff! Let Ryan know what you want!if you add a basic API for clipboard stuff, i also would like to see
a ver basic api - merely just a functionbool open_url(const char* url);
wich opens the url-string in the systems default browser. this is
definitely a thing that comes handy for most apps and is also a thing
that needs an abstraction via SDL because every platform handles this
completely differently.
Mostly everything there looks great, but this whole SDL Texture stuff is kind of
getting me worried again.
A while back it was proposed to have this (IMO, convoluted) system that had to
bind SDL_Surfaces to SDL_Textures, and whenever a change to the texture happened
you had to mess with the texture or something like that. I remember majority
opinion went against this. My main complaint was it would take the Simple out
Simple DirectMedia Layer.
Are we going back to this SDL_Surface/Texture mess? Or will SDL_Texture be
entirely separate data type from SDL_Surface?
Personally I think keeping them separate would be great. When I want to make a
quick and easy graphics app, I can just plain ol’ Surfaces. When I need more
speed and features, I can use the Textures.
Most importantly, will old SDL code still work on SDL 1.3 so I don’t have
completely redo the almost 40 programs I have on my site?
Also, since we have an over all road map do we have estimated release date?
Maybe some time in 2008?
this multipule mouse input thing souds insanely great… i had assumed i would
already be able to do something like this… using a USB and PS/2 mouse
seperatley but it seems not…
all i have to do now is figure out a game concept for one player with two
mice…
i am going to put myself on the list of sdl-1.3 users / testers… at
least when
compiling in linux land.
i have a laptop now so no excuses for not potteing around with my SDL progects
up the sdl! long live sdl!
I finally got around to writing this up. Here’s the rough roadmap for
SDL 1.3 (eventually, 2.0) …http://icculus.org/cgi-bin/finger/finger.pl?user=icculus&date=2007-10-07§ion=sdl13
Nothing is set in stone, so comments are welcome. Sam has already rocked
through an alarmingly high percentage of this list, even though the list
talks about things that will be done as opposed to things that ARE done
in most cases.
Nice move getting rid of SDL_KillThread. A vestigial man page could perhaps
point the user to the SDL condition variable functions, useful for
politely asking
a thread to exit.
VERY well done for finally getting rid of SDLmain! SDLmain was a terrible idea!
Just awful, I can’t begin to tell you. How did that go forward for so long?
“”“
2D acceleration: SDL can use OpenGL or Direct3D behind the scenes with
the 2D interfaces, so we can get acceleration on modern systems where
X11 or DirectDraw just aren’t the fast paths anymore. The framebuffer-
oriented interfaces, like X11, are still there, though, for legacy
platforms and hardware.
”""
This could be good. I use the opengl interface in SDL 1.2 to get two
things done: vbl syncing (in the smooth animation sense of the word)
and interpolated scaling, to take up as much of the screen as possible.*
Unfortunately, on windows, (let’s not mention linux) using opengl was
a very suck-it-and-see experience I guess thanks to spotty drivers.
You may or may not get syncing, you may or may not get intelligible
output, and when you quit you may or may not have a usable system.
Obviously you can’t make this the default behaviour, but equally you
can’t really ask the user to try a graphics mode that’ll leave their
monitor a skew-whiff mess. Even with an “are you sure?” step. However,
I suppose most monitor control panels do this. I didn’t try resetting
the video mode on the skew-whiff machines - I just reset them and
snuck out of the internet cafe.
So I guess my questions here are: will this 2D interface do HW
accelerated scaling? Will it support vbl syncing? Will we be
able to tell when it cannot do these things?
And can we make the subsystem prefer Direct3d on windows?
P.S. The mac, like on windows, now finally allows non-square pixel
video resolutions, but there’s no way to select them in SDL 1.2.
Not even by passing 0x0 which should give you the current mode.
If the current mode is “stretched” SDL resets the resolution to non-stretched.
Bugger.
That’s about it, keep up the great work, guys!
RFOn 10/8/07, sdl-request at lists.libsdl.org wrote:
From: “Ryan C. Gordon”
this multipule mouse input thing souds insanely great… i had assumed
i
would
already be able to do something like this… using a USB and PS/2
mouse
seperatley but it seems not…all i have to do now is figure out a game concept for one player with
two
mice…
Imagine the old Robotron with two joysticks, one to move the
protagonist and the other to control the firing direction. Now imagine
that using mouses.>>> On 10/8/2007 at 5:24 AM, wrote:
–
Lilith
Andre Krause wrote:
wich opens the url-string in the systems default browser. this is
definitely a thing that comes handy for most apps and is also a thing
that needs an abstraction via SDL because every platform handles this
completely differently.
If you want I already have code for it ready for win32/linux/mac :)—
Bye,
Gabry
if you add a basic API for clipboard stuff, i also would like to see a
ver basic api - merely just a functionbool open_url(const char* url);
wich opens the url-string in the systems default browser. this is
definitely a thing that comes handy for most apps and is also a thing
that needs an abstraction via SDL because every platform handles this
completely differently.if you agree to add that function / mini-api, i could provide some
source code snippets i have collected for win32 and linux.
To my knowledge, there’s no standard way to open a default browser on Linux
(Windows and OS X are straightforward). At least something that would work
everywhere. I know there’s xdg-open from xdg-utils, but this probably won’t work
for every window manager. The only other way I know is to execute the the
"which" command via popen() to scan for web browsers with a known name, but then
you don’t know which is the default. I’m curious – which method would SDL use?
Hello !
if you add a basic API for clipboard stuff, i also would like to see a
ver basic api - merely just a functionbool open_url(const char* url);
I think instead adding it to SDL,
it is time to create a helper lib.
for those little functions.
CU
- A basic API to read/write from the system clipboard would be nice.
- A basic API to support drag’n’drop with the system would be nice.
I have no immediate objection to these features, but I hope adding
basic API does not impede implementing fully-featured clipboard
access and drag-and-drop support on top of SDL 1.3.
Depending on the type of applications, handling of platform specific
data types or third party defined drag object may be required. In SDL
1.2, these stuffs are accessible through SysWM facility, by writing
platform dependent codes. I’m just afraid that, if SDL 1.3 provides
basic clipboard/drag-n-drop support, it took all control of the data
format negotiation and alike and it became impossible for application
to add some advanced features.--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/
Ilya Olevsky wrote:
if you add a basic API for clipboard stuff, i also would like to see a
ver basic api - merely just a functionbool open_url(const char* url);
wich opens the url-string in the systems default browser. this is
definitely a thing that comes handy for most apps and is also a thing
that needs an abstraction via SDL because every platform handles this
completely differently.if you agree to add that function / mini-api, i could provide some
source code snippets i have collected for win32 and linux.To my knowledge, there’s no standard way to open a default browser on Linux
(Windows and OS X are straightforward). At least something that would work
everywhere. I know there’s xdg-open from xdg-utils, but this probably won’t work
for every window manager. The only other way I know is to execute the the
"which" command via popen() to scan for web browsers with a known name, but then
you don’t know which is the default. I’m curious – which method would SDL use?
i know - this is exactly the problem with linux. isnt it a shame?
but maybe someone here on the list can take the burden and find a method
that work for the most common linux distro’s ? and on systems, where no
reliable method is known, open_url could return false if it was not able
to open the url. so the application could present at least the
url-string and put it in the clipboard (if sdl 1.3 adds clipboard support)
Torsten Giebl wrote:
Hello !
if you add a basic API for clipboard stuff, i also would like to see a
ver basic api - merely just a functionbool open_url(const char* url);
I think instead adding it to SDL,
it is time to create a helper lib.
for those little functions.CU
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
good idea! i will start with my simple code snippet directly here.
i only have win32 code. but i have pasted the code from wxWidgets
library, that seems to be quite complete, and could be a good starting
point.
#ifdef _WIN32
#include <shellapi.h>
bool open_url(const string& url)
{
// > 32 means no error, <32 means some error happened
return (int)ShellExecute(GetActiveWindow(), “open”, url.c_str(), NULL, NULL, SW_SHOW) > 32;
}
#else
bool open_url(const string& url)
{
// todo
}
#endif
// todo; learn from wxWidgets how to open browser in linux / macos
/* // from wxWidgets
// ----------------------------------------------------------------------------
// Launch default browser
// ----------------------------------------------------------------------------
bool wxLaunchDefaultBrowser(const wxString& url)
{
bool success = true;
wxString finalurl = url;
//if it isn’t a full url, try appending http:// to it
if(wxURI(url).IsReference())
finalurl = wxString(wxT(“http://”)) + url;
#if defined(WXMSW) && wxUSE_CONFIG_NATIVE
wxString command;
// ShellExecute() always opens in the same window,
// so do it manually for new window (from Mahogany)
wxRegKey key(wxRegKey::HKCR, url.BeforeFirst(’:’) + wxT("\shell\open"));
if ( key.Exists() )
{
wxRegKey keyDDE(key, wxT(“DDEExec”));
if ( keyDDE.Exists() )
{
wxRegKey keyTopic(keyDDE, wxT(“topic”));
wxString ddeTopic = keyTopic.QueryDefaultValue();
// we only know the syntax of WWW_OpenURL DDE request
if ( ddeTopic == wxT(“WWW_OpenURL”) )
{
wxString ddeCmd = keyDDE.QueryDefaultValue();
// this is a bit naive but should work as -1 can’t appear
// elsewhere in the DDE topic, normally
if ( ddeCmd.Replace(wxT("-1"), wxT(“0”),
false ) == 1 )// only first occurence
{
// and also replace the parameters
if ( ddeCmd.Replace(wxT("%1"), url, false) == 1 )
{
// magic incantation understood by wxMSW
command << wxT(“WX_DDE#”)
<< wxRegKey(key, wxT(“command”)).QueryDefaultValue() << wxT(’#’)
<< wxRegKey(keyDDE, wxT(“application”)).QueryDefaultValue()
<< wxT(’#’) << ddeTopic << wxT(’#’)
<< ddeCmd;
}
}
}
}
}
//Try wxExecute - if it doesn't work or the regkey stuff
//above failed, fallback to opening the file in the same
//browser window
if ( command.empty() || !wxExecute(command) )
{
int nResult; //HINSTANCE error code
#if !defined(WXWINCE)
// CYGWIN and MINGW may have problems - so load ShellExecute
// dynamically
typedef HINSTANCE (WINAPI LPShellExecute)(HWND hwnd, const wxChar lpOperation,
const wxChar* lpFile,
const wxChar* lpParameters,
const wxChar* lpDirectory,
INT nShowCmd);
HINSTANCE hShellDll = ::LoadLibrary(wxT("shell32.dll"));
if(hShellDll == NULL)
return false;
LPShellExecute lpShellExecute =
(LPShellExecute) ::GetProcAddress(hShellDll,
wxString::Format(wxT("ShellExecute%s"),
#if wxUSE_UNICODE
wxT(“W”)
#else
wxT(“A”)
#endif
#ifdef WXWINCE
)
#else
).mb_str(wxConvLocal)
#endif
);
if(lpShellExecute == NULL)
return false;
// Windows sometimes doesn't open the browser correctly when using mime
// types, so do ShellExecute - i.e. start <url> (from James Carroll)
nResult = (int) (*lpShellExecute)(NULL, NULL, finalurl.c_str(),
NULL, wxT(""), SW_SHOWNORMAL);
// Unload Shell32.dll
::FreeLibrary(hShellDll);
#else
//Windows CE does not have normal ShellExecute - but it has
//ShellExecuteEx all the way back to version 1.0
//Set up the SHELLEXECUTEINFO structure to pass to ShellExecuteEx
SHELLEXECUTEINFO sei;
sei.cbSize = sizeof(SHELLEXECUTEINFO);
sei.dwHotKey = 0;
sei.fMask = 0;
sei.hIcon = NULL;
sei.hInstApp = NULL;
sei.hkeyClass = NULL;
// Not in WinCE
#if 0
sei.hMonitor = NULL;
#endif
sei.hProcess = NULL;
sei.hwnd = NULL;
sei.lpClass = NULL;
sei.lpDirectory = NULL;
sei.lpFile = finalurl.c_str();
sei.lpIDList = NULL;
sei.lpParameters = NULL;
sei.lpVerb = TEXT(“open”);
sei.nShow = SW_SHOWNORMAL;
//Call ShellExecuteEx
ShellExecuteEx(&sei);
//Get error code
nResult = (int) sei.hInstApp;
#endif
// Hack for Firefox (returns file not found for some reason)
// from Angelo Mandato's wxHyperlinksCtrl
// HINSTANCE_ERROR == 32 (HINSTANCE_ERROR does not exist on Windows CE)
if (nResult <= 32 && nResult != SE_ERR_FNF)
return false;
#ifdef WXDEBUG
// Log something if SE_ERR_FNF happens
if(nResult == SE_ERR_FNF)
wxLogDebug(wxT(“Got SE_ERR_FNF from ShellExecute - maybe FireFox”));
#endif
}
#elif wxUSE_MIMETYPE
// Non-windows way
wxFileType *ft = wxTheMimeTypesManager->GetFileTypeFromExtension (_T(“html”));
if (!ft)
{
wxLogError(_T(“No default application can open .html extension”));
return false;
}
wxString mt;
ft->GetMimeType(&mt);
wxString cmd;
bool ok = ft->GetOpenCommand (&cmd, wxFileType::MessageParameters(finalurl));
delete ft;
if (ok)
{
if ( !wxExecute(cmd) )
{
wxLogError(_T(“Failed to launch application for wxLaunchDefaultBrowser”));
return false;
}
}
else
{
// fallback to checking for the BROWSER environment variable
cmd = wxGetenv(wxT(“BROWSER”));
if ( cmd.empty() || !wxExecute(cmd + wxT(" ") + finalurl) )
return false;
}
#else // !wxUSE_MIMETYPE && !(WXMSW && wxUSE_NATIVE_CONFIG)
success = false;
#endif
//success - hopefully
return success;
}
bool
wxExtHelpController::DisplayHelp(const wxString &relativeURL)
{
wxBusyCursor b; // display a busy cursor
#if defined(WXMSW)
wxString url;
url << m_MapFile << ‘\’ << relativeURL.BeforeFirst(’#’);
bool bOk = (int)ShellExecute(NULL, wxT(“open”), url.c_str(),
NULL, NULL, SW_SHOWNORMAL ) > 32;
if ( !bOk )
{
wxLogSysError(_(“Cannot open URL ‘%s’”), relativeURL.c_str());
return false;
}
return true;
#elif defined(WXPM)
wxString url;
url << m_MapFile << ‘\’ << relativeURL.BeforeFirst(’#’);
// will have to fix for OS/2, later…DW
// bool bOk = (int)ShellExecute(NULL, “open”, url,
// NULL, NULL, SW_SHOWNORMAL ) > 32;
// if ( !bOk )
// {
// wxLogSysError(_(“Cannot open URL ‘%s’”), relativeURL.c_str());
// return false;
// }
// else
return true;
#elif defined(DOS)
wxString command;
command = m_BrowserName;
command << wxT(" file://")
<< m_MapFile << WXEXTHELP_SEPARATOR << relativeURL;
return wxExecute(command) != 0;
#else // UNIX
wxString command;
#ifndef EMX
if(m_BrowserIsNetscape) // try re-loading first
{
wxString lockfile;
wxGetHomeDir(&lockfile);
#ifdef VMS
lockfile << WXEXTHELP_SEPARATOR << wxT(".netscape]lock.");
struct stat statbuf;
if(stat(lockfile.fn_str(), &statbuf) == 0)
#else
lockfile << WXEXTHELP_SEPARATOR << wxT(".netscape/lock");
struct stat statbuf;
if(lstat(lockfile.fn_str(), &statbuf) == 0)
// cannot use wxFileExists, because it’s a link pointing to a
// non-existing location if(wxFileExists(lockfile))
#endif
{
long success;
command << m_BrowserName << wxT(" -remote openURL(")
<< wxT(“file://”) << m_MapFile
<< WXEXTHELP_SEPARATOR << relativeURL << wxT(")");
success = wxExecute(command);
if(success != 0 ) // returns PID on success
return true;
}
}
#endif
command = m_BrowserName;
command << wxT(" file://")
<< m_MapFile << WXEXTHELP_SEPARATOR << relativeURL;
return wxExecute(command) != 0;
#endif
}
*/
Andre Krause wrote:
i know - this is exactly the problem with linux. isnt it a shame?
but maybe someone here on the list can take the burden and find a method
that work for the most common linux distro’s ? and on systems, where no
reliable method is known, open_url could return false if it was not able
to open the url. so the application could present at least the
Yes, while mac and win32 have simple, documented, ways to do so on linux
it’s more tricky:
void
openurl(const char *url)
{
#ifdef WIN32
ShellExecute(GetActiveWindow(),
“open”, url, NULL, NULL, SW_SHOWNORMAL);
#elif defined(APPLE)
char buffer[256];
snprintf(buffer, sizeof(buffer), “open %s”, url);
system(buffer);
#else
char *apps[] = {“x-www-browser”,
“firefox”, // iceweasel has an alias on debian
"opera",
“mozilla”,
“galeon”,
“konqueror”, NULL};
char buffer[256];
int i = 0;
while (apps[i]) {
snprintf(buffer, sizeof(buffer), "which %s >/dev/null", apps[i]);
if (system(buffer) == 0) {
snprintf(buffer, sizeof(buffer), "%s %s", apps[i], url);
system(buffer);
return;
}
i++;
}
#endif
}–
Bye,
Gabry
In Linux case I would first check if there is any of the listed browsers
running and would use that as the browser. If not then fallback to run
the first one present in the list.On Tuesday 09 October 2007, Gabriele Greco wrote:
Andre Krause wrote:
i know - this is exactly the problem with linux. isnt it a shame?
but maybe someone here on the list can take the burden and find a
method that work for the most common linux distro’s ? and on
systems, where no reliable method is known, open_url could return
false if it was not able to open the url. so the application could
present at least theYes, while mac and win32 have simple, documented, ways to do so on
linux it’s more tricky:void
openurl(const char *url)
{
#ifdef WIN32
ShellExecute(GetActiveWindow(),
“open”, url, NULL, NULL, SW_SHOWNORMAL);
#elif defined(APPLE)
char buffer[256];
snprintf(buffer, sizeof(buffer), “open %s”, url);
system(buffer);
#else
char *apps[] = {“x-www-browser”,
“firefox”, // iceweasel has an alias on debian
"opera",
“mozilla”,
“galeon”,
“konqueror”, NULL};char buffer[256]; int i = 0; while (apps[i]) { snprintf(buffer, sizeof(buffer), "which %s >/dev/null",apps[i]); if (system(buffer) == 0) {
snprintf(buffer, sizeof(buffer), “%s %s”, apps[i], url);
system(buffer);
return;
}
i++;
}
#endif}
I think open url is not for SDL. A small add-on library would be a
better place for this.
Andre Krause wrote:
i know - this is exactly the problem with linux. isnt it a shame?
but maybe someone here on the list can take the burden and find a method
that work for the most common linux distro’s ? and on systems, where no
reliable method is known, open_url could return false if it was not able
to open the url. so the application could present at least theYes, while mac and win32 have simple, documented, ways to do so on linux
it’s more tricky:
On GNOME you can use the command gnome-open URL.
To find out, whether you are under GNOME, check for the environment variable
GNOME_DESKTOP_SESSION_ID.
Hope that helps.Am Tuesday, dem 09. Oct 2007 schrieb Gabriele Greco:
–
AKFoerster
One thing I’d like to know about SDL 1.3: Is it going to finally remove
the restriction that SDL functions can only be called from the main
thread? SDL’s strong orientation to an old-fashioned, single-threaded,
event-driven architecture is the reason I’m currently investigating
alternative libraries. It’s just getting more and more painful trying to
reconcile SDL with a heavily multithreaded application.
I could live with restricting all SDL calls to a single thread if I had
to, if only it didn’t have to be the main thread. Is there any prospect
of some relief on the horizon?
– Ross Smith
Hello !
One thing I’d like to know about SDL 1.3: Is it going to finally remove
the restriction that SDL functions can only be called from the main
thread? SDL’s strong orientation to an old-fashioned, single-threaded,
event-driven architecture is the reason I’m currently investigating
alternative libraries. It’s just getting more and more painful trying to
reconcile SDL with a heavily multithreaded application.I could live with restricting all SDL calls to a single thread if I had
to, if only it didn’t have to be the main thread. Is there any prospect
of some relief on the horizon?
The reason for this was always named that most
OSes only support event handling and drawing
from the main thread.
For which OS is this true and for which false ?
CU