gmane.comp.lib.sdl

Re: Link error on MacOSX

Gabriele Greco — 2013-05-24T15:39:45

I'm quite sure I've had that problem too when trying to build with CMake on
OSX, so after a few failed attempts to fix the CMakeLists.txt I switched
back to build with autotools, the problem I had was that some of the .m
files do not get complied also if they are correctly added in the
respective directories...  I thought it was some problem with my version of
cmake and gave up since I had not a lot of time at the moment :)

Re: May is SDL release month!

Ryan C. Gordon — 2013-05-23T23:40:03

I would go further and say "don't ever use SDL_INIT_EVERYTHING," but 
that's just me.

Do we know why SDL_INIT_HAPTIC fails in this case? Is it something we 
can reasonably fix (like, not fail, but report zero haptic devices 
instead, or something)?

--ryan.

Re: Android EGL-fu

Scott Percival — 2013-05-23T22:59:52

Sounds like a brilliant idea, and hopefully shouldn't be too much work.

"Video" driver is a bit of a misnomer with SDL, as they also contain the
platform-specific hooks for input and event wrangling. For that reason you
might not want to implement EGL as a whole discrete video driver per se,
but perhaps a subset of common methods that get called by the current stack
of of video drivers.

Right now, the way it works is that the top level SDL_VideoDevice struct
has pointers to the GL context handling methods in the device driver (see
http://hg.libsdl.org/SDL/file/53df899db00b/src/video/SDL_sysvideo.h#l220 ).
In the X11 driver for instance, that means _this->GL_GetProcAddress can be
set to point at X11_GL_GetProcAddress (defined in
/src/video/x11/SDL_x11opengl.c) or X11_GLES_GetProcAddress (defined in
/src/video/x11/SDL_x11opengles.c). There's also a generic struct pointer of
type SDL_PrivateGLESData in there, which is later defined in the video
driver (e.g. /src/vide/x11/SDL_x11opengles.h) to be a container f

Re: Android EGL-fu

José Luis Pereira — 2013-05-23T17:01:27

I will start implementing in a separate EGL driver (folder). I dont have
complete knowledge on how SDL implements the video drivers, mainly how the
macro checks are working. Any recommendations?

Also, again about Android, i would say that a OpenSLES implementation could
also be very favourable for audio, however i dont have
an immediate interest on it ATM.

Best

------
José Pereira
Personal blog <http://www.onaips.com>



On Thu, May 23, 2013 at 8:43 AM, Sam Lantinga <slouken< at >libsdl.org> wrote:

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

SDL_image and texture access

perfectASD — 2013-05-22T19:24:00

Hi there! I'd like to know if there's a way to open an image with the SDL_image functions and then set the texture access mode to SDL_TEXTUREACCESS_STREAMING.
Thank you!




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

Re: Android EGL-fu

Sam Lantinga — 2013-05-23T15:43:43

That would be great.  I'd love to unify the EGL code in SDL.

Cheers!


On Thu, May 23, 2013 at 7:02 AM, Scott Smith <pickle136< at >sbcglobal.net>wrote:

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

Re: May is SDL release month!

Sam Lantinga — 2013-05-23T15:42:16

SDL_INIT_EVERYTHING should really be only used if you actually need all of
the subsystems provided by SDL.


On Thu, May 23, 2013 at 1:47 AM, neoaggelos <neoaggelos< at >gmail.com> wrote:

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

Re: Android EGL-fu

Scott Smith — 2013-05-23T14:02:56

________________________________
From: Ryan C. Gordon <icculus< at >icculus.org>
To: SDL Development List <sdl< at >lists.libsdl.org>
Sent: Wed, May 22, 2013 7:20:50 PM
Subject: Re: [SDL] Android EGL-fu

This is a stupid question, but: is the EGL on Android any different from the EGL 
for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I'd sorta like to move all of this to one 
"egl" video target with a little bit of platform-specific glue code for the 
different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is better than 
more.

--ryan.

Ryan,

I think your assertion is correct. I found the EGL parts could be the same and 
there are 2 platform specific parts. One to get the platform display and the 
other for the platform window surface.

I have a small little project that basically shows this: 
http://sourceforge.net/projects/eglport/
It support RAW framebuffer, SDL 1.2 (X) s

Re: May is SDL release month!

neoaggelos — 2013-05-23T08:47:47

I know it's far too late on making any API changes, buT what is the case about SDL_Init(SDL_INIT_EVERYTHING) failing because of SDL_INIT_HAPTIC??

Or SDL_INIT_EVERYTHING should be not used anymore?

------------------------
C is the God's Programming Language




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

Re: May is SDL release month!

neoaggelos — 2013-05-23T08:47:35

I know it's far too late on making any API changes, buT what is the case about SDL_Init(SDL_INIT_EVERYTHING) failing because of SDL_INIT_HAPTIC??

Or SDL_INIT_EVERYTHING should be not used anymore?

------------------------
C is the God's Programming Language




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

ANN: New library released based on SDL 2.0

Anthony Walter — 2013-05-23T07:25:27

I've been working on this project for more than a month and against my
better judgement I'm posting a link. I thought maybe this long holiday
weekend some people somewhere might look at it and give me some feedback
(watch the video):

http://www.baregame.org/

Hint: It's a class library written around SDL 2.0 and optionally includes a
compiler+IDE as well as recent binaries of SDL 2.0 for 32/64 bit Windows an
Linux.

If you look at the site, please bear in mind i haven't had time to write up
everything yet. Let me know what you think.
_______________________________________________
SDL mailing list
SDL< at >lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Re: Android EGL-fu

Gabriel Jacobo — 2013-05-23T00:14:57

2013/5/22 José Luis Pereira <onaips< at >gmail.com>


Sounds great, post it in http://bugzilla.libsdl.org/

Re: Android EGL-fu

José Luis Pereira — 2013-05-22T23:28:55

No difference at all, indeed a good point, we could just implement a
generic EGL glue that shall work with a lot more devices. There is a EGL
counterpart for pretty much every callback SDL supports. Only platform
dependent code shall be to create the EGLSurface (eglCreateWindowSurface)
which receives ANativeWindow as argument.



------
José Pereira
Personal blog <http://www.onaips.com>



On Wed, May 22, 2013 at 4:20 PM, Ryan C. Gordon <icculus< at >icculus.org> wrote:

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

Re: Android EGL-fu

Ryan C. Gordon — 2013-05-22T23:20:46


This is a stupid question, but: is the EGL on Android any different from 
the EGL for Pandora, or the Raspberry Pi, or Wayland or Mir (etc)?

(Beyond a few typedefs for display handles, etc.)

If this is basically all the same, I'd sorta like to move all of this to 
one "egl" video target with a little bit of platform-specific glue code 
for the different platform variations.

Which is to say, yes, in any case, it seems to me that less JNI is 
better than more.

--ryan.

Link error on MacOSX

Mako_energy — 2013-05-22T22:33:15

I am currently trying to do all the necessary touchups to my engine so I can get a working MacOSX port up and running.  I have SDL being built through CMake which is integrated into the CMake configuration of my engine.  SDL compiles just fine as a dependency, however when it attempts to link it errors in "SDL_Log.c" saying it can't find the symbol "_SDL_NSLog".  I have looked through the code and I found the method it's talking about in "SDL_cocoavideo.m".  As far as I can tell the project seems to be configured correctly for that files inclusion in the project.

What could be going wrong?




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

Android EGL-fu

José Luis Pereira — 2013-05-22T21:45:47

Hello guys,

Is there any particular reason to use all EGL-related calls with JNI? I've
dug a little bit on the AOSP code, and realized that all java egl related
classes are merely a JNI wrapper to the proper EGL C library.
This means that when SDL is p.e. flipping buffers, it will go from C to
Java to C again.

So, I moved all EGL-related SDLActivity methods to C-code only
(SDL_androidgl.c), as AFAIK all supported versions shall support the egl.h
on NDK.

Minimum API is 10 right? (from what i could see on the android-project
AndroidManifest.xml)

P.E, Android_GL_SwapWindow can be simply implemented by:
void
Android_GL_SwapWindow(_THIS, SDL_Window * window)
{
   if (eglSwapBuffers(display, surface) == EGL_FALSE) {
        SDL_SetError("Error on eglSwapBuffers");
        return;
    }
}

SDLActivity methods:
initEGL - createEGLContext - createEGLSurface - flipEGL

I did not benchmark it but i'm pretty sure it is more efficient as we
remove the JNI context switching overhead.
The only JNI call we will need is

problem about oss audio driver

郭永磊 — 2013-05-22T07:00:41

#include <stdlib.h>
#include <stdio.h>
#include <stdbool.h>


#include "SDL.h"
#include "SDL_mixer.h"


int main(int argc, char **argv)
{
    //parse cmd para
    if(argc != 2){
        fprintf(stderr, "%s filename.\n", argv[0]);
        exit(-1);
    }


    //init SDL
    if(SDL_Init(SDL_INIT_AUDIO) == -1){
        fprintf(stderr, "sdl init:%s\n", Mix_GetError());
        exit(-1);
    }
    atexit(SDL_Quit);


    //check audio driver name
    char buffer[32];
    fprintf(stderr, "audio driver:%s\n", SDL_AudioDriverName(buffer, 32));


    //init SDL_mixer
    if(Mix_OpenAudio(44100, AUDIO_S16LSB, 1,  4096) == -1){
        fprintf(stderr, "open audio error:%s\n", Mix_GetError());
        exit(-1);
    }


    // load music file
    Mix_Music *music;
    music=Mix_LoadMUS(argv[1]);
    if(!music){
        printf("Mix_LoadMUS: %s\n", Mix_GetError());
        return 0;
    }


    // play music, 2+1 times.
    if(Mix_PlayMusic(music, 0)==-1){
        printf("Mix_PlayMusic: %s\n", Mix_GetError());
    }

Re: Google Summer of Code applicant

Jared Maddox — 2013-05-22T06:25:55

<snip>


I wouldn't want to push what I'm going to describe as a GSOC project,
but it would handle our needs:
1) generate build files at meta-build-time, with the output being a
bare-bones form of make
2) use the provided makefile(s) to:
2aI) build a search tool,
2aII) use the search tool to obtain paths to required components, and
2aIII) copy those build-time paths to an additional makefile,
2b) then run that produced makefile from the original makefile,
2c) then continue with the rest of the original makefile

We'd actually be looking at a fixed structure. A "native" project file
for each platform to actually run the makefile, a fixed-form search
app that incorporates at least one code file constructed by the
meta-build system, and the actual makefile & meta-build files. If we
wanted to, then the search app could even use a severely striped-down
version of SDL2.

The job of the meta-build system would, in this context, largely be
the same as the build system, just at a slightly higher level: the
meta-buil

Re: SDL2 iOS Callbacks + Ray Tracer

Sam Lantinga — 2013-05-22T05:52:18

This is the final version of the iOS code (for now)
We're letting the OS handle the view transformation so it should just work
behind the scenes for you.

If you create a resizable window, then SDL will allow the user to rotate
the application to whichever orientation they like.  If you create a
non-resizable window, then SDL will lock the orientation to the aspect
ratio you've picked.

Cheers!


On Tue, May 21, 2013 at 9:31 PM, Brian Barnes <ggadwa< at >charter.net> wrote:

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

Re: SDL2 iOS Callbacks + Ray Tracer

Brian Barnes — 2013-05-22T04:31:14


Sorry, I always forget that step.  I've added 2 bugs:

1860 - Relate mouse movement on OS X doesn't hide cursor
1861 - Relate mouse movement on windows jumps the cursor to the center on the first mouse click (1836 is a similar report for OS X, but I don't see the bug there, it's possible the way I'm handling some additional things in OS X mitigates that for me.)

Can somebody quickly explain whatever change happened that automatically handles iOS landscape rotation?  Is it during the texture transfer?  I'm wondering what parts of my code I need to deal with, and if this is the final version of how that code will function for SDL 2.x.

[>] Brian

Re: syntax error before NSColor [PATCH]

Ryan C. Gordon — 2013-05-22T03:02:58


This is now hg changeset b1ca5be78064, thanks!

--ryan.