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
Changed. :)Quote:
Im not a DX3D guru. Im a DX2D guru and my 3d knowledge is based on software rendering I used to do
Maybe make a lookup cache for the maps that contain such data? I know this won't work for the LOD calcs as they are dynamic but the partition data is rather static. Only if the player would change display settings would it have to rebuild right?Quote:
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).
8 seconds isn't too bad for compiled code - 1 minute is slow though, then again maybe it's possible to cache the data for future loads though a 1024x1024 heightmap might be a bit overkill anyway :)Quote:
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.
Aye, as the LOD'ed area would only been seen on higher areas on the map when facing more of the map then when the camera is on lower terrain. I don't expect any problems with that. Though I do notice a repetitive tiling on the map but I assume that's just the texture.Quote:
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.
The fps on the renders.. is that average or incidental? :)
Ps.
Will the terrain render engine also include mouse location lookups? (DInput basically)
Change it to Rendering expert! :wave:
Forget the part about load times, it only seems slow in the IDE, quite fast (8 secs) when compiled.
Repititive tiling, thats just the texture.
I am using FPS style controls right now (wasd+mouse), with Q and E to go up/down, using the Win32API GetCursorPos/SetCursorPos.
As for right now, I am trying to improve the fps even more. The fps in the screenshots, is averange, not incidental. ;)
Just put up a request for an extra VB DX coder so we can speed things up on the engine part. (http://www.vbforums.com/showthread.php?t=358024).
Under the circumstance that no VB coder wants to join I'll be starting tonight to work on a MD3 Loader class to be able to render models in the engine.
w0rd.
It looks soo much better without the grassy skybox :)
And with the shadows ;)
Benched the renderer a bit, on average I get about 400+ FPS, I've changed the grass texture to a high-res version of grass (1024x1024) but I kinda noticed that the Texture LOD is kinda extreme isn't it? :)
Grr... getting specs of MD3 is a pain let alone that someone open sourced it for us ;)
Anyway, found a MD2 class on PSC which can be used. It's on the FTP under Source\MD2_Class
As soon as I get my hands on some decent MD3 specs I'll write my own loader.
Fiddling with photoshop Part II :: The main menu mock-up :)
Edit: Attachment didn't work properly it seems.. :p
http://devion.mijnip.nl/MainMenu_Mock.jpg
I do bielieve that at 400+ fps, the fps counter is stuffed. :eek:
Mind testing your fps with 50 partitions instead of 17? ;)
The textures are bieng rendered at 1x Anisotropy, no LOD. If you send me the grass texture, I can test out using higher levels of texture filtering.
at 50 partitions it's around 410, sometimes 400 :)
I'll send the grass texture as soon as I'm home.. (which will be in 8.3 hours :P), though you can get it from http://www.turbosquid.com/FullPrevie....cfm/ID/226334
Your fps... :eek2:
Mind uploading the texture to the ftp?
Upped -> Resources (Not Source)/Images_Devion/Grass.jpg (1024x1024 High res Grass image in JPG 0% compression)
I found a bug in the camera, in the code to cull hidden surfaces. It caused crashes in rare cases, so if it crashes with an Overflow error, I've already fixed that.
Edit: I'm working on the lighting now, btw
Kewl.
I'll prolly start working with the agrDX mod tonight implementing the Md2 class, script engine and prolly implement a menu handling class (see main menu mock up pic).
chemicalNova - You care of doing the AI class (If you haven't already started it) together with A* Pathfinding?
Besides that; Cade.. think you could upload the current version of the terrain engine source so I can look around at it a bit? :)
Download the AgrDX tutorials from my site. Tutorial 8 includes the latest released & stable (all functions work) version of AgrDX. When you unzip and load the source code, it will also need AgrDX.bas
Uploaded source to /Source/Terrain Rendering Engine/OutdoorRendering.zip
Caution, read at your own risk. I am not responsible for any medical conditions which may arise as you try to decipher the code. Because half the time I was writing it, my mental image looked like :afrog: .
Lol, I'll prepare myself mentally before looking at your code... Though if it's that bad I'll prolly take the time to actually make it all look decent.. (like Tab Idents, decent variable-declarations and prolly able to run in a class as well, as that will make things easier later on..)
Edit...
I looked! Aargh! I looked.. and that was just the form code that I looked at...
Good code yet terrible chaotic.. use tabs, indent for loops, if loops etc.
Like this:
VB Code:
I don't use tabs, Im used to typing asm style code, and I can understand code like that much more easily than most people. Also, my mental strain was mostly because it was my first time making a massive outdoor terrain renderer, not due to code. :duck:
Dont class-base the rendering code, put it in the main exe in the rendering loop.
Oh, and dont worry, AgrDX is much cleaner and more organised. :D
VB != Asm , most asm statements are short.. VB statements can be pretty long and confusing if it's not offsetted.
The rendering engine can be mod-based, logging and such will be classed based. I'll prolly rip apart my own common-dll (which contains 16 classes including mysql, logging, variable handler, script engine, crypto-methods, DLL Plugin manager, etc etc and put those as classes in the main app.
Though some stuff like the game loop handler will be DLL's as they are easier to update and don't require recompiling the main app. (Using late-binding of the DLL and auto registering them just before binding so that users don't need to register themselves)
Anyway; I'll prolly start a base of the game today and fiddling with agrDX ;)
Asm may be different, but that is what I think in, for some reason.
Take a look at all the AgrDX tutorials, starting from 1.
Direct Link