Well, it all depends on what exactly you want to do, cause I can think of a few different ways of doing things for different purposes. Could you be a bit more specific?
So, repeating keys could easily be handled with a timer.
The logic: when the key's first pressed (IsActive + HasNewStatus), you add a global timer with the input name as payload.
In your callback timer, you check if the input is still active, if yes, you act (you can send an event or do anything you need to do) and you re-add the same timer with the same payload.
An alternative would be, when first adding the timer, to do it with infinite number of calls, and remove it from inside the callback when the input is inactive. Your choice!
Which one is more efficient?
And yeah, I've noticed it's been quite dead here. I mean, I haven't been here because of school. But I'm resolving to make more time to work on my game instead of playing other peoples'.
There isn't any real performance difference between both choices.
However the first approach (where you re-add the timer manually from within the timer), allows you to use different time intervals for the first time and the subsequent ones, like key repetition is usually done (first delay being much longer than subsequent ones).
Not sure why the forum has been dead silent recently, but that's often how things are around here: there are waves of questions followed by periods of silence. It's just been longer than usual.
I wrote the code for a new tutorial (actually two, but one is supposed to be simpler and referenced from the TexturePacker website soon): it show how to use the new resource module, how to extend resource types (in the example I show how all resources can be now easily loaded from ZIP files, for example) and some examples of more complex interactive timeline tracks.
I'll advertise it in a day or two via the new dev mailing list but if you're curious, it's all here: https://bitbucket.org/iarwain/resource
Hello everyone, the forum is silent but not dead, I check it once in a while. My final exam starts from tomorrow, after that I can have all the time I need to experiment with things And good to see zip file in action, just out of curiosity does it support encoded zip or password protected zip ?? Also new resource system seems much cleaner. Nice work iarwain
As for the tutorial, the goal is not so much to support ZIP file for others to use rather than showing how easy it is to add support for different resource types.
If you look at the .cpp file, you'll see that adding support for a new type of resource is pretty easy.
In there, I'm using Rich Geldreich's wonderful miniz (http://code.google.com/p/miniz/), which doesn't support encryption.
If you want to be able to support encrypted zip, you can follow the same steps I did in the tutorial and use a different library.
I chose miniz for the tutorial as it's contained in a single file and extremely easy to learn&use, perfect for a tutorial!
That being said, I'd recommend going for a different archive format than zip if you want to use encryption, encrypted zip files are notorious to be easily crackable.
Custom file archive is always a secure option, it might not be relevant but is it possible to load my resources while playing an animation. Can I do this using orx's default resource loading or I have to implement my own resource that will load data in small chunk or any other way?
Well it depends what you mean by "while playing an animation". Providing your own resource type won't change "when" a resource will get loaded, just "how".
You can of course load the resources yourself (asynchronously, for example), using the orxResource API, and make them available to orx, but that requires a good understanding on how the resources are used internally.
What is it precisely that you'd like to achieve? One day I'll probably support async loading/streaming, but it's not something that will likely happen soon.
Sorry I was not clear enough, I was talking about playing a loading animation while the resources are being loaded, what we see in most of the games. Like a loading bar, the bar will be 100% if all the resources are loaded. Kind of flash pre-loader.
Jim, the easiest way of doing this while not having to fiddle with multi-threading is to keep a list of the resources you want to load (either per level, per menu or all the resources if you think they'll all fit in memory), go over that list 1 or 2 items per frame and asks for their creation (orxTexture_CreateFromFile, orxSound_LoadSample, etc...).
This way orx will continue to work and update whichever animation/status bar you display on screen, and you load your resources one step at a time every frame.
Comments
Well, it all depends on what exactly you want to do, cause I can think of a few different ways of doing things for different purposes. Could you be a bit more specific?
So, repeating keys could easily be handled with a timer.
The logic: when the key's first pressed (IsActive + HasNewStatus), you add a global timer with the input name as payload.
In your callback timer, you check if the input is still active, if yes, you act (you can send an event or do anything you need to do) and you re-add the same timer with the same payload.
An alternative would be, when first adding the timer, to do it with infinite number of calls, and remove it from inside the callback when the input is inactive. Your choice!
And yeah, I've noticed it's been quite dead here. I mean, I haven't been here because of school. But I'm resolving to make more time to work on my game instead of playing other peoples'.
However the first approach (where you re-add the timer manually from within the timer), allows you to use different time intervals for the first time and the subsequent ones, like key repetition is usually done (first delay being much longer than subsequent ones).
Not sure why the forum has been dead silent recently, but that's often how things are around here: there are waves of questions followed by periods of silence. It's just been longer than usual.
I wrote the code for a new tutorial (actually two, but one is supposed to be simpler and referenced from the TexturePacker website soon): it show how to use the new resource module, how to extend resource types (in the example I show how all resources can be now easily loaded from ZIP files, for example) and some examples of more complex interactive timeline tracks.
I'll advertise it in a day or two via the new dev mailing list but if you're curious, it's all here: https://bitbucket.org/iarwain/resource
The simple one having a classic but still cool background wormhole effect shader: https://bitbucket.org/iarwain/simpletest
Let me know if you have any questions.
Best of luck for your finals, then!
As for the tutorial, the goal is not so much to support ZIP file for others to use rather than showing how easy it is to add support for different resource types.
If you look at the .cpp file, you'll see that adding support for a new type of resource is pretty easy.
In there, I'm using Rich Geldreich's wonderful miniz (http://code.google.com/p/miniz/), which doesn't support encryption.
If you want to be able to support encrypted zip, you can follow the same steps I did in the tutorial and use a different library.
I chose miniz for the tutorial as it's contained in a single file and extremely easy to learn&use, perfect for a tutorial!
That being said, I'd recommend going for a different archive format than zip if you want to use encryption, encrypted zip files are notorious to be easily crackable.
You can of course load the resources yourself (asynchronously, for example), using the orxResource API, and make them available to orx, but that requires a good understanding on how the resources are used internally.
What is it precisely that you'd like to achieve? One day I'll probably support async loading/streaming, but it's not something that will likely happen soon.
Jim, the easiest way of doing this while not having to fiddle with multi-threading is to keep a list of the resources you want to load (either per level, per menu or all the resources if you think they'll all fit in memory), go over that list 1 or 2 items per frame and asks for their creation (orxTexture_CreateFromFile, orxSound_LoadSample, etc...).
This way orx will continue to work and update whichever animation/status bar you display on screen, and you load your resources one step at a time every frame.