View previous topic :: View next topic |
Author |
Message |
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Tue Oct 10, 2006 2:33 pm Post subject: |
|
|
All set. The Arc/Derelict packages are now in the FreeUniverse SVN.
Quote: | I see somebody already implemented zooming though. |
You can thank Sequoh for that |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Oct 10, 2006 3:08 pm Post subject: |
|
|
phr00t - I'm just renamed "arcgames" to "arc" so it will compile.
Also, I wonder where Sequoh put the zooming code.. hrm.
edit: finally got those darn rocks to work right
Last edited by clayasaurus on Tue Oct 10, 2006 3:18 pm; edited 1 time in total |
|
Back to top |
|
|
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Tue Oct 10, 2006 3:12 pm Post subject: |
|
|
Quote: | I'm just renamed "arcgames" to "arc" so it will compile. |
OK, good! I wanted the name "arc", but I was having some silly problem with "arc" and the SVN (was saying it was obstructed??). Anyway, good |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Oct 10, 2006 3:33 pm Post subject: |
|
|
I'm going to be making some changes to 'modernize' your version of Arc, but first I'll ask, do you use perpixel collision at all? If not them I'm going to remove it along with sdl rotozoom.
Other changes I might do
* sound system
* adding xml capabilities
* adding arc 'log' , this is better than writef because you can redirect it to stdout, a text file, or an xml file, and it forces you to provide useful debug info
* if I can find zoom, attempt to turn it from the current (software?) to hardware implementation
* should we rotate the game camera as the ship rotates?
* should we really zoom out _that_ far when the ship accelerates? should each ship have a certain "max sight" ? |
|
Back to top |
|
|
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Tue Oct 10, 2006 3:55 pm Post subject: |
|
|
I don't use any perpixel collision detection.
* Sound system: Good.
* XML / Log: sure
* Zoom SW->HW: Work with Sequoh on this... I haven't been doing any zooming code.
* Rotating camera: Hrm, I don't think so. This would give the effect that your ship is always pointed up, and the universe spins around you? I perfer the current "look and feel" of turning...
* Zoom distance: Yeah, the zooming needs some tweaking... max sight? I was thinking the zoom should be porportional to your speed -- not ship...? |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Oct 10, 2006 4:19 pm Post subject: |
|
|
Phr00t wrote: |
max sight? I was thinking the zoom should be porportional to your speed -- not ship...?
|
Hrm.. alright. I thought it might be cool to have a 'sight' attribute (or maybe a sensor attribute?) on your ship and the bigger ship you get the better 'sight range' it gets, allowing you to see more and more of the universe. It doesn't make sense to me that the faster you go the farther you see. For example, if I go 200mph in a car it is not like I can see 100 miles further.
Your call, however. |
|
Back to top |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Tue Oct 10, 2006 4:29 pm Post subject: |
|
|
Quote: | Also, I wonder where Sequoh put the zooming code.. hrm. |
What's currently in FreeUniverse is a 'we can do it even without adjusting the camera' implementation. That means I have a global zoom variable by which everything is scaled down. Check init/init.d for that. I hope to replace that as soon as Arc manages the zooming.
The current zooming in and out is really just a hack to show how it could work. Feel free to tweak the lines in space/handler.d to make it better.
About zooming out when going fast: I did this so you see where you're going. And yes, it's too extreme at the moment. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Tue Oct 10, 2006 5:09 pm Post subject: |
|
|
Just cleaned up the arc code based some
1) Added log. Please use log instead of writefln and import arc.io.log instead of std.stdio even if you don't use log.
arc.io.log.write("currentFile", "currentFunction", "info/warn/error", ... "message");
"error" causes the game to quit instead of assert
2) Try to use ARC_UP instead of SDLK_UP etc.
3) removed rotozoom and perpixel collision
That's about it. Also instead of tex.ID it is tex.getID, getWidth, getHeight.
Sorry I am in a rush right now going to give a student seminar on D and Arc!
g2g
~Clay |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Wed Oct 11, 2006 12:11 am Post subject: |
|
|
Just made another change ...
1) Added camera. I havn't been able to get it to work quite right because since it zooms the actual screen smaller it doesn't have the effect wanted. Maybe Sequoh can work on this?
// zoom projection mode
arc.io.camera.open();
render_game();
arc.io.camera.close();
// normal 2d projection mode
arc.io.window.mode2D();
render_gui();
2) Upgraded version of derelict
3) Replaced SDL_mixer sound system with OpenAL
4) Upgraded Point + triangle + phyutil
5) Added run-build.bat , either run from command line or configure poseidon to use it, or double-click it from the folder. I'm lazy and don't like to type the build string every time |
|
Back to top |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Wed Oct 11, 2006 2:53 am Post subject: |
|
|
I've added arc/io/log.d and arc/io/sound.d to the repository from arc's svn - they were missing.
I'll check out the new camera module later. Basically, you'd have to get rid of the current zoom code (set ZOOM = 1) and if you want to use camera translation, also make sure SCROLL_X_OFF, SCROLL_Y_OFF are zero all the time.
Then add the camera code in front of the space drawing.
By the way, I think I'd prefer if there was an actual camera class, so I can store multiple camera settings, like:
Camera main_space_view;
Camera minimap_view;
Camera interface_view; // was mode2D
And then just do
main_space_view.open();
blub
main_space_view.close();
... same for other cameras. Might even be able to get rid of close() call? (didn't check the implementation yet)
Can live with the way it is atm though.
Also, instead of storing scroll and zoom ourselves seperately, we could actively use
main_space_view.getX/getY/getZoom |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Wed Oct 11, 2006 7:58 am Post subject: |
|
|
Alright, I turned camera into a class then and allowed the use of storing glOrtho projection settings inside of it.
camera.close() is needed to pop the projection matrix back to normal.
Also, I think I know a solution for the draw order problem. I need to add a templated <key> option for the linklist, so you can choose to sort a linked list by any data type you want to.
For the object list, the key can be an int, which would represent draw order. After loading all the objects inside of the linked list with the draw order sorting key, simply .sort() linked list and everything should be drawn in the correct order.
I'll work on the linked list sorting mechanism...
[edit]
I got the linked list merge sort working so it will sort objects based on draw order, but for some reason it isn't having any effect! I am really confused now and must conduct more experiements later... but for now I am done. Maybe I just don't know where I should sort the space objects?
The biggest change I've made is that now linked list objects need an extra DRAW_ORDER enum to know what order to sort the objects in.
I'll commit my changes, I hope you don't mind.
~ Clay |
|
Back to top |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Wed Oct 11, 2006 9:03 pm Post subject: |
|
|
Quote: | I'll commit my changes, I hope you don't mind. |
Of course not! You're working increadibly fast! I wish I had more time for what I term 'recreational programming'...
But please always check if there are any files/directories not yet in svn with 'svn status' before committing. This time I added arc/tools/xml from arc's svn since it was missing in the FU repository.
I didn't see a call to SpaceObjects.sort() anywhere. Could it be that you just forgot to put it in? I tried, but couldn't test since I don't know what the 'draw order problem' actually is.
If it has anything to do with particles, you'll be out of luck - they're stored in a seperate list at the moment and are drawn before any space objects are. |
|
Back to top |
|
|
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Wed Oct 11, 2006 11:27 pm Post subject: |
|
|
The draw order problem is that objects are being drawn out of order.
My proposed solution was to add a 'sorting key' to all linked lists that will sort the objects by the sorting key.
IE:
"a" with key 4
"b" with key 2
"c" with key 6
will sort them to order
"b"
"a"
"c"
If the objects are sorted in the correct order, then they should be drawn in the right order if you are using a loop like
while (!spaceobjects.last)
spaceobjects.data.draw();
So, I implemented a merge sort to my linked list structure and adding a sorting key with a DRAW_ORDER enum in init.d
enum DRAW_ORDER
{
SPACEOBJECT,
PLANET,
SHIP,
STATION
}
and I've tried to use a .sort() in numberous places, but it didn't work so I just removed my .sort()
Oh, and I moved xml from tools to io, btw.
I also moved dlinkedlist from tl to templates.
I'm sorry about forgetting to add stuff to the SVN
[edit]: I did an experiment, and I can effect the draw order of the space ships and planets. I tried it with particles, but no success yet. I'm just calling .sort() every frame, which has no noticable performance degradation on my machine, but there should be a better way.
[edit]: there are 2 solutions to fix the draw ordering problem
1) Put all objects and particles etc. in the same list, then a .sort() would sort them by draw order correctly.
2) Split up all different types of objects in a seperate linked list, then simply draw them in the right order, ie..
planets.draw()
ships.draw()
particles.draw()
I like solution #2 because you do not need to sort, although #1 could work as well. |
|
Back to top |
|
|
ChristianK
Joined: 26 Sep 2006 Posts: 159 Location: Berlin, Germany
|
Posted: Thu Oct 12, 2006 4:29 am Post subject: |
|
|
Thanks for the explanation! How can I reproduce the bug? What's drawn in the wrong order?
About calling .sort every frame: You could make the dlinkedlist.add function add new elements in the correct position to avoid having to resort constantly. However, sorting something that's almost completely sorted already should be really close to O(n) for most algorithms anyway.
Your options:
1) Particles are not derived from FU_OBJECT. I've previously talked to Phr00t about it and think that will change eventually. It makes keeping everything in one list not an option at the moment.
2) Split lists would have the added advantage of being able to get rid of mosts of the run-time type checking and casts, making some things cleaner. However, calling each FU_OBJECT's handle_object would get more tiresome. I propose a custom holder class, that allows to iterate over all FU_OBJECTs in the right display order and also over the seperate FU_SHIP, etc. |
|
Back to top |
|
|
Phr00t
Joined: 03 Mar 2006 Posts: 203
|
Posted: Thu Oct 12, 2006 11:31 am Post subject: |
|
|
Hrm.. I like splitting up the lists, especially getting the projectiles out of the same list that ships are in...
BUT, remember that particles need to draw below ships, but above planets/stations -- and I believe ships and planets are going to always be in the same list, or else that could get messy?
I was suggesting running the particles loop/drawing code when the first ship object was reached in the SpaceObjects linked list, so all particles would then be drawn (which is after planets/stations etc. which are already sorted before all ships), and then that first ship could be drawn (then continue through SpaceObjects as normal). This would draw them in order without much change to the code, or need for extra sorting.
- Jeremy |
|
Back to top |
|
|
|