Page 1 of 2

Vertical Scroller Enhancements

Posted: Sat Apr 21, 2007 8:53 pm
by nicolasc
Hi all,

This term's subject for me is to enhance the vertical scroller in a manner, that it makes fun to play. To start with we will move away from the 2D world to a 3D...

Ideas will get introduced as they get implemented.

The first idea/concept is the so-called action box. the entire action takes place in this "box" in front of the player. the AI should be limited to this box, but within be a free as possible. limiting the AI to this box is an easy way to ensure that we will not have another embarrassing moment as we had with the last presentation.

Although I call it box, frustum (truncated cone) might be more suitable. As this "box" will be larger the further away from the player it is...

@chrigi: It doesn't matter whether it is a box or a frustum, as the inside check either way consists of 6 plane comparisons! It is only a little more difficult to imagine.

Stay tuned!
nico

Posted: Sun Apr 22, 2007 10:31 am
by chrigi
No, this should be no problem.

Posted: Tue Apr 24, 2007 7:53 pm
by patrick
Very cool! This is definitely something that Orxonox needs :D

If I may ask: What do you mean with moving to 3D world? Do you just change the perspective or do you allow full 3D flight?

Either way: I will try to collect some ideas as well :D

cu

Posted: Tue Apr 24, 2007 8:36 pm
by nicolasc
If I may ask: what do you mean with moving to 3d world? Do you just change the perspective or do you allow full 3D flight?
Change of perspective: I/We thought to stick with the scroller for a little longer, but give the track the ability to be placed freely. And the camera should be place "behind" the player.

I am heading back to my starfox-like ideas... but full free flight is currently no subject.

cheers
nico

Posted: Tue Apr 24, 2007 10:17 pm
by beni
Just be sure that the level design has to be accordingly. This perspective leads to new possibilities but also to yet unknown problems. But hey, I don't want to discourage you.

Posted: Tue Apr 24, 2007 10:31 pm
by nicolasc
Just be sure that the level design has to be accordingly. This perspective leads to new possibilities but also to yet unknown problems. But hey, I don't want to discourage you.
Thanks for the reminder... but what possibilities do we have ATM?? I think, it is more important just to get the game play up and running and fast! Debugging and balancing need much time...

cheers
nico

Posted: Wed Apr 25, 2007 7:04 am
by beni
It's true. It's probably my problem to think of everything at the same time. With you guys implementing the new perspective you will hopefully automatically think of interesting things to happen in the level...

Posted: Fri Apr 27, 2007 8:46 am
by chrigi
Action box is implemented. You can get a pointer to it with State::getActionBox()

Posted: Thu May 31, 2007 7:57 am
by nicolasc
I started modularizing the weapon payload for the player ship....
So far I have only created a few new functions, xml loadability is still missing.


@patrick:
How can I pull the position out of the mount points. Background is, that a weapon slots position is set in the oif-file, and I need to pass that position to the weapon manager to be able to create a new weapon slot.

cheers
nico

Posted: Thu May 31, 2007 11:16 am
by patrick
Yea, this is the great question. I did not have time to implement a dynamic weapon loader the last night before the presentation, this is why it looks a little bit unfinished.

So:
- Slot positions are read from the model file (there are placeholders there). This was at 1am in the morning
- The positions are passed to the weapon manager (somehow; don't remember anymore how I did this). There is perhaps a handler in spaceships or something that parses this data out of it (It was 4am when I wrote the code).
- The first weapon is assigned the first slot

Good luck. Ask me if you have a question to a concrete part of the code :D

Posted: Sun Jun 03, 2007 5:39 pm
by nicolasc
Sorry, but I am going to misuse this thread for my understanding problems.

A mountpoint get replaced by a weaponslot. Great, but how do I tell that weaponslot to which weaponmanager (remember we have 2) it belongs.

And how do I attach weapons (esp. their config slots) to that weaponslot.

Basically I need to give that weaponslot several (more or less) independent pieces of information.

I am not sure, where exactly the problem resides: Is it my limited understanding of the XML file, or how the hierarchy of the entire framework works

This is an example snipplet from an oif

Code: Select all

  <MP.00.rfcannon_tr>
    <Description>RFCannon</Description>
    <OrxClass>WeaponSlot</OrxClass>
    <Details>
      <WeaponClass>RFCannon</WeaponClass>
      <slot>0,0</slot>
    </Details>
  </MP.00.rfcannon_tr>
cheers
nico

WM rewrite; need another pair of eyes

Posted: Mon Jun 11, 2007 7:25 pm
by nicolasc
Browsing through the WM-XML loading part, I discovered that the somebody (I presume paeddu) tried to enhance the WM by introducing a weaponslot, but did not finish the job. I rewrote the entire thing and enforced the new hierarchy.
Now every WE has its WM (or 2 if its a spaceship). Every WM has a set of weaponslots, and every weaponslot has some weapons.
I needed this to be able to load data/weapons directly from the XML.

For some reason, it does not work and I cannot get a backtrace on my system (for whatever reason; I'll file a bug report), and the one I get from the tardis, does not make any sense. It seems to create a SIGSEGV while executing isActive() - which cannot be - so my guess is that there is something not properly initialized.

The post below, is a backtrace from a tradis machine:

Code: Select all

=======================================================
= time: Mon Jun 11 11:48:11 2007
=======================================================
Program received signal SIGABRT, Aborted.
[Switching to Thread -1237714016 (LWP 5395)]
0xb6fbf83b in raise () from /lib/tls/libc.so.6
(gdb)
#0  0xb6fbf83b in raise () from /lib/tls/libc.so.6
#1  0xb6fc0ecd in abort () from /lib/tls/libc.so.6
#2  0xb6fb92df in __assert_fail () from /lib/tls/libc.so.6
#3  0xb7ccbc0a in alSourcefv ()
   from /usr/pack/gamelibs-1.0-to/i686-debian-linux3.1/lib/libopenal.so.0
#4  0xb7ccb81e in alSource3f ()
   from /usr/pack/gamelibs-1.0-to/i686-debian-linux3.1/lib/libopenal.so.0
#5  0x0830f3e7 in OrxSound::SoundEngine::update (this=0x8ba4428)
    at sound_source.h:169
#6  0x08195c65 in GameWorld::update (this=0x8591a90)
    at lib/sound/sound_engine.h:33
#7  0x081956fa in GameWorld::run (this=0x8591a90)
    at story_entities/game_world.cc:346
#8  0x081955cd in GameWorld::start (this=0x0)
    at story_entities/game_world.cc:253
#9  0x0819239d in Campaign::run (this=0x858e588)
    at story_entities/campaign.cc:154
#10 0x0819225e in Campaign::start (this=0x858e588)
    at story_entities/campaign.cc:85
#11 0x08337a62 in GameLoader::start (this=0x0) at loading/game_loader.cc:164
#12 0x081b2c3f in Orxonox::start (this=0x84ccdf0) at orxonox.cc:416
#13 0x081b4d7b in startOrxonox (argc=1, argv=0xbfde1c54, name=@0x0, port=0)
    at orxonox.cc:577
#14 0x081b3306 in main (argc=1, argv=0xbfde1c54)
    at /usr/include/c++/3.3/bits/stl_alloc.h:652
(gdb)
(gdb)
I basically need someone to look through the code, and explain what i missed.

cheers
nico

PS: Sorry for the double post, but some umlaut trashed my post.

EDIT Deleted double post

Posted: Mon Jun 11, 2007 8:20 pm
by chrigi
Program received signal SIGABRT, Aborted.
Looks like this was no SIGSEGV, it was SIGABRT, which means some assertion failed. Last output line might be something like assertion in blabla.cc on line XX failed

running in circles

Posted: Tue Jun 12, 2007 2:19 pm
by nicolasc
I don't know... but I feel like running in circles.
I don't seem to get a reasonable backtrace on my notebook, and working on those tardis machines is only half an option. I decided to give myself time till Thursday to come up with an solution/fix/working hack whatever, and if not I'll revert to a state before the WM hacks. I need more time...

And that would be a typical trace... the error has to be somewhere is the first 3 steps...

Code: Select all

=======================================================
= time: Tue Jun 12 16:50:03 2007
=======================================================
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1238131808 (LWP 29549)]
WeaponManager::tick (this=0x8c08720, dt=0.00995119754) at weapons/weapon.h:106
106	    inline bool isActive() const { return (this->currentState == WS_INACTIVE)? false : true; };
(gdb) 
#0  WeaponManager::tick (this=0x8c08720, dt=0.00995119754)
    at weapons/weapon.h:106
#1  0x080c6627 in SpaceShip::tick (this=0x8c08490, time=0.00995119754)
    at world_entities/space_ships/space_ship.cc:479
#2  0x08195398 in GameWorld::tick (this=0x8590940, entityList=
          {<std::_List_base<WorldEntity*, std::allocator<WorldEntity*> >> = {<std::_List_alloc_base<WorldEntity*, std::allocator<WorldEntity*>, true>> = {_M_node = 0x884d470}, <No data fields>}, <No data fields>}, dt=0.00995119754)
    at /usr/include/c++/3.3/bits/stl_list.h:169
#3  0x0819550c in GameWorld::tick (this=0x8590940)
    at /usr/include/c++/3.3/bits/stl_list.h:117
#4  0x08195189 in GameWorld::run (this=0x8590940)
    at story_entities/game_world.cc:329
#5  0x08195095 in GameWorld::start (this=0x8c08c28)
    at story_entities/game_world.cc:253
#6  0x08191e65 in Campaign::run (this=0x858d438)
    at story_entities/campaign.cc:154
#7  0x08191d26 in Campaign::start (this=0x858d438)
    at story_entities/campaign.cc:85
#8  0x083374ca in GameLoader::start (this=0x8c08c28)
    at loading/game_loader.cc:164
#9  0x081b26c3 in Orxonox::start (this=0x84cbdf0) at orxonox.cc:416
#10 0x081b47ff in startOrxonox (argc=1, argv=0xbf87bf74, name=@0x8c08c28, 
    port=146836520) at orxonox.cc:577
#11 0x081b2d8a in main (argc=1, argv=0xbf87bf74)
    at /usr/include/c++/3.3/bits/stl_alloc.h:652
(gdb) 
(gdb) 
cheers
nico

Posted: Wed Jun 13, 2007 9:19 am
by patrick
That's a strange msg. Perhaps the weapon manager doesn't exist at this time. Although it sounds strange such a thing can happen...