The library has been stabilized in terms of features, so this weekend will have many API changes to keep a consistent feeling. I decided to do this before the 2.0 release, since after that it will be too late to make such changes.
-- Aggelos Kolaitis
Friday, September 27, 2013
Thursday, September 26, 2013
The focus is now on the docs
For the next few days, I will restrict the development of the library to bug fixes and small API changes only, with very few additions. The primary goal right now is to start writing a rock-solid wiki, as well as update the documentation in the header files and the website.
Anyway, I haven't done much in the code over the last few days, so I guess we are also close to a release at this point. But first, I will try to update the build system to allow building SDLU as a DLL under Windows systems.
-- Aggelos Kolaitis
Sunday, September 22, 2013
New website is up!
All right, after tons of work this weekend, I finally finished the new website. It is now live at http://sdlu.bitbucket.org.
I consider the new website a vast improvement over the previous one, with a much better navigation menubar and -finally- an acceptable from the human race look.
-- Aggelos Kolaitis
I consider the new website a vast improvement over the previous one, with a much better navigation menubar and -finally- an acceptable from the human race look.
-- Aggelos Kolaitis
Development State [22th September 2013]
Last week was a week of many changes. Some things were removed, others were changed, and many new things were added, along with a bug fix for Android.
New Additions
New Additions
- The code now should build for iOS and Mac OS X.
- New button flags SDLU_BUTTON_ROUND and SDLU_BUTTON_THEMED
- New premake option --force=LIBS [Read section Forcing Depencies in INSTALL]
- The SDLU_ALIGN_* macros are now exclusive to the Text Rendering API.
- Custom fonts for the Text Rendering API (see SDLU_SetTruetypeFont()) are now passed as ready TTF_Font* structures. This allows further control over the output as well as greater rendering speeds, since we don't have to create the font every time.
- Fixed common test code crashing on Android
Expect a snapshot soon...
-- Aggelos Kolaits
Monday, September 16, 2013
Testers for Mac OS X wanted!
Well, currently the library has reached a stable point is probably ready for a beta. There are some things that have to be done before that, though...
Besides adding some small APIs, I want to make sure the library actually works as expected under Mac OS X [and if I have the time possibly add official support for iOS]. This is as hard as it can get, because I have no access to a Mac machine.
For that reason, fellow OS X developers: Please test the library [build and run all the tests too to see if anything has to be fixed]. I don't want to make a release of something that has not been tested for Mac OS X. SDL2 is a cross-platfrom library, and so should SDLU be. But that's impossible without your help :)
-- Aggelos Kolaitis
Besides adding some small APIs, I want to make sure the library actually works as expected under Mac OS X [and if I have the time possibly add official support for iOS]. This is as hard as it can get, because I have no access to a Mac machine.
For that reason, fellow OS X developers: Please test the library [build and run all the tests too to see if anything has to be fixed]. I don't want to make a release of something that has not been tested for Mac OS X. SDL2 is a cross-platfrom library, and so should SDLU be. But that's impossible without your help :)
-- Aggelos Kolaitis
Sunday, September 15, 2013
Source code snapshot [15/09/13]
Now that I eliminated some bugs in the source code, the library is considered stable enough for use. Also, it's quite probable that there won't be any more breaking API changes before the 2.0 release, but there are still some features that I would like to add.
If you have a copy of the git repository, the snapshot is tagged with the name
snapshot-150913. (150913 stands for 15/9/13, I just don't like having slashes '/' in the tag name).
As always please test the library, run the test programs and report issues at the issue tracker.
-- Aggelos Kolaitis
Why SDLU v1.0 was never released
A while ago [Mid-summer of 2013], after roughly four months of development, version 1.0 was almost ready for release. I had even posted about that in the SDL2 forums. The library passed through three release candidate releases, yet it was never actually released. Furthermore, even the tags for these versions are not there anymore, leaving everyone using the library dissapointed [all four of them :p].
So what happened???
Well, after three and a half months of development, I wanted to make a first release (v0.9) of the library, which would be done alongside the release of SDL2. The release of SDL2 was postponed, with many bug fixes every day [I tracked the development state before the stable SDL2 release closely]. For that reason, I decided to keep the release of SDLU as well.
Time went along without an SDL2 release, so I kept fixing bugs and adding useful features in the library, as well premature support for Visual Studio and Android [at that time I used the library solely on my development system, which was Linux]. Many things were changed, so I decided to call off v0.9 and go on with v1.0.
After a while, I made the very first RC available. The response was quite depressing, as the announcement did not get even one comment. Anyway, I kept fixing bugs while releasing RC 2 and 3.
In the meantime, I had a local dev branch where I put new features (preparing the library for a stable release I could not add them to the main development line). I was aiming to keep that branch local until all tests were deployed, so I could then merge it into master for the next release.
However, one day or two before the release, I was commiting some stuff at my local dev branch [which had gone over 30 commits away from master], when that exact split-second my Windows machine decided to reboot by itself. That led to a complete disaster, because git had written inside the repository a bad tree. I couldn't recover the repository state, AND I had kept no local nor remote back-up.
Thankfully, I didn't lose any work [all changes were there, since I was on the dev branch when the corruption happened]. For that reason, and due to the little response I got while in RC status, I decided to once again call off the release. I began the git repository from scratch, losing all tags and branches. Furthermore, I noticed quite a few bugs in the code that should not be in a stable release.
So, I left the messy and painful version 1.0 go away, and went head on to prepare an as good as possible 2.0 release. The current code has had many API improvements, additions and bug fixes since that time, and after some things are added, I will hopefully go on to finally release it!
-- Aggelos Kolaitis
So what happened???
Well, after three and a half months of development, I wanted to make a first release (v0.9) of the library, which would be done alongside the release of SDL2. The release of SDL2 was postponed, with many bug fixes every day [I tracked the development state before the stable SDL2 release closely]. For that reason, I decided to keep the release of SDLU as well.
Time went along without an SDL2 release, so I kept fixing bugs and adding useful features in the library, as well premature support for Visual Studio and Android [at that time I used the library solely on my development system, which was Linux]. Many things were changed, so I decided to call off v0.9 and go on with v1.0.
After a while, I made the very first RC available. The response was quite depressing, as the announcement did not get even one comment. Anyway, I kept fixing bugs while releasing RC 2 and 3.
In the meantime, I had a local dev branch where I put new features (preparing the library for a stable release I could not add them to the main development line). I was aiming to keep that branch local until all tests were deployed, so I could then merge it into master for the next release.
However, one day or two before the release, I was commiting some stuff at my local dev branch [which had gone over 30 commits away from master], when that exact split-second my Windows machine decided to reboot by itself. That led to a complete disaster, because git had written inside the repository a bad tree. I couldn't recover the repository state, AND I had kept no local nor remote back-up.
Thankfully, I didn't lose any work [all changes were there, since I was on the dev branch when the corruption happened]. For that reason, and due to the little response I got while in RC status, I decided to once again call off the release. I began the git repository from scratch, losing all tags and branches. Furthermore, I noticed quite a few bugs in the code that should not be in a stable release.
So, I left the messy and painful version 1.0 go away, and went head on to prepare an as good as possible 2.0 release. The current code has had many API improvements, additions and bug fixes since that time, and after some things are added, I will hopefully go on to finally release it!
-- Aggelos Kolaitis
Development state [15th September 2013]
I just managed to fix a long-running bug [been there for about two weeks :p], that would mess up the Text Rendering API, by changing the output position of the text at will. Turns out I just used int instead of float to store the scale factors. Anyway, now that I've also finished reworking the Android port and the new Button API, I guess the code has come to a mostly stable point.
Expect a source code snapshot soon!
Website [under development]: http://sdlu.bitbucket.org/
Repository: http://bitbucket.org/sdlu/sdlu
-- Aggelos Kolaitis
Expect a source code snapshot soon!
Website [under development]: http://sdlu.bitbucket.org/
Repository: http://bitbucket.org/sdlu/sdlu
-- Aggelos Kolaitis
Welcome!
Welcome to the blog of the SDL Utility Library. I started this blog so that I will be able to easily publish news about the development of the library, while also posting articles about different issues I've encountered, as well as how I managed to fix them. My hope is that someday, someone that has a similar problem will be able to find a suitable solution/answer without going through all the fuss I went through (yeah... there were things that I needed, and the information was scattered all around the web)
The SDL Utility Library, is exactly what its name suggests: an utility library for SDL2, the Simple Direct-Media Layer. It provides a set of APIs that make developing SDL2 applications faster and easier. Some of its core features are:
- A fully-featured Button API [with ability for callbacks and completely customizable appearence], blending seamlessly with the SDL2 event queue.
- A set of functions to cap the framerate of your application.
- A 2D Sprite API, built on top of the SDL2 Render API.
- A powerful Text Rendering API.
- cxx, An optional C++ interface of SDL2 [SDL_Window, SDL_Renderer and SDL_Texture]
The SDL Utility Library (SDLU for short) is written in plain C (apart from the cxx interface, of course), and is licensed under the zlib license. zlib, which is also used by SDL2, is a very liberal license which permits almost anything. The library works with Windows, Linux, Mac OS X and Android [Mac OS X and iOS support mostly exists in the source code, but I have no access to a Mac machine to test it -- patches welcome].
-- Aggelos Kolaitis
Subscribe to:
Posts (Atom)