Well, it's been a while since I've touched this. My previous post was started in july and got finished today, so I guess I should do an update as well.
Important things:
- I got married. Back in August :) It wasn't a big wedding, just close family and friends. Pictures are available on my wifes gallery here.
- I got my wifes website set up. If you fancy reading about hamsters then go to noobooweb. If you fancy a comic with 'stick-hamster'-esque drawings, then try here and read through Anita's HAMIC archive :)
- I've almost got a site for myself. I'll update here once I've finished off the last few details
- Work is going well. There's been some bad times and some people had to be made redundant :( Thankfully I wasn't one of them and I have since been moved onto a project where I'm able to do some real (C++) development. Which has been fun :)
And now it's approaching christmas, so got the holidays to look forward to. My first christmas as a married man :D
I hope the one person who actually reads this will have a good holiday too ;)
Sunday, December 7, 2008
Thursday, July 3, 2008
Reality is an illusion
So then, it's been a while since I've posted anything here. There's no particular reason for this, other than because I haven't really had anything to say. I feel I finally do but it isn't about programming or gaming, so bear with me.
Right now, my mind is of a scientific persuasion and I have been contemplating the nature of scientific enquiry. I know this isn't anything particularly new but I have an urge to write about it and I may have something to add to the age old description of what makes a scientist (or I may not... I don't know yet :)). So on with my ramble. I may wander to a point eventually.
I think I need to start with the title. It is part of one of my favourite quotes from Einstein and the full quote is 'Reality is an illusion, albeit a very persistent one'. It was part of my choice of name for this distinguished blog :) I've had a reason to think on it some more recently though and I think I have come to a line of thought that is at least new to me and relates this illusion not just to reality (which can easily be seen from just a quick glance over both quantum physics and relativity) but also to our description of reality, the laws and theories of physics. These are in a sense the ultimate illusion of reality as they give us a way of predicting things, making observations and generally increasing our knowledge. However, the only way we come up with new theories and laws is by questioning the currently established set and saying 'are these correct?'. Our description of how reality works is only ever expanded upon by attempting (and succeding) in showing that the current description is merely an illusion that fits the current observations of the greater illusion.
So, with the idea of reality as an illusion, and our description of reality as a higher-order illusion I turn now to the question:
'Is this correct?'
This question can be applied to any form of opinion, belief, idea or theory. It is this introspection that a scientist constantly requires and that a faith lacks. A true beliver starts from the assumption that they are correct and bases all ideas and conclusions on that. Even if they are later shown by evidence to be wrong with their initial assumption they will have become so used to the idea that they are right that it isn't themselves who are wrong, but everything else. A scientist starts from the assumption that they are wrong. If later on someone else (or themselves) shows that this is indeed the case, there is no shock or disappointment because they already knew that. It can just be taken in stride, examined and a better (but still wrong) idea can be put in place.
Applied to this post and my ideas, I have to say that no, I am not correct. What I'm saying is most likely complete nonsense, and the furthest I could possibly get from the truth. However, it is a starting point and it explains some things. So why bother? Curiosity and the thought that even though you are wrong, where the idea takes you may be interesting and, more importantly, slightly less wrong than the previous explanation. And it is this desire to be less wrong that expands the knowledge of the human race.
p.s. I know this post is kinda weird. It also doesn't flow particularly well. It was just something I was trying to get sorted in my own head and I think it's succeded on that front. If anyone wants, I can try and clean this up at another point but for now it's been sitting in my head for months and I'm gonna leave it as it is ;)
'Is this correct?'
This question can be applied to any form of opinion, belief, idea or theory. It is this introspection that a scientist constantly requires and that a faith lacks. A true beliver starts from the assumption that they are correct and bases all ideas and conclusions on that. Even if they are later shown by evidence to be wrong with their initial assumption they will have become so used to the idea that they are right that it isn't themselves who are wrong, but everything else. A scientist starts from the assumption that they are wrong. If later on someone else (or themselves) shows that this is indeed the case, there is no shock or disappointment because they already knew that. It can just be taken in stride, examined and a better (but still wrong) idea can be put in place.
Applied to this post and my ideas, I have to say that no, I am not correct. What I'm saying is most likely complete nonsense, and the furthest I could possibly get from the truth. However, it is a starting point and it explains some things. So why bother? Curiosity and the thought that even though you are wrong, where the idea takes you may be interesting and, more importantly, slightly less wrong than the previous explanation. And it is this desire to be less wrong that expands the knowledge of the human race.
p.s. I know this post is kinda weird. It also doesn't flow particularly well. It was just something I was trying to get sorted in my own head and I think it's succeded on that front. If anyone wants, I can try and clean this up at another point but for now it's been sitting in my head for months and I'm gonna leave it as it is ;)
Friday, April 18, 2008
A weekly check-in (almost)
And as a complete surprise, I've actually been doing some game-related programming this week :)
It isn't exactly interesting programming, but it's been fun doing it. I've been recreating my event-dispatcher and input manager code around SFML and, due to how easy SFML makes creating thread-safe code, I've even turned it into a threaded system while I was at it.
I've still got a bit left to do with my input-action code (namely, actually re-write it :)) but so far it's been going well. It took me very little time and effort to wrap an SFML event source (i.e. a window) into a class that would translate the event structure into a series of Event-derived classes and dispatch them to registered listeners. Then a little bit more to write listeners that would let you register multiple other listeners (multiple dispatch) to get events around the entire system.
I've almost finished with my input code as well now, with a keyboard and mouse class that can be registered as event listeners and give you input references to check if a button or key has been pressed (request a key input, it gives you back an input object that is bound to the key... a nice amalgam of polling and events I reckon :). The last section that I've just started on is to bind the inputs into named actions, which will allow a config file to load a set of actions and key mappings into the events and check for the actions by name rather than by key. It should be nicely configurable by the time I finish, unless something shiny distracts me sometime in the next week and I abandon it again :)
After that, I'll start working on some graphical stuff, although I am also thinking of some network engine stuff that I want to add to allow for even more ease of use with networking. If I do that next, I'll do a review on the SFML network package.
Other news: Wedding is getting closer and closer, and I have a hamster show to attend this weekend. Lots of fun :P
It isn't exactly interesting programming, but it's been fun doing it. I've been recreating my event-dispatcher and input manager code around SFML and, due to how easy SFML makes creating thread-safe code, I've even turned it into a threaded system while I was at it.
I've still got a bit left to do with my input-action code (namely, actually re-write it :)) but so far it's been going well. It took me very little time and effort to wrap an SFML event source (i.e. a window) into a class that would translate the event structure into a series of Event-derived classes and dispatch them to registered listeners. Then a little bit more to write listeners that would let you register multiple other listeners (multiple dispatch) to get events around the entire system.
I've almost finished with my input code as well now, with a keyboard and mouse class that can be registered as event listeners and give you input references to check if a button or key has been pressed (request a key input, it gives you back an input object that is bound to the key... a nice amalgam of polling and events I reckon :). The last section that I've just started on is to bind the inputs into named actions, which will allow a config file to load a set of actions and key mappings into the events and check for the actions by name rather than by key. It should be nicely configurable by the time I finish, unless something shiny distracts me sometime in the next week and I abandon it again :)
After that, I'll start working on some graphical stuff, although I am also thinking of some network engine stuff that I want to add to allow for even more ease of use with networking. If I do that next, I'll do a review on the SFML network package.
Other news: Wedding is getting closer and closer, and I have a hamster show to attend this weekend. Lots of fun :P
Wednesday, April 9, 2008
SFML - Getting back on the wagon (A brief review)
It's been a while since I've updated. That's mainly due to a lack of time to do any personal programming as I've been busy at work and organising a wedding (My own :D).
Still, I found myself with some free time yesterday and took the opportunity to try out a new framework mentioned on http://gpwiki.org/forums called SFML (Simple and Fast Multimedia Library). It's an Object Oriented C++ framework designed to speed up development of certain types of applications (games being one of them) and I have to say, first impressions are good.
Coding wise, the library is definitely simple and fast to pick up. It is organised into logical packages (system, graphics, windows, audio, networking, etc.) and can be used with either a package include (#include) or at a class level (#include ) allowing fine control of dependencies and coupling. Using the items couldn't be simpler either. The classes are typically designed along RAII principles and when they aren't (as is the case with mutexes) then an RAII wrapper is provided (in the previous case, the wrapper is the lock class). The interfaces to the classes are clean and simple to use and if you use a code-completing IDE such as Visual Studio then you also have easy access to the comments when browsing for the correct method (at this point it almost goes without saying that the comments are simple, but not too simple ;)).
Still, it is only a simple library so it must have some things it ignores or doesn't do well surely? Well, it only provides it's interfaces for 2d drawing operations. This doesn't make it useless for 3d though as once you have created a window (a single line of code, can't be much simpler eh? :)) then you have access to OpenGL for all your 3d needs. That's it, you include the headers, link it, open a window and you can use OpenGL. None of this messing around with creating a window with different parameters that is so common with other libraries. That makes it about as simple as possible for 3d development as well as 2d (if you have an engine that uses just OGL and requires a window set up for use, then it should work with SFML with almost no fuss). How about 2d and 3d together? Again, simple as can be, you just create a graphics RenderWindow (used for all SFMLs 2d api drawing) and you can mix and match OGL and SFML.
That last point needs to be taken with a slight pinch of salt though. After a very brief play with the library, I've already noticed that there is a slight speed issue with this. I've yet to track down exactly what is causing it (I'm using boost lexical_cast for an fps meter, so it could be that being called 20 times a second that is the bottleneck) but with a simple rotating cube and aforementioned FPS reading I was only getting 20fps. I wouldn't hold this against the library though. Mixing their 2d API with arbitrary OGL calls would always be a tricky operation. I believe it is made easier by their use of OGL under the hood for 2d API operations (or so I believe) but that introduces a problem of it's own, namely state management. With their 2d drawing, they will need to maintain both their state and your OGL state and switch them at the start and end of each function that relies on it. Even with the best algorithms this is a costly operation. It is recognised by the library creator though and they provide a way to turn off the state management if you use SMFL exclusively (or wish to manage the state yourself, as then you can store and manage state on a more sensible level than 'in my code, I must save your state').
I have yet to explore their sound or networking libraries, but I expect more of the same from them. The sound package is built upon OpenAL, so I would expect a fairly decent wrapper around that judging by the rest of the library. Networking is on the level of class-wrappers for network sockets etc. and so is probably the most low-level API available in the library. I'll comment more on them when I have used them more though.
My first impression is one of good, clean design and a decent implementation. Some possible speed issues that I haven't confirmed yet admittedly but even with that I have no problems recommending that anyone thinking of writing games and multimedia applications in C++ at least look at this library for their initial development period.
Still, I found myself with some free time yesterday and took the opportunity to try out a new framework mentioned on http://gpwiki.org/forums called SFML (Simple and Fast Multimedia Library). It's an Object Oriented C++ framework designed to speed up development of certain types of applications (games being one of them) and I have to say, first impressions are good.
Coding wise, the library is definitely simple and fast to pick up. It is organised into logical packages (system, graphics, windows, audio, networking, etc.) and can be used with either a package include (#include
Still, it is only a simple library so it must have some things it ignores or doesn't do well surely? Well, it only provides it's interfaces for 2d drawing operations. This doesn't make it useless for 3d though as once you have created a window (a single line of code, can't be much simpler eh? :)) then you have access to OpenGL for all your 3d needs. That's it, you include the headers, link it, open a window and you can use OpenGL. None of this messing around with creating a window with different parameters that is so common with other libraries. That makes it about as simple as possible for 3d development as well as 2d (if you have an engine that uses just OGL and requires a window set up for use, then it should work with SFML with almost no fuss). How about 2d and 3d together? Again, simple as can be, you just create a graphics RenderWindow (used for all SFMLs 2d api drawing) and you can mix and match OGL and SFML.
That last point needs to be taken with a slight pinch of salt though. After a very brief play with the library, I've already noticed that there is a slight speed issue with this. I've yet to track down exactly what is causing it (I'm using boost lexical_cast for an fps meter, so it could be that being called 20 times a second that is the bottleneck) but with a simple rotating cube and aforementioned FPS reading I was only getting 20fps. I wouldn't hold this against the library though. Mixing their 2d API with arbitrary OGL calls would always be a tricky operation. I believe it is made easier by their use of OGL under the hood for 2d API operations (or so I believe) but that introduces a problem of it's own, namely state management. With their 2d drawing, they will need to maintain both their state and your OGL state and switch them at the start and end of each function that relies on it. Even with the best algorithms this is a costly operation. It is recognised by the library creator though and they provide a way to turn off the state management if you use SMFL exclusively (or wish to manage the state yourself, as then you can store and manage state on a more sensible level than 'in my code, I must save your state').
I have yet to explore their sound or networking libraries, but I expect more of the same from them. The sound package is built upon OpenAL, so I would expect a fairly decent wrapper around that judging by the rest of the library. Networking is on the level of class-wrappers for network sockets etc. and so is probably the most low-level API available in the library. I'll comment more on them when I have used them more though.
My first impression is one of good, clean design and a decent implementation. Some possible speed issues that I haven't confirmed yet admittedly but even with that I have no problems recommending that anyone thinking of writing games and multimedia applications in C++ at least look at this library for their initial development period.
Subscribe to:
Posts (Atom)
Posts
