Copperbox revision 443.
I've deleted the ZBmp1 directory - this had a prototype of ZBitmap that handled mono bitmaps. As ZBitmap does mono bitmaps, ZBmp1 is redundant.
Also, I've made minor changes to Example1 in the Haskell FreeType binding.
Saturday, January 31, 2009
Friday, January 30, 2009
ZBitmap
Copperbox revision 442.
I've tidied up the Convert module and added support for 4- and 8-bit bmp bitmaps.
I've tidied up the Convert module and added support for 4- and 8-bit bmp bitmaps.
ZBitmap
Copperbox revision 441.
Tidying up the Convert module, though it still needs work to implement other resolutions than mono and 24bit.
Tidying up the Convert module, though it still needs work to implement other resolutions than mono and 24bit.
ZBitmap
Copperbox revision 440.
Some tidying up. The Convert module still needs more tidying, though.
Some tidying up. The Convert module still needs more tidying, though.
Thursday, January 29, 2009
ZBitmap
Copperbox revision 439.
Fixed the striping bug when going from a *.bmp bitmap to the internal bitmap and back to the *.bmp bitmap.
Now that I've got ZBitmap working I'm starting to see how it should work anyway (I'd never really programmed bitmap graphics before, so I was somewhat in the dark to start with). The next round of work will be to start tidying up some of the code horrors.
Fixed the striping bug when going from a *.bmp bitmap to the internal bitmap and back to the *.bmp bitmap.
Now that I've got ZBitmap working I'm starting to see how it should work anyway (I'd never really programmed bitmap graphics before, so I was somewhat in the dark to start with). The next round of work will be to start tidying up some of the code horrors.
ZBitmap
Copperbox revision 438.
Work on rendering the internal bitmap representation back to a DIB bmp bitmap.
This has some problems - mainly because I don't seem to be translating the initial input bmp bitmap properly in the first place.
Work on rendering the internal bitmap representation back to a DIB bmp bitmap.
This has some problems - mainly because I don't seem to be translating the initial input bmp bitmap properly in the first place.
ZBitmap
Copperbox revision 437.
Initial work on converting bitmap colour depths. The internal bitmap format in ZBitmap stores a pixel as a 32 bit value - the new code can translate mono Bmp bitmaps to the internal format (though it currently ignores the palette value and blindly sets things pixels to black or white).
Initial work on converting bitmap colour depths. The internal bitmap format in ZBitmap stores a pixel as a 32 bit value - the new code can translate mono Bmp bitmaps to the internal format (though it currently ignores the palette value and blindly sets things pixels to black or white).
ZBitmap
Copperbox revision 436.
I've made the BmpBitmap type opaque. Most of its attributes are constrained to particular values, so it makes sense to prevent new BmpBitmaps being created with arbitrary values.
I've made the BmpBitmap type opaque. Most of its attributes are constrained to particular values, so it makes sense to prevent new BmpBitmaps being created with arbitrary values.
Wednesday, January 28, 2009
ZBitmap
Copperbox revision 434.
ZBmp is now ZBitmap.
I've renamed ZBmp to ZBitmap - the bitmap surface handling is a bit more generalized as I'm working towards supporting different pixel formats. Its still all rather messy at the moment though. Also the types are improved so it should be easier to marshal a surface between other applications (especially the FreeType binding), and then render it as a DIB bitmap.
ZBmp is now ZBitmap.
I've renamed ZBmp to ZBitmap - the bitmap surface handling is a bit more generalized as I'm working towards supporting different pixel formats. Its still all rather messy at the moment though. Also the types are improved so it should be easier to marshal a surface between other applications (especially the FreeType binding), and then render it as a DIB bitmap.
ZBmp
Copperbox revision 433.
Update to the original ZBmp to use some of the code from Mono-ZBmp. This is not yet a full merge as the original ZBmp still only handles 24-bit bitmaps.
Update to the original ZBmp to use some of the code from Mono-ZBmp. This is not yet a full merge as the original ZBmp still only handles 24-bit bitmaps.
Tuesday, January 27, 2009
ZBmp
Copperbox revision 432.
More work on the mono bitmap version of ZBmp.
It's now a bit smarter about overlay indexes - the data is in a flat array of bytes but pixels are addressable by their row and column, which uses both array and bit addressing via the Bits class (reversed as the data is stored by MSB rather than LSB).
All that said, the code quality is really quite low. But, as I've spent the last three days working on addressing schemes and combinators that bore no fruit, committing something that works (just) is a relief.
More work on the mono bitmap version of ZBmp.
It's now a bit smarter about overlay indexes - the data is in a flat array of bytes but pixels are addressable by their row and column, which uses both array and bit addressing via the Bits class (reversed as the data is stored by MSB rather than LSB).
All that said, the code quality is really quite low. But, as I've spent the last three days working on addressing schemes and combinators that bore no fruit, committing something that works (just) is a relief.
Friday, January 23, 2009
Thursday, January 22, 2009
Haskell FreeType binding
Copperbox revision 428.
This time the Bitmap datatype is genuinely improved. There's still room for improvement: the buffer is currently a Haskell string - it would be better as an array.
This time the Bitmap datatype is genuinely improved. There's still room for improvement: the buffer is currently a Haskell string - it would be better as an array.
Haskell FreeType binding
Copperbox revision 427.
Some work on the Bitmap datatype. I've made it more opaque, though I'm not sure this is an improvement. As the binding is still a long way off being usable its worth committing the code as a checkpoint.
Some work on the Bitmap datatype. I've made it more opaque, though I'm not sure this is an improvement. As the binding is still a long way off being usable its worth committing the code as a checkpoint.
Wednesday, January 21, 2009
Haskell FreeType binding
Copperbox revision 426.
Finally I've got Example1 working. I've spent all day confusing myself with simple geometry but in the last session of the day I finally eliminated the problems I'd made for myself.
Finally I've got Example1 working. I've spent all day confusing myself with simple geometry but in the last session of the day I finally eliminated the problems I'd made for myself.
Tuesday, January 20, 2009
Haskell FreeType binding
Copperbox revision 425.
I've added a Haskell version of Example1.c from the FreeType tutorial. It runs and outputs something, though the output clearly isn't right. It might simply be that I haven't got my array traversals right (for one thing the output is portrait when it should be landscape). It's hard to tell, though, as the output is a large text file. It would be nice to hook up the FreeType binding to ZBmp.
I've added a Haskell version of Example1.c from the FreeType tutorial. It runs and outputs something, though the output clearly isn't right. It might simply be that I haven't got my array traversals right (for one thing the output is portrait when it should be landscape). It's hard to tell, though, as the output is a large text file. It would be nice to hook up the FreeType binding to ZBmp.
ZBmp
Copperbox revision 424.
I've sorted the 'line boundary' bug out in ZBmp and also got writing bitmaps to work.
I've sorted the 'line boundary' bug out in ZBmp and also got writing bitmaps to work.
Monday, January 19, 2009
ZBmp
Copperbox revision 422.
More work on ZBmp - I've added an Ascii art renderer and changed the data representation pixels to an array. Also I've put the source in a better directory structure.
Copperbox revision 423.
Corrected a bug in the ascii render - it was getting rows and columns mixed up. It still seems to have problems if the bitmap size isn't a multiple of 4.
More work on ZBmp - I've added an Ascii art renderer and changed the data representation pixels to an array. Also I've put the source in a better directory structure.
Copperbox revision 423.
Corrected a bug in the ascii render - it was getting rows and columns mixed up. It still seems to have problems if the bitmap size isn't a multiple of 4.
Sunday, January 18, 2009
Haskell FreeType binding, plus ZBmp
Copperbox revision 421.
More work on the FreeType binding, plus start of a new library for working with *.bmp bitmap files. I want to be able to test the rendering form FreeType - currently it can write an Ascii rendition of a single character but I really need to be able to write bitmaps.
The available Haskell libraries for graphics (GD, GraphicsMagick, ...) seem to be bindings over substantial C libraries. This is more than I need, so I've started ZBmp to read and write *.bmp files. I want it to be almost as simple as possible[1] and have no dependencies outside the GHC base libraries.
[1] Currently it's too simple as it uses [[pixel]] - list of list of pixels - I'll make it use arrays in due course.
More work on the FreeType binding, plus start of a new library for working with *.bmp bitmap files. I want to be able to test the rendering form FreeType - currently it can write an Ascii rendition of a single character but I really need to be able to write bitmaps.
The available Haskell libraries for graphics (GD, GraphicsMagick, ...) seem to be bindings over substantial C libraries. This is more than I need, so I've started ZBmp to read and write *.bmp files. I want it to be almost as simple as possible[1] and have no dependencies outside the GHC base libraries.
[1] Currently it's too simple as it uses [[pixel]] - list of list of pixels - I'll make it use arrays in due course.
Haskell FreeType binding
Copperbox revision 420.
More work on the low level interface to FreeType.
I think I need to be a bit more thoughtful about which data structures I marshal to Haskell and which I leave in C especially when the C data structures have internal data. The FreeType type FT_FaceRec isn't marshaled across, instead there are peek functions to read the public fields and as the data is immutable and stays on the C side, there is no need for a Storable instance with poke.
There are probably quite a few structs that I went ahead an wrote the Storable instance for, that shouldn't have one.
More work on the low level interface to FreeType.
I think I need to be a bit more thoughtful about which data structures I marshal to Haskell and which I leave in C especially when the C data structures have internal data. The FreeType type FT_FaceRec isn't marshaled across, instead there are peek functions to read the public fields and as the data is immutable and stays on the C side, there is no need for a Storable instance with poke.
There are probably quite a few structs that I went ahead an wrote the Storable instance for, that shouldn't have one.
Haskell FreeType binding
Copperbox revision 419.
More work on the low-level interface. All of the types from Base Data Types and the Base Interface now have corresponding Haskell types.
More work on the low-level interface. All of the types from Base Data Types and the Base Interface now have corresponding Haskell types.
Saturday, January 17, 2009
Haskell FreeType binding
Copperbox revision 418.
I've split the BaseInterface Hsc wrapper into two parts - one for datatypes and one for FFI wrappers. The original module was rather messy and it was difficult to keep track of how much of the wrapper had been completed.
Also, I've fixed a resource handle leak in one of the examples in the OpenVG binding.
I've split the BaseInterface Hsc wrapper into two parts - one for datatypes and one for FFI wrappers. The original module was rather messy and it was difficult to keep track of how much of the wrapper had been completed.
Also, I've fixed a resource handle leak in one of the examples in the OpenVG binding.
Thursday, January 15, 2009
Haskell OpenVG binding
Copperbox revision 417.
I've added withResource functions that pair the creation and deletion of a resource with an encapsulated action function to use it (cf. withForeignPtr from Foreign.ForeignPtr).
Plus I've added a new utility module to provide path commands. This has necessitated some changes in the original OpenVG.Path module as some of the datatypes weren't right.
I've added withResource functions that pair the creation and deletion of a resource with an encapsulated action function to use it (cf. withForeignPtr from Foreign.ForeignPtr).
Plus I've added a new utility module to provide path commands. This has necessitated some changes in the original OpenVG.Path module as some of the datatypes weren't right.
OpenVG and FreeType bindings
Copperbox revision 416.
I've added a colour module to the OpenVG binding that defines OpenVG/OpenGL equivalents of the SVG list of named colours.
Also I committed some minor changes to the FreeType binding that had been hanging around in my local repository.
I've added a colour module to the OpenVG binding that defines OpenVG/OpenGL equivalents of the SVG list of named colours.
Also I committed some minor changes to the FreeType binding that had been hanging around in my local repository.
Haskell OpenVG binding
Copperbox revision 415.
Work on the cabal file and removing some compiler warnings (adding white space to the end of some files).
It seems that a Simple build will compile the library, so I might not need to use autoconf unfortunately on Windows the library gets built with name mangled symbols. Hopefully a bit of web searching will point up a solution.
Work on the cabal file and removing some compiler warnings (adding white space to the end of some files).
It seems that a Simple build will compile the library, so I might not need to use autoconf unfortunately on Windows the library gets built with name mangled symbols. Hopefully a bit of web searching will point up a solution.
Wednesday, January 14, 2009
Haskell OpenVG binding
Copperbox revision 414.
I've replicated the error handling in HsOpenGL for the OpenVG binding. This means that the only (significant) work outstanding before the binding is release ready is to write autoconf configure file.
I've replicated the error handling in HsOpenGL for the OpenVG binding. This means that the only (significant) work outstanding before the binding is release ready is to write autoconf configure file.
Haskell FreeType binding
Copperbox revision 413.
I've changed some of the interface to be more like the Haskell OpenGL binding - libraryVersion is now a gettable State Var, and rather than exposing the allocator and deallocator for the ft_library I've wrapped both in a withFreeType call which is like the withNURBSObj function.
Currently this is just an experiment, as I've just looked at a couple of examples where the GL idioms would work well. It would be nice for me if I could adopt HsOpenGL's idioms wholesale - then I wouldn't have to think up abstractions over FreeType for myself. But the GL idioms might not work well for FreeType. OpenGL is a rather special library, the API is essentially a set of commands - very little shared state is transmitted between the client and the library (the NURBS interface is one of the few places where a handle is taken by the client to point to the library's data). FreeType uses many more handles and data is more frequently created by the client and communicated to the library.
I've changed some of the interface to be more like the Haskell OpenGL binding - libraryVersion is now a gettable State Var, and rather than exposing the allocator and deallocator for the ft_library I've wrapped both in a withFreeType call which is like the withNURBSObj function.
Currently this is just an experiment, as I've just looked at a couple of examples where the GL idioms would work well. It would be nice for me if I could adopt HsOpenGL's idioms wholesale - then I wouldn't have to think up abstractions over FreeType for myself. But the GL idioms might not work well for FreeType. OpenGL is a rather special library, the API is essentially a set of commands - very little shared state is transmitted between the client and the library (the NURBS interface is one of the few places where a handle is taken by the client to point to the library's data). FreeType uses many more handles and data is more frequently created by the client and communicated to the library.
Tuesday, January 13, 2009
Haskell FreeType binding
Copperbox revision 411.
I've changed to a more pedantic naming scheme to help me keep track of the underlying C types.
I've changed to a more pedantic naming scheme to help me keep track of the underlying C types.
Monday, January 12, 2009
Haskell FreeType binding
Copperbox revision 410.
The enough of the binding is now implemented to do basic rendering. The FontData example does a demonstration rendering a character to ascii art.
The enough of the binding is now implemented to do basic rendering. The FontData example does a demonstration rendering a character to ascii art.
Haskell FreeType binding
Copperbox revision 409.
Added a new example FontData.hs which loads a typeface, then queries it.
Added a new example FontData.hs which loads a typeface, then queries it.
Sunday, January 11, 2009
Haskell FreeType binding
Copperbox revision 408.
Adding the correct hsc files - the wrong ones were in the Subversion repo.
Adding the correct hsc files - the wrong ones were in the Subversion repo.
Haskell FreeType binding
Copperbox revision 406.
Work on the interface rather than just the ccall stubs. I've got the Haskell equivalents to FT_Init_FreeType and FT_Done_FreeType working through a ForeignPtr.
Work on the interface rather than just the ccall stubs. I've got the Haskell equivalents to FT_Init_FreeType and FT_Done_FreeType working through a ForeignPtr.
Saturday, January 10, 2009
Haskell FreeType binding
Copperbox revision 405.
Haskell FreeType binding - ccall wrappers for the outline functions (these would seem to be the important ones for vector graphics).
Haskell FreeType binding - ccall wrappers for the outline functions (these would seem to be the important ones for vector graphics).
Friday, January 9, 2009
Haskell FreeType binding
Copperbox revision 404.
Added Storable instances for the Haskell datatypes. Now all the C functions and types in the base interface have a Haskell equivalent, but they are so low-level as to be unusable. This makes the raising the abstraction level the real work (which is all still to do).
Added Storable instances for the Haskell datatypes. Now all the C functions and types in the base interface have a Haskell equivalent, but they are so low-level as to be unusable. This makes the raising the abstraction level the real work (which is all still to do).
Thursday, January 8, 2009
Haskell FreeType binding
Copperbox revision 402.
I've started work on a binding to FreeType2's basic API. Using FreeType would seem to be the most appropriate way of getting font data into OpenVG. Potentially it would be wiser to do this entirely in 'C-land' but I'll try it through Haskell with a C binding first.
I've started work on a binding to FreeType2's basic API. Using FreeType would seem to be the most appropriate way of getting font data into OpenVG. Potentially it would be wiser to do this entirely in 'C-land' but I'll try it through Haskell with a C binding first.
Wednesday, January 7, 2009
Haskell OpenVG binding
Copperbox revision 401.
Finished haddocking the exposed modules in the OpenVG binding. There are a few functions that I haven't translated yet (e.g. vgGetMatrix), and I'm not sure if some of functions are missing on in the ShivaVG dll on Windows due to my compilation hack, but most of the code is done.
The VGU module remains a bit of a sore thumb - although it makes some functionality more high-level, it does it is a way that is particularly un-Haskell. It might make most sense simply to leave it as is, and define a original higher-level interface.
Finished haddocking the exposed modules in the OpenVG binding. There are a few functions that I haven't translated yet (e.g. vgGetMatrix), and I'm not sure if some of functions are missing on in the ShivaVG dll on Windows due to my compilation hack, but most of the code is done.
The VGU module remains a bit of a sore thumb - although it makes some functionality more high-level, it does it is a way that is particularly un-Haskell. It might make most sense simply to leave it as is, and define a original higher-level interface.
Haskell OpenVG binding
Copperbox revision 400.
No big news for Copperbox's 400th commit, just more Haddock documentation added to the Haskell OpenVG binding. I'd say that I'm about half way through haddocking, which then leaves the autoconf script as the main thing to do.
No big news for Copperbox's 400th commit, just more Haddock documentation added to the Haskell OpenVG binding. I'd say that I'm about half way through haddocking, which then leaves the autoconf script as the main thing to do.
Tuesday, January 6, 2009
Haskell OpenVG binding
Copperbox revision 399.
More work on the Haskell OpenVG binding - adding Haddock documentation and changing various function signatures to use the Size and Position datatypes from HOpenGL.
More work on the Haskell OpenVG binding - adding Haddock documentation and changing various function signatures to use the Size and Position datatypes from HOpenGL.
Haskell OpenVG binding
Copperbox revision 398.
Added a Haskell version of test_vgu.c from the ShivaVG distribution. And it works! (although there is a slight glitch drawing polygons).
Monday, January 5, 2009
OpenVG binding
Copperbox revisions 396 & 397.
Reorganising the OpenVG directories to fit a cabal build. I've added a cabal file, but it looks like I'm going to have to use autoconf/configure anyway. Revision 396 deleted all the Haskell source for the OpenVG binding, which wasn't a welcome gesture (I suppose I'll have to revise my intuition how svn move works).
Reorganising the OpenVG directories to fit a cabal build. I've added a cabal file, but it looks like I'm going to have to use autoconf/configure anyway. Revision 396 deleted all the Haskell source for the OpenVG binding, which wasn't a welcome gesture (I suppose I'll have to revise my intuition how svn move works).
Sunday, January 4, 2009
OpenVG binding
Copperbox revision 395.
More work on the Haskell Shiva-VG OpenVG binding. Mainly on VGU, which now just needs error handling sorting out (i.e. getting it consistent with the OpenGL binding's error handling).
More work on the Haskell Shiva-VG OpenVG binding. Mainly on VGU, which now just needs error handling sorting out (i.e. getting it consistent with the OpenGL binding's error handling).
OpenVG binding
Copperbox revision 394.
Latest updates to the Haskell OpenVG binding. The most salient change is I'm making sure I'm working to the 1.0.1 spec (which is the revision Shiva-VG targets). Previously I'd been using the 1.1 spec as it was the one I originally downloaded.
I don't think using the wrong version of the spec has actually made me waste any time, but gosh there really is a lot of work to do. I'd imagined it would take me a couple of days at most, after all Ivan Leben did the hard work of writing the implementation, and Sven Panne did the hard work of the Haskell OpenVG binding which I'm cribbing from to do the OpenVG one. But as I do more I realize there's more to do... much more.
Latest updates to the Haskell OpenVG binding. The most salient change is I'm making sure I'm working to the 1.0.1 spec (which is the revision Shiva-VG targets). Previously I'd been using the 1.1 spec as it was the one I originally downloaded.
I don't think using the wrong version of the spec has actually made me waste any time, but gosh there really is a lot of work to do. I'd imagined it would take me a couple of days at most, after all Ivan Leben did the hard work of writing the implementation, and Sven Panne did the hard work of the Haskell OpenVG binding which I'm cribbing from to do the OpenVG one. But as I do more I realize there's more to do... much more.
Saturday, January 3, 2009
Friday, January 2, 2009
OpenVG binding
Copperbox revision 392.
More work on the Haskell OpenVG binding. Still plenty to do though.
More work on the Haskell OpenVG binding. Still plenty to do though.
Thursday, January 1, 2009
OpenVG binding
Copperbox revision 391.
Ah success!
The Haskell binding can now talk to shiva-vg on Windows and get the vendor id (Ivan Leben - many thanks for your nice library, Ivan!) and the version number.
To do - about 70 functions... Try on OSX and Linux... Work out a communicable method of building the shiva libs on Windows (it has taken a lot of hacks to get this far). Cabal install...
Ah success!
The Haskell binding can now talk to shiva-vg on Windows and get the vendor id (Ivan Leben - many thanks for your nice library, Ivan!) and the version number.
To do - about 70 functions... Try on OSX and Linux... Work out a communicable method of building the shiva libs on Windows (it has taken a lot of hacks to get this far). Cabal install...
OpenVG binding
Copperbox revision 390.
All the C functions now have a corresponding foreign import ccall definition.
All the C functions now have a corresponding foreign import ccall definition.
Subscribe to:
Posts (Atom)
About Me
- Stephen Tetley
- Disambiguating biog as there are a few Stephen Tetley's in the world. I'm neither a cage fighter or yachtsman. I studied Fine Art in the nineties (foundation Bradford 1992, degree Cheltenham 1992 - 95) then Computing part-time at Leeds Met graduating in 2003. I'm the Stephen Tetley on Haskell Cafe and Stackoverflow.