Re: A couple of new libraries

[BLM]

aboout openGL aldacron has written derelict to use it and maybe 
it will

do a lib as GLFW does


I'm actually using Derelict and its OpenGL/SDL bindings. I'm just 
implementing a layer on top of those.

Re: A couple of new libraries

[bioinfornatics]

Le jeudi 21 juin 2012 à 17:46 +0200, BLM a écrit :
> >
> > What's the advantage over the existing libraries?
> > Why have you choosen to build a library from scratch, instead 
> > of improving an existing one?
> >
> > see:
> > http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries
> 
> The main issue I've had with other libraries is that I never seem 
> to be able to build them right. I also wanted to try out my 
> dynamic resizing algorithm and see how simple and flexible I 
> could make my code. This is actually my first major attempt at 
> GUI programming, so it's also largely a learning project. I'll 
> consider helping an existing library, though.
> 
> Speaking of help, if anyone has some OpenGL 3+ experience, the 
> game engine project has a bug I can't sort out.  I'll write up 
> some info if anyone feels like going on a bug hunt.

aboout openGL aldacron has written derelict to use it and maybe it will
do a lib as GLFW does

Re: A couple of new libraries

[Jacob Carlborg]

On 2012-06-21 12:00, Rory McGuire wrote:


What sort of help?


What's mostly needs to be done with DWT is:

* Updating to later versions of SWT
* Finish the Mac OS X port
* Porting the browser package
* Porting to Linux 64bit
* Possibly port to other platforms

--
/Jacob Carlborg

Re: JPG and PNG decoder

[Felix Hufnagel]

it's not that hard to write a baseline jpeg encoder. it's not harder than  
decoding.

there are many tutorials and examples online.




Am 17.06.2012, 09:55 Uhr, schrieb cal :


On Sunday, 17 June 2012 at 07:07:35 UTC, Philippe Sigaud wrote:

Still, I'm interested in writing a JPEG/PNG to disk from a
ubyte[3][][], or whatever.


Do you mean that you want to encode a ubyte array to disk as JPEG/PNG?  
Encoding a JPEG would be a bit of work I think, the format's kind of a  
monster. PNG should be easier, depending on how good you want the  
compression to be. If you don't care too much about compression level,  
you simply zlib compress the data, write it out by image row/scanline,  
include appropriate header and chunk info, and you're done. I'll give a  
simple encoder a go if you think you could use it.


Cheers,
cal




--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/

Re: JPG and PNG decoder

[cal]

On Thursday, 21 June 2012 at 17:58:47 UTC, Stewart Gordon wrote:

On 18/06/2012 00:49, cal wrote:


ubyte[] data = some data;
Image img = new Img!(Px.R8G8B8)(width, height, data);


Image?  Img?


img.write("mypng.png");


Image is the interface, Img the templated class that does all the 
work. It is parameterized by the pixel format. It may not be the 
best strategy (or naming scheme!) but enumerating the formats and 
templating based on that limited the number of cases I had to 
think about.


Does it always take in a ubyte[], or does that depend on the 
bit depth?


It currently just takes a ubyte, and doesn't do any rearranging 
of the array, so it will only work for 8-bit depths. If you had 
4-bit greyscale tightly packed into your ubyte (two pixels per 
byte) then it would not be correctly interpreted, nor would 16 
bit. The reason was I didn't want to have the Image class 'own' 
the passed-in array. If it did own it, then it would be free to 
unpack the smaller bit depths the way it does when decoding. I 
will fix this when I have time to think about it a bit more.

Re: JPG and PNG decoder

[Stewart Gordon]

On 18/06/2012 00:49, cal wrote:


ubyte[] data = some data;
Image img = new Img!(Px.R8G8B8)(width, height, data);


Image?  Img?


img.write("mypng.png");

It uses adaptive filtering, and should work with the pixel formats supported by 
the image
class (except for the 16 bit ones I've just realised). I've only tested it on 
images that
I have previously loaded in however.


Does it always take in a ubyte[], or does that depend on the bit depth?


Stewart, I used your makepng.d as a template for this, can I add you to the 
author list?



By all means.

I look forward to seeing what you've come up with.

Stewart.

Re: A couple of new libraries

[BLM]

What's the advantage over the existing libraries?
Why have you choosen to build a library from scratch, instead 
of improving an existing one?


see:
http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries


The main issue I've had with other libraries is that I never seem 
to be able to build them right. I also wanted to try out my 
dynamic resizing algorithm and see how simple and flexible I 
could make my code. This is actually my first major attempt at 
GUI programming, so it's also largely a learning project. I'll 
consider helping an existing library, though.


Speaking of help, if anyone has some OpenGL 3+ experience, the 
game engine project has a bug I can't sort out.  I'll write up 
some info if anyone feels like going on a bug hunt.

Re: A couple of new libraries

[Rory McGuire]

What sort of help?

On Thu, Jun 21, 2012 at 11:39 AM, Jacob Carlborg  wrote:

> On 2012-06-21 10:06, Matthias Pleh wrote:
>
>  What's the advantage over the existing libraries?
>> Why have you choosen to build a library from scratch, instead of
>> improving an existing one?
>>
>> see:
>> http://prowiki.org/wiki4d/**wiki.cgi?GuiLibraries
>>
>>
> Yeah, good question. I could really use some help with DWT.
>
> --
> /Jacob Carlborg
>

Re: A couple of new libraries

[Jacob Carlborg]

On 2012-06-21 10:06, Matthias Pleh wrote:


What's the advantage over the existing libraries?
Why have you choosen to build a library from scratch, instead of
improving an existing one?

see:
http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries



Yeah, good question. I could really use some help with DWT.

--
/Jacob Carlborg

Re: A couple of new libraries

[Matthias Pleh]

Am 20.06.2012 23:20, schrieb BLM768:




Can you tell us more about the GUI library, like:

* Which platforms and GUI systems it's available on
* Does it use native drawing operations
* Or is it more directed to gaming


It's currently Windows-only, but the plan is to make it cross-platform.
It's designed for native widgets. So far, it just does windows, buttons,
and text fields, but adding other controls shouldn't be too difficult.
The goal is to create as simple and intuitive of an interface as
possible, even if it means sacrificing a few advanced features that are
rarely used.




What's the advantage over the existing libraries?
Why have you choosen to build a library from scratch, instead of 
improving an existing one?


see:
http://prowiki.org/wiki4d/wiki.cgi?GuiLibraries