Capellan Conflict Development

Quote:

---

Im not a DX3D guru. Im a DX2D guru and my 3d knowledge is based on software rendering I used to do

---

Changed. :)

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).

---

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:

---

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.

---

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:

---

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.

---

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.

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:

For etc etc
     If bla bla then
           For etc etc 
                Code code
           next
     End if 
Next

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

I'll do that when I get home, I'm gonna try and make the main menu prolly using the agrDX engine as I need to get familiar with DX. My ToDo list is growing by the minute :)

In the meantime, anything you want me to do?

Mmh, fix the rendering engine as a .mod instead of in the main form so I can easily implement it in the base application? :)

And feel free to fiddle around with the md2_class I've upped to the ftp,

Models can be easily downloaded from Polycount.com (http://www.planetquake.com/polycount....asp?model=386) though Md2 will prolly only be used for simple objects (though we could use .X for that also) - Simple objects like trees, boxes, etc btw :)

I will attempt to work on the md2 class. Would you also like stencil shadow support for md2 files? :D

yes please :D

Project update-We have currently decided to use .x files instead of md2 files, for the time bieng.

My ToDo - Starting tonight.
---------------------------------------------
Main:
* Start for the app base for the game including but limited to: Initialisation of the application, configuration/setup, implementing helper classes.

Implements:
* Graphics handler using agrDX Texturepool and lookup tables.
* Script engine for external setup of information.
* StateHelper for easy setup of different states within the gameloop (think of: Ingame, Menu, Quiting, etc)
* Menu/Widget handler for graphics GUI's based upon XML data containing locations (grid-based locations so multiple resolutions actually work)

Mutates/Conversions:
* Mutate agrDX to support game logging and error handling.
* Mutate terrain render mod to support also the game logging and error handling.

Estimated time for completion: A few days hopefully.

----------------------------

ToDo's for those that want it: (We won't get bored)

* MD3 Loader class based upon the agrDX DirectX implementation (!)
* A* Pathfinding implementation based upon the Terrain renderer code. (!)
* Sound Engine based upon the agrDX DirectX implementation (?)
* Easy map editor using the agrDX/Terrain renderer code. (?)
* Network Protocol (!1)
* Network handler(!1)
* Server code to handle clients for the game (!)(?1)
* AI Module based upon GameLogic/Terrain Renderer (?)

(!) = Priority (?) = Not sure yet, might change overtime. (?1) = First Priority yet no real priority as it depends on other things first.

AgrDX, the A is capital. Also, Devion, download the DX 8.1 SDK and take a look,you might find it useful/intresting.

I will be back in about... 12 hours. :wave:

That menu screen looks bloody amazing. I thought for a second that it was one from a retail version of MW. Very impressive.

Thnx :)
It's not based upon any MW screen so far that I know.. well I took a peek at one but it was at a resolution of 320x200.. so I had to create my own stuff.. takes a few minutes longer but the end result is the same..

Though I'm hoping we can do an animation on the background instead of a still picture of a mech (Btw, the background is ripped from a screenshot ;))

Main Base code has been uploaded in Source\MWBG_Main
(Make sure you regsvr32 the common dll otherwise it aint gonna work ;))

Take a look at the script in the Configuration directory (I'll make some documentation regarding the script engine later), the Resources directory is the directory where data should be stored.

Haven't implemented AgrDX yet as there are some minor issues with the code :P

I've mentioned before, I can't do anything until I get my own PC. That will either be tomorrow (oh god I hope so), or sometime next weekend.

But yes, I can work on a few pathfinding things (haven't done 3D stuff in a while, not since my Half-Life bot programming days). I should be able to get something up.

Also, I have assignments to get out of the way. Mostly web related, so I must make those my top priority aswell :eek:

chem

No prob, gimme a yell when you got free time and are motivated to do some pathfindin' ;)

I'm going to work on the Terrain Engine a bit more, I think I can get it faster... ;)

Mind uploading the source to common.dll? :ehh:

Edit: Got loading times boosted about 3 times faster and a minor increase in fps.

Common.dll comin' up.

Edit: Uploaded to \Source\Common

Thanks :)
What main model format will we use? MD3?

I'm not sure yet, MD3 is a pain in the ass model structure, if I can get my hands on some decent specs I might be able to code a class for it but it also requires a modeller that can actually export a model to MD3 and make it all work.

ChemicalNova, can you do pathfinding if I just pass you a list of X,Y,Z coordinates of all the points the map consists of?

I've decided it's better to use an available engine at this point due to several problems that are going to lie just around the corner (Model support being one).

So I spent the friday evening getting the Main base app working with NemoX which at this point works (yay!)

Source of Main app with Nemo and a few textures and configuration and such is upped at Source\MWBG_Main\MWBG_Main_922005_Using_NEMO.rar

Anyway, attached is a screenshot of how it looks, still fiddling with the skybox though, too far and it starts showing black streaks through the skybox.

Anyway #2: NemoX is probably gonna stay as it supports basically everything that we will ever need (Including physics engine.. well carPhysics ;))

Small addendum for those downloading the main app code:

Register NemoX DLL + TLB (well Atleast keep it where it should be)
Register Common DLL

App.path & \Configuration contains 2 files that are interesting to look at... first one:

autoexec.cfg - Script startup, contains a few important things like variables that are being set (and used!)

Settings.ini - Can be deleted, will be auto-generated as soon as the app starts again. Contains a few settings you can mess with :)

Next in line: resources\maps\

Contains only Rocky.xml which is a XML document containing information on where it can load it's map info. This XML will be bigger at the end containing spawn points and so on and on.