FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

FreeUniverse to Arc v.2 upgrade...
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic     Forum Index -> FreeUniverse
View previous topic :: View next topic  
Author Message
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Tue Oct 10, 2006 2:33 pm    Post subject: Reply with quote

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 Very Happy
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Oct 10, 2006 3:08 pm    Post subject: Reply with quote

phr00t - I'm just renamed "arcgames" to "arc" so it will compile. Smile

Also, I wonder where Sequoh put the zooming code.. hrm.

edit: finally got those darn rocks to work right Smile


Last edited by clayasaurus on Tue Oct 10, 2006 3:18 pm; edited 1 time in total
Back to top
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Tue Oct 10, 2006 3:12 pm    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Oct 10, 2006 3:33 pm    Post subject: Reply with quote

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 Smile
* 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
View user's profile Send private message AIM Address
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Tue Oct 10, 2006 3:55 pm    Post subject: Reply with quote

I don't use any perpixel collision detection.

* Sound system: Good.
* XML / Log: sure Very Happy
* 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
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Oct 10, 2006 4:19 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Tue Oct 10, 2006 4:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Tue Oct 10, 2006 5:09 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed Oct 11, 2006 12:11 am    Post subject: Reply with quote

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 Smile
Back to top
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Wed Oct 11, 2006 2:53 am    Post subject: Reply with quote

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
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed Oct 11, 2006 7:58 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Wed Oct 11, 2006 9:03 pm    Post subject: Reply with quote

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'... Smile

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
View user's profile Send private message
clayasaurus



Joined: 21 May 2004
Posts: 857

PostPosted: Wed Oct 11, 2006 11:27 pm    Post subject: Reply with quote

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 Sad 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 Embarassed

[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
View user's profile Send private message AIM Address
ChristianK



Joined: 26 Sep 2006
Posts: 159
Location: Berlin, Germany

PostPosted: Thu Oct 12, 2006 4:29 am    Post subject: Reply with quote

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
View user's profile Send private message
Phr00t



Joined: 03 Mar 2006
Posts: 203

PostPosted: Thu Oct 12, 2006 11:31 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> FreeUniverse All times are GMT - 6 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
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