Printable View
Mmh well the mech look should be looking right in front of the player so I can use it to do damage calculations on it :D (make parts of it yellow/red depending on damage taken) ;)
Edit: Oh.. a skybox would be nice.. you can find one in the /resources/textures/skybox called Rocky_<side>.jpg
Just posted @ turbosquid regarding getting a modeller that's up to the job of creating mechs in a singular format.
http://www.turbosquid.com/Forum/Inde...ThreadID/18272
Heat signature, post-processing with a pixel shader. Nothing special coded for the mechs, just using a dependant texture lookup on a 1D array based on how bright/hot a pixel is.
Got a slight migraine.. no work today... :p
Post-processing implemented on your end?
No.. like I said.. had a migraine.. haven't done anything yesterday.. :/
The heat vision and any other game effects will be done using a render-to-texture with a pixel shader. Some of the other things I have planned, will be done via post-processing...
I will work on the code, and upload it as sept-15, so don't make changes to yesterday's code...
Okay
I have uploaded the code for now, sep 15.
Just don't edit frmMain.GameLoop, I have to finish the HDR lighting pixel shader.
Check. Won't be editing anything for atleast another 5 hours so... :]
Well, if you do edit, please move the terrain loading code to read from a xml, and the positions of the mechs too (modMainMenu is where all that code is now)
Also, 5 hours from now, when you do edit, I will not be around (and the latest code will be on the ftp), so feel free to edit and upload your changes. I will then download them in about 18 hours from now.
Yep, i'll reimplement terrain loading via XML, positioning of mechs (AI Actor classes).. Starting points of mechs.. not sure if we should use static locations and just random position mechs with a certain radius around it so mechs don't get spawned next to eachother.
Also tonight I'll start working on the menu handler again as I didn't do anything yesterday due to the migraine. Might implement the main menu while I'm at it.
So few things for tonight:
- GUI Handler (HUD, Menus) using widgets style XML nodes
- Menu implementation for main menu, maybe loading as well (going to be hard)
- LoadMap from XML
- GetMaps from FS_MAPS dir. (Enum)
- Clean and more implementations inside the Actor class (Low priority)
I'm still here, trying out how to figure out post-processing :)
grmbl.. Trying to look up how to make a GUI Handler framework on google hasn't returned any useful hints at all..
Going to be fun tonight :o
I've got post-processing to work with HDR/Bloom
Look on the main dir of the ftp
I will tone down the effect and upload its code... september 16
mayb exclude HDR for models? :D
HDR is applied to the whole scene, but my blurring filter is all wrong, I will work on that tomorrow. Current version of code on ftp has no hdr...
Blurring filter? Perhaps I could be of assistance?
chem
D3D, I have 2 textures,both 512x512. They are both the same except the 2nd is a blurred version of the first.My current method is to downsample 512,256,128,65,32,16 and then blend them back together but I need to know how to use a Guassian blur or something.
I'm going to try some other methods, then when I'm done, I will upload the code for Devion.
Note, in the ATI drivers control panel, Alternate Pixel Setting for Direct3D must be set to true, if not, the HDR effect is stretched on a top-left to down-right direction, just a note for later...
It appears that there will be no HDR for now, because the effect looks very very out of place...
Okay no prob. Please fix the culling problems as soon as possible :)
-
I'll be working tonight on the plugin handler a bit so it's easier to use; Kinda having a 'slight' user-non-friendliness with it atm.
so instead of comPlugin.ObjectRef("Bla").function etc you'll be able to use comPlugin("Bla").function - it will also be able to raise an error which it can't at the moment (atleast not returnable)
Edit #1: GUI Handler class will be a DLL which can be called upon with comPlugin later on.. No need to register the dll it will be handled at load :)
Oh.. and why doesn't AgrDX have DirectInput support by the way?
Also make sure that the frmMain and such are fairly empty regarding code; Basically everything should be in modules or classes, not forms.
Ps. Most of the ToDo of yesterday will be done today as I didn't get very far yesterday regarding the menu handling class.
AgrDX (Advanced Graphics Renderer for DirectX) has no capabilites other than graphics rendering and some math stuff. I am starting on the culling problems now, when I am done, I will reply here and upload the code.
Culling problems have been fixed, uploading code now
Btw, I got a webdesigner intrested in making the site, more details later (want me to tell him to add you on msn?), but he's pretty good...
Let him send me some examples on my email address of what he did (same email addy as my msn addy).
If we take on a webdesigner he has to be good otherwise I'm doing the web myself.
Right then... he will probably make the site in Flash, like one of those super cool Flash sites you see, you will probably like his samples
Anything else you want me to do in the meantime? :)
Get DirectInput working :)
Whats wrong with our current method?
I could make a DirectInput module, but no advantages I know of...
Faster thus more responsive, ability to run inside a module instead of linking via frmMain, joystick support, better mouse handling, etc.
Like somewhere on Page 1; I wanted a complete 3D engine not bits and pieces. So far AgrDX isn't a 3D engine but a 3D helper module. seeing the amount of code still required to render in frmMain...
Right, well, I'm off to experiment with terrain rendering methods again... :)
Edit: Only editing modTerrainRendering atm, the latest code (unedited ModTerrainRendering) is on the ftp
Using vertex buffers now, fps increase...
Edit #2: Implemented culling vertices, counter clockwise. It has a minimal performance increase for me, but for some other card/driver combos, it should boost fps...
Edit #3: Experimented with quadtrees... Partitions are far simpler to use and there is barely any performance difference... so no quadtrees for now
Okay long post ahead:
I'm been contemplating the idea of creating Mechwarrior Battlegrounds on VB.NET in combination with IRRLicht 3D engine (mostly due to it's support factor and usage of DX9.1.)
With the support factor I mean the API.NET 'MSDN' style web and ability to basically everything that MWBG requires including having a GUI Handler that I wouldn't have to rewrite from scratch.
http://irrlicht.sourceforge.net/images/shots/077.jpg
Just a little cut/paste of the features:
IrrLicht has been mentioned a few times in this thread (page 1) by Nova which at this point I think is a good idea to start actually using it. Considering it's fair incompatiblity with VB6, VB.NET would be a wise option (including the fact that a lot of external COM components would not be required anymore)Code:High performance realtime 3D rendering using Direct3D and OpenGL [more]
Platform independent. Runs on Windows95, 98, NT, 2000, XP and Linux.[more]
Huge built-in and extensible material library with vertex and pixel shader support [more].
Seamless indoor and outdoor mixing through highly customizeable scene mangagment. [more]
Character animation system with skeletal and morph target animation. [more]
Particle effects, billboards, light maps, environment mapping, stencil buffer shadows, and lots of other special effects. [more]
.NET language binding which makes the engine available to all .NET languages like C#, VisualBasic, and Delphi.NET.
Platform and driver independent fast software renderer included. It features z-buffer, gouraud shading, alpha-blending and transparency, fast 2D drawing.
Powerful, customizeable and easy to use 2D GUI System with Buttons, Lists, Edit boxes, ..
2D drawing functions like alpha blending, color key based blitting, font drawing and mixing 3D with 2D graphics.
Clean, easy to understand and well documentated API with lots of examples and tutorials.
Written in pure C++ and totally object orientated.
Direct import of common mesh file formats: Maya (.obj), 3DStudio (.3ds), COLLADA (.dae), DeleD (.dmf), Milkshape (.ms3d), Quake 3 levels (.bsp), Quake2 models (.md2), Microsoft DirectX (.X)... [more]
Direct import of Textures: Windows Bitmap (.bmp), Portable Network Graphics (.png), Adobe Photoshop (.psd), JPEG File Interchange Format (.jpg), Truevision Targa (.tga), ZSoft Painbrush (.pcx)... [more]
Fast and easy collision detection and response.
Optimized fast 3D math and container template libraries.
Directly reading from (compressed) archives. (.zip)
Integrated fast XML parser.
Unicode support for easy localisation.
Works with Microsofts VisualStudio6.0™, VisualStudio.NET 7.0-8.0™, Metrowerks Codewarrior, and Bloodshed Dev-C++ with g++3.2-4.0.
The engine is open source and totally free. You can debug it, fix bugs and even change things you do not like. And you do not have to publish your changes: The engine is licensed under the zlib licence, not the GPL or the LGPL.
Anyway some more copy/paste:
I know this would negate any work done by Cade so far but I feel it's necessary to get things moving in a more direct approach to the end result then to wait for different components to get developed and working flawlessly; Something that will take months before actual completion.Code:Currently supported textures file formats:
Adobe Photoshop (.psd)
JPEG File Interchange Format (.jpg)
Portable Network Graphics (.png)
Truevision Targa (.tga)
Windows Bitmap (.bmp)
Zsoft Paintbrush (.pcx)
Currently supported mesh file formats:
3D Studio meshes (.3ds)
Alias Wavefront Maya (.obj)
Cartography shop 4 (.csm)
COLLADA (.xml, .dae)
DeleD (.dmf)
FSRad oct (.oct)
Microsoft DirectX (.x)
Milkshape (.ms3d)
My3DTools 3 (.my3D)
Pulsar LMTools (.lmts)
Quake 3 levels (.bsp)
Quake 2 models (.md2)
Modelling Support Factor:
Currently there are two types of character animation implemented:
Morph target animation: Meshes are linear interpolated from one frame to the next. This is how it is done in the Quake game series, and how the Irrlicht engine does it when importing .md2 files.
Skeletal animation: A skin is manipulated by animated joints. The Irrlicht Engine will do this when loading .ms3d or .x files. It is easily possible to attach objects to parts of the animated model. It is possible e.g. to attach a weapon to the hand of a model, which will be moved as the hand moves, with only one line of code.
The programmer needs not to know about all this, if he doesn't want to. All he has to do is to load the files into the engine and let it animate and draw them.
I've given this idea some thought over the last few days and I'm getting to the point that I'll have to choose and imho I think the choice is basically set with IrrLicht.
Well, that is entirely up to you...
IrrLicht gives the complete toolkit + SDK, getting an alpha up and running should be done in less then a week basically.. (give or take 2 days to learn IrrLicht's way of work)
Well, if your really sure, but then you dont need any other programmers on the team
Not sure yet; I'll first have to delve deeper into IrrLicht and see what they don't support but is still needed (Physics engine etc) but regarding Engine development.. nope.. Don't think multiple coders are required but still would be useful to have around due to the workload involved.
Well, you can rule me out, I'm don't have VB.net
Sorry dude, but sticking around in VB6 with Agr is going to take months ; Months that could be spent on content development :/
It wont take months, see how far we've come in about 2 weeks, the hardest part of making this must be the terrain renderer and that is now in a stable condition.
Ehh. stable condition? Yesterday I still had culling problems; plus you said there wasn't a chance things like bridges and such could be implemented because the meshes were linked to the terrain and not total mesh.
The 'engine' is at this point 20.. maybe 21% complete. If it takes 2 weeks to do 20%, finishing this would take up a month and a half excluding testing everything. This is excluding the fact that we are at that point using outdated stuff like PS1.4 and imho 10 secs for terrain loading without extra textures and such is a lot.
Then there's the 'problem' of that it's a module and not class-based. There are no events in AgrDX/Terrain load. Creating a loading scene for that is trying to bash open a coconut with your forehead.. It's doable but it's painful and takes a long time.
Actually, they can be implemented, just we need to use a standard mesh format...
It is possible to do bridges, just I have no bridge mesh to test with.
Events can be added easily, and culling problems were because I wrote a very simple frustum culling system and fixed 95% of the culling issues in about 5 mins today and uploaded. 10 secs is to generate a vertex mesh from a heightmap, we can cache that...
Right, well nvm... guess you really are going to use IrrLicht
Yep going to use IrrLicht as I can get things working pretty quickly.
Status update #1::
After fiddling with Irrlicht for about an hour now I finally got the hang of how it's classes work.. So far I got it to init.. now it's onto getting the terrain renderer loaded up and such.. (after checking out how the texturepool works)
Status update ::
I got it to render.. working out 'small' details now like why the textures aren't resizing in the GUI and why the ISceneNode is a pain in the behind :)
It works! Terrain rendering with detail texture.. (do note that little (really little) FPS counter in the top left corner..)
What problems are you having with ISceneNode? No doubt conversions of vectors and such. There was a little hack I was told a while ago that converted the vectors of an IAnimatedSceneNode into a type of vector of an ISceneNode. I can't remember exactly, but yeah.
Nice work.
chem
So far I've run into a few lovely problems:
- GUI Images... 1024x768 don't get resized to the current resolution (ie. 800x600)
(Same occurs with Draw2DImage)
- Getting a mesh to animate and move in the right direction
- Getting the isometric camera to actually work and not screw up the camera completely.. (grr)
Well atleast I got the terrain up and and a mesh ;)
Updating main code so it actually all belongs where it should (it's kinda a mess at the moment)
Cleaned up most code and working on a progressbar which works except that I have no freaking clue how to resize textures (having a 800px progressbar on 800x600 screws it up ;))
The problem... and a small 'annoyance'.. the textures seem crippled a bit on the 'texture quality' though that's probably easily fixed if I know what to set ;)
Source upped to /Source on FTP. Shows off the new loading progress if you start it.. (Now I just need to find out how to resize the sceen ;))
Solved resolution problem by adding new semi-hardcoded variable called %Screenwidth% which can be used when loading textures.. (ie. LoadTextureNoMip("C:\Bla_%screenwidth%.jpg"); would load C:\Bla_1024.jpg or 800 etc.
About that skybox, my advice is that u create a sphere and apply a cloudy texture to it and then continiously rotate it a small amount on the x-axis this will firstly make your sky look like a real sky than a box and the movement will make the clouds look like they are moving! Believe me it works wonders!
Thanks, I'll try to implement that :)
Just noticed u guys r using irrlicht. Well for physics engine my advice would be to use the newton physics engine, it is used by many other people on the irrlicht forums and its also free secondly there are tutorials available which tell u how to implement newton engine with irrlicht engine.
Yep, been reading about newton on the Irrlicht forums, looks a bit of a pain to implement but solves a lot of problems ;)
Personally, I don't think the newton engine is the best, especially not for a Mechwarrior game. Theres another one I'd seen a while back. It isn't all that complicated to use either, and its not as bulky and hard to implement as Newton.
chem
Well if u can state its name it can be helpful for a lot of people u know!