This release contains support for JPEG images via libjpeg, several important bugfixes, an implicit data sharing system, and countless additions and improvements across the entire library.
- Support for reading/writing JPEG images
- Improved unit resolution support
- Set custom row callback function
- Implicit data sharing (copy-on-write)
- Several major bugfixes
Even though the JPEG implementation is completely stable and very usable, it’s still missing a few useful features, namely, support for exif metadata, thumbnails, comments and restart markers.
This is probably the last beta release, as the interface is now very well stabilized. The next release will probably be considered stable and remove the beta qualifier.
Special thanks to the Independent JPEG Group for making JPEG support virtually painless.
v0.1.3b – May 4, 2012
- Fixed bug which caused paletted BMP image file headers to write incorrect offset to image data
- Fixed bug in function iFileStream::atEnd() which caused a crash when calling it before a stream was opened or after it was closed
- Fixed bug in class iPNG which caused memory corruption when reading PNG images that did not contain a background chunk
- Added iJPEG class, inherited from iAbstractImage, which handles loading and saving of JPEG images
- Added class iSharedData for implicit data sharing
- Added class iJobTime
- Added iTypeJPEG enumerator to iImageType enumeration
- Added functions iPNG::getCompressLvl() and iPNG::getInterlaceType()
- Added enumeration iUnitType with enumerators iUnit, iCentimeter, iMeter and iInch
- Added enumeration iWrapMode with enumerators iWrapBackground, iWrapClamp and iWrapRepeat
- Added static function isValid() to all image classes; use it to test if an image type is valid
- Added virtual functions getc() and putc() to class iDataStream
- Overload operator= in iBMP, iJPEG, iPNG and iTGA
- Added private data member unitType and public accessor functions setUnitType() and getUnitType()
- Added private data member jobTime and public accessor function getJobTime() and setJobTime()
- Added accessor functions set*Res() and get*Res()
- Added pure virtual function isFormatSupported() and implemented it in all classes inherited from it
- Added pad() function for padding image data
- Added functions setReadFunc() and setWriteFunc() that sets functions to be called whenever a row of image data is read or written
- Added function iAbstractImage::detachData()
- Significantly improved unit resolution support in all image classes (except iTGA, which doesn’t support it)
- Added int alpha parameter to functions iAbstractImage::convertFormat() and iPalette::convertFormat()
- Renamed function iTGA::getVersion() to iTGA::getTargaVersion()
- iAbstractImage save() functions now make sure image format is supported before saving image
- Classes iBMP, iJPEG, iPNG and iTGA can now call a user-provided function whenever a row of image data is read or written
- iImageType enumerators have been assigned different values
- Compression level in class iPNG is now set to 9 by default
- Image classes now check if stream is at end before loading images with user-provided stream
- PNG writer can now save image’s background color
- TGA writer can now read job time from Extension Area
- iTGA structs TGA_HEADER, TGA_FOOTER, TGA_EXTENSION and TGA_DEVTAG are now private
- iBMP structs BITMAPFILEHEADER, BITMAPCOREHEADER, BITMAPINFOHEADER, BITMAPV4HEADER and BITMAPV5HEADER are now private
- Private function determineType() can now recognize extensions in ALL CAPS as well as lowercase
- Load functions now test for image type validity with buffers and streams before reading image; it doesn’t spit out lots of error messages anymore
- Overloaded all load() and save() functions, including functions for streams
- Renamed private members XPxPerMeter and YPxPerMeter to XResolution and YResolution
- Implemented implicit data sharing (copy-on-write)
- Function resize() now preserves original image, returns bool, and can use X and Y offsets
- Removed function iTGA::getTargaType()
- Removed class iRoutines
- Removed iTypePCX enumerator from iImageType enumeration
- Removed function iAbstractImage::deleteData()
- Removed all iTGA::getJob*() and iTGA::setJob*() functions
- Added libjpeg
- Added –format option to imagenconv
This release includes several critical bugfixes and numerous improvements to many areas of the library, including partial support for Windows Bitmap files.
- Partial support for reading/writing Windows Bitmap files
- New command-line front-end
- Read and write paletted PNG images
- Several major bugfixes
It’s a late-coming but important release. I have made significant improvements to all areas of the library and will be stepping out of beta within the next few releases.
If you are currently using the unstable and highly-deficient v0.1b, you must get this upgrade.
- More stabilized and consistent interface
- New polymorphic design for data streams
- Numerous improvements to the way images are read and written
- Completed read/write support for colormap Targa images with 24/32-bit palettes
- Removed accidental libpng dependency in iPNG.h header
- Numerous improvements to PNG image reading/writing
- Class iImage now preserves all attributes common to all image classes
The first release encapsulating the new design of the imagen library is complete.
The library is pretty stable and ready to use. I definitely recommend switching to it if you’re currently using v0.0.1 of the library.
I was thrilled to witness the release of the OpenGL 4.x specification over a year ago. It was really exciting to see how clean the specification was with the removal of so much of the fixed-function processing and other ancient, deprecated features; but a few things still have me worried.
Because of modern OpenGL’s focus on the GPU (with vertex shaders, et al.), it is impossible for weaker PCs to utilize these specifications, since they are simply incapable of the kind of graphics processing required. So what are these weaker computers (and there are more that don’t have an advanced GPU than those that do) supposed to do?
It seems that they must stick with an outdated API with fixed-function processing and an unwanted OpenGL matrix stack. We’re talking OpenGL 1.4. If it were just existing computers that were limited, I wouldn’t have a problem; but many new computers that haven’t even been conceptualized yet will be too weak to use the modern API as well.
I am currently developing a game engine with OpenGL 1.4, and am a bit perplexed about exactly how I should go about rendering my objects.
Normally, you would manipulate the projection and modelview matrices with calls to gluPerspective() or glOrtho(); and glTranslatef(), glRotatef(), and glScalef(), respectively. You could then draw the vertices with glDrawArrays().
What if I want to take exclusive control of each vertex’s position, manipulating it by my own matrices? If my only option is to multiply my matrices on top of OpenGL’s matrix stack with glMultMatrix(), then so be it; that would be a tolerable compromise. But if there is a way to disable OpenGL’s matrix stack completely, that would almost alleviate all of the worries I have.
So what about those of you who wish to make simple 2D games that can run on any PC? These games don’t need intensive graphics processing, but could certainly benefit from modern rendering methodologies. I guess we’ll just have to deal with some of the inconveniences of a decade-old API…for now.
It seems that the transition (or lack thereof) to OpenGL 2.0 and beyond is rather harsh.
Am I looking at this all wrong? Your thoughts would be very much appreciated.
I wish I didn’t have to be so pessimistic, but I just don’t see this problem going away any time soon.
On a brighter note, with the advent of so many amazing new technologies, maybe it will just take some time for things to settle down and find where they really belong. All good things take time.
I recently spent a week building a rudimentary raytracer to strengthen my understanding of some concepts I had been studying.
It’s very small; just the barebones basics: spheres, planes, and point lights; and no shaders.
It was difficult building the initial core and mathematical base, but it always pays off to have a well-structured core, especially when it comes to modifications later on.
It’s certainly not much to look at, and the shadows aren’t even correct; but, hey, it works!
This took about 1 second to render on my Intel Pentium Dual CPU E218 @ 2.00 GHz running Windows, and far less than 1 second on Linux:
I wrote a subsampling algorithm as well, which was very slow and only semi-successful:
I’m speaking from personal experience when I say that the first correct images your raytracer produces are very satisfying.
But, a more probable scenario is that you will have ripped out all of your hair in frustration, because you had been fiddling with your raytracer (which had been spitting out garbage) for over 8 hours, only to realize that the problem was just one line of misstyped code in your sphere-ray intersection algorithm.
If you’ve ever thought about writing your own raytracer, you should definitely give it a try. Physics-based raytracing especially is a lot of fun.
If you want to see how a real raytracer works, check out the source code of LuxRender or Yafaray.
Here’s links to some resources to get you started:
DevMaster.net – Raytracing: Theory & Implementation
Codermind – The Raytracer series
FuzzyPhoton – Raytracing articles
Ray Tracing: Graphics for the Masses
Raytracing at Siggraph
I’m currently restructuring the entire imagen library. The new design is much more object-oriented, embracing inheritance and polymorphism.
I’ve begun with the TGA loader, and have made a lot of changes, implementing stricter adherence to the Truevision TGA File Format Specification. The new class, called iTGA, will also include read/write support for all of the features included in TGA v2.0.
imagen won’t be targeting just image loading for games; more advanced software will be able to make use of it too
Look for a completely backward-incompatible release within the next few weeks.
Evidently, it’s expected of developers with registered projects on SourceForge to have a blog, so here it goes…
I guess I’ll start with a few random facts:
I am NOT an experienced software developer. I got started in this field in late 2010, only a year ago.
I am a lifelong user of Windows, but am now very interested in Linux.
I love free/open-source software, and have used it for most of my work for several years now.
John Carmack and Linus Torvalds are not my personal heroes, although they come close.
Python is my favourite language, but I do most of my work in C++.
My key tech interests are digital imaging and information technology.
I also enjoy mathematical logic and many branches of computer science.
I would like to thank SourceForge.net for their generous project and web hosting. They offer so many great services, some of which would be very difficult and expensive to set up on my own, and they don’t charge a dime for it. Thanks, SourceForge!
This is my first public release of Gel2D.
Gel2D is a free/open-source, cross-platform, object-oriented, 2-dimensional game engine written in C++. It aims to someday be an all-in-one solution for commercial-quality rapid game development.
Go ahead and check it out on sourceforge. Here’s the project page: http://gel2d.sourceforge.net/
After you’ve given it a test drive, please come back here and tell me what you think of it. I need your feedback. Thanks!