Status of SDLAda

Status of SDLAda

[Michael B.]

There is an unfinished binding to the SDL2 library called SDLAda 
(https://github.com/Lucretia/sdlada).
Does anyone know if development will be continued in the future?

Michael

Re: Status of SDLAda

[Luke A. Guest]

Michael B. <michaelb@example.com> wrote:
> 
> There is an unfinished binding to the SDL2 library called SDLAda 
> (https://github.com/Lucretia/sdlada).
> Does anyone know if development will be continued in the future?
> 
> Michael
> 

Yes I will. Just been in Linux driver land messing with Radv and Vulkan for
Gentoo.

Re: Status of SDLAda

[Luke A. Guest]

Luke A. Guest <laguest@archeia.com> wrote:
> Michael B. <michaelb@example.com> wrote:
>> 
>> There is an unfinished binding to the SDL2 library called SDLAda 
>> (https://github.com/Lucretia/sdlada).
>> Does anyone know if development will be continued in the future?
>> 
>> Michael
>> 
> 
> Yes I will. Just been in Linux driver land messing with Radv and Vulkan for
> Gentoo.
> 
> 

The next thing I intend to work on is the event system because I don't like
what I have. 

Also I need to add more texture iterators and then images have to have
similar.

Re: Status of SDLAda

[Michael B.]

On 09/12/16 03:12, Luke A. Guest wrote:
>> Yes I will. Just been in Linux driver land messing with Radv and Vulkan for
>> Gentoo.

I'm glad to hear that :-)

> The next thing I intend to work on is the event system because I don't like
> what I have.

In my tests it worked pretty well. What's wrong with it?

> Also I need to add more texture iterators and then images have to have
> similar.

I wanted to use this binding to do some 2D gaming experiments. Therefore 
I need to create surfaces/textures from image files, but this part seems 
not to be finished yet.
Would you accept contributions to your binding? I was thinking of 
writing something for SDL_surface.h and/or SDL_image.h which implies a 
binding for SDL_rwops.h.

Michael

Re: Status of SDLAda

[Aurele]

> There is an unfinished binding to the SDL2 library called SDLAda 

This looks like a "thick" binding to the SDL library:

https://www.libsdl.org/

Would having a "thin" binding to the SDL library not have been a better approach?  And why are the API names all different (what happened to SDL_ from the name).  Anyway, nice code.  Does SDLAda offer more than whats already (and used) in the library? 

Re: Status of SDLAda

[Luke A. Guest]

Michael B. <michaelb@example.com> wrote:
> On 09/12/16 03:12, Luke A. Guest wrote:
>>> Yes I will. Just been in Linux driver land messing with Radv and Vulkan for
>>> Gentoo.
> 
> I'm glad to hear that :-)
> 
>> The next thing I intend to work on is the event system because I don't like
>> what I have.
> 
> In my tests it worked pretty well. What's wrong with it?

It's a bit too thin and chucks up warnings when converting between
different events. A thick binding would allow use of the type system. I
just need to create a test branch as I'm not sure if the performance
implications.

>> Also I need to add more texture iterators and then images have to have
>> similar.
> 
> I wanted to use this binding to do some 2D gaming experiments. Therefore 
> I need to create surfaces/textures from image files, but this part seems 
> not to be finished yet.
> Would you accept contributions to your binding? I was thinking of 
> writing something for SDL_surface.h and/or SDL_image.h which implies a 
> binding for SDL_rwops.h.

Yeah I haven't got around to that yet. I've been meaning on looking into
copyright issues as I don't want this biting me at a later date. I'm happy
to accept contributions as long as they stick to the same kind of
interface, thin where need be thick when required, stick to the Ada style
and agrees to copyright assignment which can be done in a hit pull /patch.

Re: Status of SDLAda

[Luke A. Guest]

Aurele <aurele.vitali@gmail.com> wrote:
>> There is an unfinished binding to the SDL2 library called SDLAda 
> 
> This looks like a "thick" binding to the SDL library:
> 
> https://www.libsdl.org/
> 
> Would having a "thin" binding to the SDL library not have been a better approach?  

No. If you just want to write C in Ada use a thin binding.

And why are the API names all different (what happened to SDL_ from the
name).  

Why the hell would you use C's naming convention in a language that
supports overloading, the reason why C libs add a namespace in function
names is because C can't do overloading.

The name's aren't different! The names may be reorganised based on package,
I.e. SDL.Video.Initialise.

Anyway, nice code.  Does SDLAda offer more than whats already (and used) in
the library? 
> 

Yes, array slices to textures for one, allows sub image copying using Ada
semantics. Also texture iterators, see the moose example.

Re: Status of SDLAda

[Aurele]

> No. If you just want to write C in Ada use a thin binding.

Its not writing C in Ada when you "import" an entry from a C or stdcall library.  The SDLAda body pakages makes such imports all over, hence why I said SDLAda is a "thick" binding with new or extras features.  Nothing wrong with that and nothing wrong keeping SDL_ (if SDLAda it were a thin binding).  Anyway, good luck, and its always good to see new Ada projects !

Re: Status of SDLAda

[Luke A. Guest]

Aurele <aurele.vitali@gmail.com> wrote:
>> No. If you just want to write C in Ada use a thin binding.
> 
> Its not writing C in Ada when you "import" 

Sorry but I have to take issue with this. But if you only have a crude thin
binding to a C lib you are essentially programming C in Ada.

an entry from a C or stdcall library.  The SDLAda body pakages makes such
imports all over, hence why I said SDLAda is a "thick" 

Well of course the do, have to import them somehow, I just generally wrap
anything that should be wrapped and bind others in such a way that it won't
feel like C.

binding with new or extras features.  Nothing 
wrong with that and nothing wrong keeping SDL_ (if SDLAda it were a thin
binding).  

Again having SDL.SDL_ is stupid, yes I know you can "use SDL;"

Anyway, good luck, and its always good to see new Ada projects !
> 

Ta, hope you use it to produce something cool and prove that Ada is the
best choice for writing games in. Also to help get the compiler optimised
better in the newer 2012 features, iterators in particular as I think they
may still not be generating the best code, yet.

Re: Status of SDLAda

[Michael B.]

On 09/13/16 00:01, Luke A. Guest wrote:
> Yeah I haven't got around to that yet. I've been meaning on looking into
> copyright issues as I don't want this biting me at a later date. I'm happy
> to accept contributions as long as they stick to the same kind of
> interface, thin where need be thick when required, stick to the Ada style

Fine :-)
I have written an Ada package (two files) for RWOps. What should I do 
with them? Do you prefer a fork/pull-request on Github, an email or 
something else?

> and agrees to copyright assignment which can be done in a hit pull /patch.

I've never thought about this legal stuff, but I'm ok with that. Just 
tell me what I need to do.

Michael

Re: Status of SDLAda

[Luke A. Guest]

Michael B. <michaelb@example.com> wrote:
> On 09/13/16 00:01, Luke A. Guest wrote:

>> interface, thin where need be thick when required, stick to the Ada style
> 
> Fine :-)

Cool.

> I have written an Ada package (two files) for RWOps. What should I do 
> with them? Do you prefer a fork/pull-request on Github, an email or 
> something else?

Git format-patch, can you declare in the commit that you are assigning it
to me? You can email it through git or GitHub.

This will make binding sdl image lib easier as well. 

I would like to have an Ada stream interface but I don't think that will be
possible.

>> and agrees to copyright assignment which can be done in a hit pull /patch.
> 
> I've never thought about this legal stuff, but I'm ok with that. Just 
> tell me what I need to do.

Yeah I've been thinking more about this recently as I want to keep this
binding matching the libsdl license and if they change it, it'll be s pain.
I doubt they will as libsdl2 used to be pure GPL.

You see, AdaCore generated a thin binding and then slapped a GPL license,
no exception, which was stupid and really insulting.

I want to make sure this stays as free as possible and be the best binding
there is.

Luke