This project has moved to
http://www.codeplex.com/Wiki/View.as...jectName=Raven
Printable View
This project has moved to
http://www.codeplex.com/Wiki/View.as...jectName=Raven
Okay, that's good. Got a few ideas on fiddling with heightmaps :)Quote:
31 fps, 800x600. And a canyon can be implemented quite accurately, I have tried that. Even with a larger scale.
A bit off-topic: How do we want to arrange sharing the data between us all? CVS? FTP?
As a good little OOP Coder I think it's a good idea that we seperate code in seperate DLL's so that's it's easier to update (and break compatiblity) seperate parts of code.
Correct me if I'm wrong here, this is just an sketchy idea. Feel free to come up with something better.
Main App
|
|\_ Engine (Sound, 3D, Input, etc)
|\_ Network (Network Protocol)
|\_ Game (AI, Parsing Gamedata)
\_ DataFetcher (Prefetch data via Network)
For easy use I guess it's easier to use design-time binding for now instead of late-binding during runtime.
Any screenies yet? :)
They started to discuss the game 20 hours ago..:D....Quote:
Originally Posted by wossname
[Edit]
Ohhh..BTW when thinking about it...:D
http://vbforums.com/attachment.php?attachmentid=40093
Nice, how large is that map in real world terms, few hundred metres on each side?
Give or take a few square miles :)Quote:
With a 128x128 heightmap, this is the terrain it makes, fairly large. It should be suitable for 10 people to run around in if you want them to fight using sniper weapons from far away, or 64 people if you want them fighting from medium/close range.
I don't think you'll want 64 mechs running around in a box of a few hundred meters :]
Check the mech.jpg file that's attached. That's from MechCommander 2 but Mechwarrior Battlegrounds will have basically a bit of the same look. Isometric-tilted camera and continuous control over the mech instead of RTS-Style point-n-click.
128x128 miles?? :eek:
I think 64 mechs running around in a football field sized area would be hilarious, you need to set that up and render a screeny for us :D
You guys going to sell this or open source it or what? :)
I used to have MechAssault on the XBox, that a kickass game that was. It'd be interesting to see how your project continues, I shall watch with interest.
So far I think this will be open source with a small expection of certain code (like the anti-cheat thingy which will be implemented at a later stage)
And no.. not 128x128 miles more or less 4 by 4 mile zones in team deathmatch or assaults. 1 by 1 mile for small deathmatch groups, 2 by 2 etc. Maybe we should incorporate Battlefield II's dynamic map size (depending on amount of players)? :D
128x128 square miles,no. But, safe to say, maps about the size of, or larger than, Battlefield 1942/Vietnam/2. Im going to try partioning the maps then rendering the closest partions.
Should be more then enough.
MechAssault was pretty cool xcept that it was only on Xbox.. I wish they kept it on the PC ;)Quote:
I used to have MechAssault on the XBox, that a kickass game that was. It'd be interesting to see how your project continues, I shall watch with interest
Edit: http://www.turbosquid.com/FullPrevie.../236682/blFP/1 (Madcat Mk. III)Quote:
Originally Posted by NoteMe
Thanks a bunch! :D
Got partioning working
Now im going to try and use distance and view culling and use larger heightmaps. :afrog:
Kewl, keep up the good work :)
Partioning? Looks like tiling to me..:)Quote:
Originally Posted by Cade
There is a faint mountain in the middle-right area ;)
Quote:
Originally Posted by Devion
Your point is? It is still not culling them. Still rendering the whole map isn't he? Hence there is no space partitioning algo implemented.
- ØØ
http://www.vbforums.com/showthread.p...65#post2144740
He's busy with it :)
There is now an algo implemented to cull tiles based on distance and view direction. Its just first I had to break up the map into tiles aka partions. ;)
Quote:
Originally Posted by Cade
It is called tiles..:D:D:D ;)
Well these partions contain info relevant to where they are along with the vertex data. And unless I am mistaken, a partion is a segment of something.
Partion/Partition
par·ti·tion (pär-tshn)
n.
1.
a. The act or process of dividing something into parts.
b. The state of being so divided.
tr.v. par·ti·tioned, par·ti·tion·ing, par·ti·tions
1. To divide into parts, pieces, or sections.
2. To divide or separate by means of a partition: We partitioned off the alcove to make another bedroom.
:D
Yeah, partition is a part of something. But in a binary tree you have nodes that is a part of the thee, but you don't call them partitions..;)
- ØØ -
I wouldn't call 'm tiles either though :]
Well, I will let you guys get on with your project...won't bother you more with terms.
Proof:
http://www.hsigraphics.com/bryce/tut...eterrains.html
- ;);) -
Tiles/Partions/Partitioning. End result is less array-hogging for VB. And it's the result that counts imho :)
End result is actually more array hogging if you add all the partion's together, but each partion contains less that in the whole array.
Heh; That's what I meant. The end result of having partitions wether some people call it tiles or not.
Partion isn't even a word. All the google results look like typo's to me.
Parti on dudes!!
Partition then?, I actually liked the word =)
Anyway; Partion or Partition or Tile or Segment or Cell - Does it really matter? We know what the subject is - The project thread is getting poluted by meaningless chatter about typo's and misformed words.
Replaced all 56 instances of Partion with Partition.
Btw, Devion, I am not working on the actual game code right now. I will leave it to you to create the base of the actual game. I am working on getting an outdoor terrain rendering system up (Done) and running as efficiently (Not done) as possible.
Are you guys designing your mechs from scratch or are you using meshes from one of the other games?
Don't worry, I kinda assumed that :)Quote:
Originally Posted by Cade
I was going to check in with the development team of Capellan Solution (C&C Generals Mechwarrior mod team) as they modelled about every mech type there is in any of the Mechwarrior games. If that doesn't work we would need a few modellers to work on 'm and build 'm from scratch (thank god there is enough research material on the net :))Quote:
Are you guys designing your mechs from scratch or are you using meshes from one of the other games?
You guys are Google nubs :D
http://www.bhsc.vic.edu.au/home/lo/google.JPG
type define: before a word :)
chem
Yes yes.. We know :)
btw I've designed a small little (Quick and freakin' dirty) logo.. It's on the 1st post.
and...
I've sent the project leader of Capellan Solution an e-mail asking if we can use stuff they made. I hope they allow us as it will greatly increase speed of the project. (Atleast we can test the game with real mech models instead of little square cubes with bright colors)
and......
Another mail sent to Wizkidsgames.com (Property holder of Battletech). As with Capellan Solution. If they allow us to use the battletech property it will severely increase the project development process.. if not.. well then we have a few things to change so we don't infringe on any intellectual property.
I'm sorry, how is that dirty? That things looke "l337"!
chem
quick and dirty as in the expression that it's been made in less then 30 minutes ;)
Just to let everyone know we now have a FTP server (which is backed up every night) @ ftp://devion.mijnip.nl (user: mwbg , pass: mwbg).
Upped code to FTP:
Quote:
Directory: Source\Game DLL's\MechData_DLL
Author: Devion
Date: 10:22 PM 8/30/2005
Description: MechData contains the class 'clsMech' which is used in-game to hold all the data of the current mech. It's not done yet (Returning Properties of a mech needs to be better for sure.)
Devion - To increase performance, loadtimes will go up, as it generates smaller partions (32x32 or 16x16 instead of 64x64), it must make more partions to fill the map and making each partion means one more iteration through the entire map. That and the overhead of LOD calculations (only when you load the map).
Edit: Im not a DX3D guru. Im a DX2D guru and my 3d knowledge is based on software rendering I used to do. :afrog:
Scince we are using an isometric camera angle, The draw distance does not have to be very far. In the screenshot, I have loaded a 512x512 heightmap, with each pixel bieng a vertex 32 places apart (making the map size 16384x16384), it took 8 seconds to partition it (as a compiled native code exe) and renders with quite good performance. Using a 1024x1024 heightmap took about a min by the clock.
I will now try to implement LOD by using lower res heightmaps.
Edit: I have implemented LOD. At close to medium distances, the partitions are rendered at full detail. At medium to far distances, the partitions are rendered at LOD detail, defined as a constant, to be OriginalDetail/LODDetail. Currently, LODDetail is set to 4. Unfortunately, there are seams between the non-lod and lod partitions so I have to work that out. It only appears then looking around FPS-style, but it will be fine for isometric 3d.
My current constants, about the terrain detail, are
Private Const PartitionSize As Long = 16
Private Const PartitionViewLODDistance As Long = 64 - 16
Private Const PartitionViewDistance As Long = 128 - 32
Private Const PartitionLODSize As Long = 4
Private Const MapScale As Long = 64 'Map horizontal scale
Private Const MapVScale As Long = 4 'Map vertical scale