View previous topic :: View next topic |
Author |
Message |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sun Sep 10, 2006 8:07 am Post subject: Long term project roadmap... |
|
|
Here is the long term project roadmap for Arc.
http://www.dsource.org/projects/arcgames/browser/web/arclib.html?format=raw
I'm having trouble updating the 'home page' so just use this link for now.
If there is anything else anyone thinks should be added then dicuss it here.
Last edited by clayasaurus on Sat Nov 18, 2006 1:44 pm; edited 8 times in total |
|
Back to top |
|
|
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Sun Sep 10, 2006 11:55 am Post subject: |
|
|
Wow, and I don't even have the rest of my afternoon planned. |
|
Back to top |
|
|
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Sun Sep 10, 2006 3:12 pm Post subject: |
|
|
Wow, very impressive! Go ArcGames |
|
Back to top |
|
|
Lutger
Joined: 25 May 2006 Posts: 91
|
Posted: Mon Sep 11, 2006 5:59 am Post subject: |
|
|
Nice one!
I have some code finished for an application that does batch image operations which might be useful. I'm stalled on the gui part, but that should not be a problem.
The useful parts of this code is: tightly packing smaller images into a bigger texture (spritesheets), cropping an image with an alpha layer in order to shave off redundant space, converting image to code. Furthermore there is regexp renaming and format conversions.
If you're interested I could expand it somehow into a tool for arc as this overlaps the autotrim option I see you have scheduled and a sprite editor you once mentioned.
The texture packing implements a modified version of this algorithm: http://www.blackpawn.com/texts/lightmaps/ |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Sep 12, 2006 3:43 pm Post subject: |
|
|
I don't think i'll need texture packing as I think the same effect can be achieved when you put a bunch of textures into a zip file.
As for image shaving, I already have an algorithm for that
However, if you do come up with something then I'll think about adding it. |
|
Back to top |
|
|
Lutger
Joined: 25 May 2006 Posts: 91
|
Posted: Tue Sep 12, 2006 5:51 pm Post subject: |
|
|
clayasaurus wrote: | I don't think i'll need texture packing as I think the same effect can be achieved when you put a bunch of textures into a zip file.
As for image shaving, I already have an algorithm for that
However, if you do come up with something then I'll think about adding it. |
All of what I proposed might be too much, I'll better develop as an independant app and provide some compatibility for Arc. The texture packing is still useful imo (saves VRAM). Let me hack something up and I'll send it for you to review so you can decide if it fits with your ideas? |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Fri Sep 22, 2006 3:06 pm Post subject: |
|
|
Lutger - sure, sounds good. If anything I could add it to the 'tools'.
----
* Polygon-polygon collision with sprite zoom/rotation/change size now works
* Sprite load from XML now works
* Units have changed from size(float argX, float argY) to size(Point s) instead, this simplifies code and allows a whole lot more power
----
This has been harder than I expected, especially the sprite zoom/rotation/change with the polygon, I was getting all weird sorts of errors.
Next up, I will improve the sound system.
edit: JoeCoder, would you be able to provide me with your latest and greatest OpenAL sound system code? It would save me a lot of time, thanks. |
|
Back to top |
|
|
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Sat Sep 23, 2006 2:31 pm Post subject: |
|
|
Clay,
You can get the latest "build" of my engine here. I say "build" because I've been so busy with school, etc. that I haven't worked on it in over two months and that's just something I put together for a homework assignment for my graphics class. Nonetheless, it's the latest code that compiles. This is my last semester of school, so I'm looking forward to having more time after it's complete.
You'll find a sound.d in the resource module. The main class here acts as a layer of abstraction for different sound file formats. Near the bottom you'll find a VorbisFile class where the constructor loads an ogg vorbis file and it's associated properties, a getBuffer() function to retrieve raw, uncompressed sound data at an arbitrary position, and the destructor closes the file.
In the node module you'll find sound.d with the soundNode class. This acts as an actual instance of a sound and can reference the aforementioned sound resources. Most of the methods here are well documented and straighforward. Although it's certainly not a simple and easy to learn from example, it is fairly feature complete.
I think you'll find some initiation code in device.d. Derelict has full support for OpenAL and libvorbis, so I have no special code for actually loading and linking with the libraries.
Finally, since I haven't had time for my engine lately, so you may need to make some changes to get it to work with the latest versions of Derelict and the D compiler. I'm usually on AIM if you need any quick answers.
[Edit]
There are some good OpenAL tutorials on devmaster.net; c++, but they helped me tremendously. Also, all of my code is public domain until I have more time to work on it and figure out a license, so do whatever you want with it. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Sat Sep 23, 2006 11:47 pm Post subject: |
|
|
Thank you very much I think I'm going to go through some devmaster tutorials to see what I can accomplish. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Mon Sep 25, 2006 7:18 pm Post subject: |
|
|
JoeCoder, if you were to write an OpenAL tutorial then it would be the best OpenAL tutorial on the net, simply because your code doesn't rely on ALUT, it better organized and is more powerful and flexible, and there are barely any tutorials out there. Thanks to you I was very easily able to implement OpenAL into Arc.
However, I will also have to add the resource manager now to arc to simplify my code and to make sure no resource gets loaded twice as right now the new sound code will load the same sound file twice, I know how to get around it but I want to do it the right way, so I'm going to implement a resource manager. Instead of newing sprites the usual way, with Arc, you'll do something like...
// this code will only load it if it doesn't already exist, otherwise
// it will just give handle to already existing tex
Texture tex = arc.io.resource.getTexture("star.png");
// only load it if not already loaded
SoundFile sound = arc.io.resource.getSound("stream.ogg");
Now, in order to implement the resource manager, the way I'm going to do it, I am also going to implement PhyFS. http://www.icculus.org/physfs/
So.. erm... I was seeming so close to done with version .2, but now I am so far away, but will technically save me 14 days in the long term.
edit: phr00t, real time pitch changing works now, yay! |
|
Back to top |
|
|
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Tue Sep 26, 2006 7:49 am Post subject: |
|
|
Quote: | edit: phr00t, real time pitch changing works now, yay! |
yay! |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Sep 26, 2006 2:56 pm Post subject: |
|
|
Implementing PhysFS is going to be a pain, because I have to learn how to load everything from a PhysFS_File * instead of a physical file.
It is possible, though, I think |
|
Back to top |
|
|
Lutger
Joined: 25 May 2006 Posts: 91
|
Posted: Wed Sep 27, 2006 6:05 am Post subject: |
|
|
clayasaurus wrote: | Implementing PhysFS is going to be a pain, because I have to learn how to load everything from a PhysFS_File * instead of a physical file.
It is possible, though, I think |
Then why use it? I think you can do better with a system designed from ground up, using mango. True, you'll (might?) have to learn mango and code it yourself, but:
- you will learn mango if you haven't used it. I'm trying to learn it now, it looks so good (huge though) and provides everything you need + more. You could pull networking code from there too, perhaps?
- it will be in D instead of C, can do OOP style.
- could keep it more simple at first.
- don't know the details, but I image you could extend FilePath and FileConduit to VirtualFilePath and VirtualFileConduit and leverage much of the mango api without a lot of work. Plus Arc users will be learning some mango instead of PhysFS which is more useful imo.
I'm not saying PhysFS is a poor choice, it's just I think you can code a much better library (better as in better for this purpose). |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Wed Sep 27, 2006 8:33 pm Post subject: |
|
|
Lutger wrote: |
Then why use it? I think you can do better with a system designed from ground up, using mango. True, you'll (might?) have to learn mango and code it yourself, but:
- you will learn mango if you haven't used it. I'm trying to learn it now, it looks so good (huge though) and provides everything you need + more. You could pull networking code from there too, perhaps?
- it will be in D instead of C, can do OOP style.
- could keep it more simple at first.
- don't know the details, but I image you could extend FilePath and FileConduit to VirtualFilePath and VirtualFileConduit and leverage much of the mango api without a lot of work. Plus Arc users will be learning some mango instead of PhysFS which is more useful imo.
I'm not saying PhysFS is a poor choice, it's just I think you can code a much better library (better as in better for this purpose). |
Arc users would just learn a few simple commands which wrap physfs. I'll think about implementing my own system, but I want to save as much time as possible and implementing my own would take considerably longer than using an existing system. I'll look at mango... but if I do decide to go with mango I'm going to make a lot of mango suggestions
I'm already having weird problems with PhysFS so, if I don't get those solved, I'll think about an alternative system. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Fri Sep 29, 2006 8:43 am Post subject: |
|
|
I've decided to rewrite Arc's development so it will not take until 2010 for Arc v1.0.
Instead, I've saved all the challanging features for Arc 2.0 and I hope I will be able to commemorate the D 1.0 release with an Arc 1.0 release.
In addition, this means the release of Arc v.2 is imminent. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|