[aldacron]

DERELICT 0.2
-------------------

It would seem that some people who use Derelict for the first time are, quite understandably, downloading the only release archive- which is horribly outdated. It would seem that I need to get a new release out the door as soon as possible. To that end, these are my next steps:

1) nix DerelictPY - I started this package because I wanted to use it for a project I had in mind. It has proven to be a huge headache, and since I began a new version of Python (2.4) has been released. So in the name of progress I'm going to remove all of DerelictPY from SVN and put it on the backburner. Somewhere down the road I hope to revisit it, but from a different angle. I would rather rewrite everything from scratch than modify the existing nightmare.

2) finish the Linux ports - I still need to get the AL, GL, and GLU packages ported to Linux. Piece of cake (or should be).

3) add SDLnet - this is the last major SDL package to add, and looks to be painless

4) a handful of sample programs

5) a short tutorial for each package, beyond the basic READMEs.

Once again, no timeframe on this stuff, other than 'as soon as possible'. The sooner the better, of course. The goal here is really to get something downloadable that a new user can unzip and get up and running with. The first 3 steps I shouldn't take long at all, but steps 4 and 5 will likely be a bit more lengthy.

If any of you have sample apps you wouldn't mind submitting, or would like to write a tutorial for one of the packages, please don't hesitate to email me. Sample apps should be sent in source form and should, preferably, demonstrate basic concepts of using Derelict packages. Tutorials should be focused on Derelict, not on the library a package wraps. I'm not looking to teach SDL here, but how to get DerelictSDL up and running. A tutorial with a corresponding sample would be perfect.

If I get no submissions, no biggie, I'll get something knocked up as soon as I can. My email address is the handle you see here AT gmail. BTW, I have 10 gmail invites if anyone wants one. I really like it much better than any webmail service I've previously used.


DERELICT'S FUTURE
-----------------------

What are some other packages you would like to see in Derelict? Please reply to this post with any ideas. I make no promises. I will evaluate anything posted, look at licenses to make sure no conflicts will arise (GPL is out!) and determine if I want to make the effort required to port a particular lib (libPNG, while smaller than Python, is even worse!).

Of course, if I decide not to port a lib, I will accept almost any contributions provided that they a) follow the same structure (both directory and code-wise) as the existing Derelict packages and b) the original library is not GPL or any other sort of license that would force Derelict users to go open source. LGPL is okay as long as the original library is available in DLL/SO form.

Here's the status on some libraries you might be thinking of:

SDL_net - coming real soon for the 0.2 release

GLFW - this will be in the 0.3 release

DirectX - I still want to do this, and I will, but it's not a high priority right now

libPNG - forget it. I really wanted to include this, but there are just so many conditional compilation oprtions that there's no way I can get an accurate representation of the headers in D. Those guys need to be shot for the way they designed that library. If anyone can get a working version in D, that can be configured to match any libPNG DLL, I'll happily include it. Otherwise, this may be a candidate for rewriting altogether in D.

Let me hear what you want!

[JJR]

Aldacron,

I'm nearly finished implementing a GLFW branch for derelict. You can add it if you want when I'm done. I have to finish it up, then test it to see that it works satisfactorily on Win32 and Linux.

Later,

John R.

[JJR]

I've completed the initial version of derelict.glfw for win32. I'll work on the linux version shortly.

There are two versions of the loader:

1) The first one maps the loaded glfw functions to simpler names. For example instead of the real function name "glfwOpenWindow()", I remap to the d-style name openWindow(). The qualified name is derelict.glfw.openWindow(). I think this improves readability. I did it this way because I find the C style prefixing "glfw" to be redundant in D (the module name already contains glfw). Unfortunately, the qualified name is too long now. A solution is to simply remove glfw.d from the derelict directory all together such that importing glfw renders the fully qualified name glfw.openWindow(). It's simple and looks good.

2) In the second method, I've left the actual names in place in the style of Derelict's other modules.

Method #1 has a minor issue: although it works fine and looks pretty, it's still possible to just call "openWindow()" undecorated because all remapped glfw names are pulled into the current namespace when the module is imported (as is normal for D). Without the glfw decorating the functions, it won't look as clear (to people reading the code) which library is being used. So the only benefit for that method is if you decide to make sure you always prepend the module name to the function: glfw.openWindow() as a convention. In this case, I think it's a good idea.

I'm also interested in encapsulating these functions into a struct or class. As an added bonus, the dynamic loading process can be done in a constructor (although structs don't have those yet ). This doesn't fit into the current derelict methodology, so I might just make this a separate personal project, instead.

Meanwhile the basic glfw interface can go into Derelict when Aldacron needs it.

One other issue I ran into with glfw. In order to make the library work, you must download the glfw archive from the author's site. In that archive is the glfw.dll. Unfortunately that particular dll does not contain the glfwSetTime() function for some wierd reason (that's the only function that didn't load so I commented it out). If you need that function, you'll have to compile the glfw source to a dll yourself with Visual C++ 6. You could also use any of several other C/C++ compilers, but as far as I can tell, most other compilers create symbol names with the '_' prefix and "@#" postfix, which means you'll have to plug in all those symbols into the glfw.d loader code to get the functions loaded correctly - it's kind of annoying how the dll's aren't alike (if you know how to eliminate those symbols in the particular compiler... more power to you!).

I'm going to get some glfw code demos converted to D to test the interface. I'll include those in the package when it's done.

I admit that some of these ideas are inconsistant with Derelicts current design, so I won't offer the described changes for inclusion. The original directly mapped names are available for Derelict's use (#2). I can keep mine as an independent project for glfw.

Later,

John R.

[aldacron]

[JJR]

[aldacron]

[JJR]

[aldacron]

[JJR]

Well... it may be trickier then I imagined. I didn't realize you went to all that trouble. I'll be at work all weekend, but I should have a chance to see what needs to be done.

Later,

John R.

[JJR]

[JJR]

The slowdown could be completely in the glfw.dll that's provided, since that's the only one I've been using.

If you get a gcc glfw.dll compiled, maybe I should give that a test.

[JJR]

I ran a couple of tests:

1) Compiled a glfw.dll with mingw-gcc-3.4.2. I then used the dll with the derelict.glfw triangle.d example. Low and behold, it ran just as slow as when using the provided glfw.dll.

2) Compiled a glfw.dll with openwatcom again. This time I found a linker switch that disables the function decoration . The dll is twice as big as that made by gcc, but when I used it with the d triangle.exe, it had full performance (the same speed as the C staticly linked one)! Yay!

So the problem is in the dll. I still don't know why gcc was slow and openwatcom was fast. Maybe it has to do with some optimization settings or compiler switches. Beats me. But I'll use the openwatcom compiled dll for now. Maybe I'll check the performance of a dmc compiled dll too.

- John R.

[JJR]

[aldacron]

[JJR]

Ok I understand what you mean now. I'll continue to look into it.

As for the derelict.glfw, did you receive my email?

Later,

John R.