Chronicals of Nada
GravitySpec
Very exciting stuff going on from what I have gathered over the past
few days. After getting my degree in Computer Science and obtaining a
full-time job doing application development in VB.NET and ASP.NET with
VB.NET backend. I've been slowly bringing my life together while
getting accustomed to commute and a workout routine after work.
As such, I was supposed to make my school project (a game using najaks
RAGE) available for everyone grab.
Here is the link:
http://cs.selu.edu/~ltrahan/Nada/Chronicals_of_Nada.rar
This is using a modified version of Najaks RAGE (Aug_18th_Demo).
Note: In order to build this you will need the June 2005 DirectX SDK
which you can get here:
http://cs.selu.edu/~ltrahan/Nada/dxsdk_jun2005.exe
The game was far from complete because of time constraints and poor
organization throughout the first half of the semester (not to mention
losing weeks of development because of Hurricane Katrina). But I hope
it has enough to give some people some ideas.
Here is a brief overview:
-There are some weather effects created using the Axiom's particle
system
-Fighting is done using a Turn-Based fighting system (my team really
wanted to do this for some reason)
-Monsters roam around the world (they follow a defined path)
-To fight with a monster just walk into it
-There are shops where you can purchase equipment and potions around
town (although I'm not sure how far my teammate in charge of stat
calculations got with implementing all of it)
-Axiom's particle system was used to make lanterns around town glow
-To save on much needed frames I created a method for culling objects
from the renderer so if you were too far away from town, expensive
items like the mass of particles running from the lamps would simply
turn off if you are far away.
-You can also progress to different areas with different music for each
area. Head to the boat on the docks to be transported to the desert.
Walk back to the boat on the shore to return to town.
Movement is done using the A, S, W, D keys
Jump = Spacebar (there is currently no limit on how many times you can
jump so you can fly around if you want)
Set Recall Point = R
Teleport to Recall Point = T
(there is a 5 second delay from the time you press the key to simulate
a type of casting delay)
I'm sure I may be forgetting some stuff but just play around with it
and I hope it gives people ideas. When Dan's ink is finished drying I
will be looking forward to playing with developing better things in the
new system to come.
It's good to be back.
-GravitySpec
P.S. Watch out for the giant Yakuza running around town, he will mess
you up if you don't have potions when you fight him.
najak
GeForce FX 5200, so it all runs at like 4 FPS, making it hard to enjoy
-- looks like I need to upgrade. :)
Have you profiled it to see where the bottlenecks are... is most of the
CPU being consumed by Axiom?
GravitySpec
recommendations?
>From what I can tell the only thing slowing this down is the sheer
amount of triangles being rendered. Hince why I had to cull the
particles from the lamps at a distance. If I let all the lamps stay lit
my FPS would drop under 30 while looking at the town from a distance
making the game run very choppy.
My system spec:
AMD Athlon 64 3400+ ~2.2 Ghz
1GB RAM
GeForce 6600 256MB
This was the designed minimum spec because this was the only system
that had an NVidia chipset (so the lighting would render correctly, not
sure why ATI cards will not render ambiant light correctly or not
render any other lightsource at all).
The system specs at our lab at school was (I think):
Pentium 4 3 Ghz
1GB RAM
ATI Radeon 9800 XT
The FPS was good on these machines but the lighting issued existed so I
can't say if that was a reason for it the have a slightly better FPS.
The person who made all the models minus the main player avatar did
everything as low in poly count as possible as he was big about making
efficient models. He also made efficient use of mapping the house
texture onto the inn model so that only one texture would be needed and
could be cleverly reused on multiple models.
I'm not sure if the FPS is a problem with Axiom. I do know that I have
tried to do some tests that showed if I look at one high poly model and
have a FPS of 60 and then I look at two of the same model my FPS will
drop to 30 even though they are the same model. I'm not sure if there
is a way to handle that better from pulling the existing model from
memory instead of creating two places in memory for the same model.
This is just a thought I have come up with.
I also forgot to mention that you need to left-click once to get past
the "Loading" screen. Not sure why it was done that way but another
teammate had set that up.
If you could make it past getting out of town to the forest or the
desert you could see some nice weather.
Fred Hirschfeld
NV 6800GT
najak
how useful it is. Otherwise, my only experience with .NET profilers is
with DevPartnerStudio7, which also costs about $3K/seat. I haven't
tried any budget profilers yet.
Has anyone else seen good performance from free or low-budget
profilers? (free or up to $300).
Terry L. Triplett
on), so can't answer that question. NProf looks interesting - might be
worth looking into: http://nprof.sourceforge.net
I'm not familiar with all the history of Axiom, but I don't get the
impression that serious optimization was ever done - the focus always
seemed to be more on getting the design right. Since anecdotal evidence
suggested performance was somewhat on par with Ogre (Randy Ridge posted
some benchmarks for the demos, as I recall), people were pleasantly
surprised and satisfied that there was nothing severely wrong.
After giving this a bit of thought (about 45 seconds worth - heh), I'm
going to say that while this is a crucial topic, worrying about this
right now may be premature. Since the expectation is that moving to
.NET 2.0 will result in performance improvements, waiting to put Axiom
under the microscope until after the first round of 1.1->2.0 changes is
complete (whatever that means) seems reasonable.
Until then, it's still worth identifying which areas are most likely to
affect performance and need to be looked at. Tao? It's certainly a
candidate, since so much rests on it. Tao still only supports .NET 1.1
- that's a factor to consider. After the next Tao release (should
happen Real Soon Now ... ), I'm going to recommend a push for 2.0
support. It's been talked about a bit, but nobody was motivated to make
the jump just yet. I'd say the time is right to revisit the issue.
I'll pass along any relevant news.
Beyond that, what other low hanging fruit is there?
GravitySpec
When the move to this new platform takes place, I plan to pick this
project back up and port it over to that platform. There is so much I
want to improve on and this is a nice base to work with, all things
considered.
I would really like the first thing to work on would be getting a
paging landscape established so that moving around in a large area will
not tax the system. Currently for this version the entire landscape is
rendered out even if you can't see the other areas over the hills. This
is one of the things that makes this so horribly inefficient, as this
is a fairly large piece of terrain that is loaded.
We had some trouble getting transparent textures to work in Axiom/RAGE
(hence all the trees look like as they are to work within the
constraints). It was discovered recently that there may have been a
problem with how Photoshop 7 was exporting the images. Our artist for
the project said he will re-export his models that used transparent
textures (trees, bushes, etc.) and I will test and see if this was the
case.
Fog was another issue as it was not functioning properly. I'm not sure
what was going on between Axiom and RAGE because I knew
Axiom/RealmForge had a working tech demo showing fog. If fog had worked
I would have been able to dramatically increase the FPS because I could
have culled out everything that was beyond the fog except for the
landscape since it was all one object.
One of the things we ran out of time on was getting some basic form of
collision. We had to decide on collision or make the monsters move
around the area. We had some basic method of collision but my teammate
that worked on it somehow lost it and was unable to recover or recreate
it because we ran so close to the deadline. :(
After I have a recreation of this project in the new platform with the
above changes the next thing I will work on is getting networking added
to the game. Of course I will have to convert the turn-based fighting
into a real-time fight system but my goal is to get more than one
person running around and chatting with other people.
"So little to do, so much time... wait... strike that, reverse it."
najak
RAGE layer), but if it turns out that I'm not going to finish it, I'll
pass that off to the public so that others can give it a try if they
want to. I've also integrated it with Lu4Net to allow for much
improved Application support, Forms, and Logging. Anyhow, I'm willing
to release this if others are interested. It is currently in a
somewhat unfinished state.
Rob Loach
video card that's the problem.... Great work though, keep it up. I
loved the music.
GravitySpec
with the style of the game. There is a copyright notice in the media
folder that outlines where things come from. Although the only outside
media came from Ragnarok Online for music. The rest was done by our
team artist with exception to some skyboxes.