Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / K96 - Terrain Manager

Author
Message
Sigh
18
Years of Service
User Offline
Joined: 26th Dec 2005
Location: The Big 80s
Posted: 25th Nov 2006 22:48
Ive been working on the terrain manager for my project K96 since yesterday. So far its coming along great - just some minor issues that Im sure are going to be relatively easy to fix.
</p>
So, here are some screenshots of the terrain manager working:
</p>
</p>
[img]"http://ixeelectronics.com/K96/TestTerrainA.png"[/img]
[img]"http://ixeelectronics.com/K96/TestTerrainB.png"[/img]
</p>
[img]"http://ixeelectronics.com/K96/TestTerrainC.PNG"[/img]
</p>
[img]"http://ixeelectronics.com/K96/TestTerrainD.PNG"[/img]
</p>
[img]"http://ixeelectronics.com/K96/TestTerrainE.PNG"[/img]
</p>
</p>
As you can tell, right now there is no terrain texturing or other "niceties". Since K96 is a proof-of-concept version of a larger project I'm debating whether to even bother with texturing; besides I kind of like it as-is because it reminds me of fun times I had playing games similar to K96 way back.
</p>
Now for a little info about the terrain manager....
</p>
It doesn't use matrix functions because Im not satisfied with those at all. It uses prebuilt (or runtime generated if one wants) terrain objects to construct the terrain.
As you can see there is also a sky, planet, and stars. The sky is made by using a modified sky"sphere" and doing some tricky math to make it work. The "star" planes are projected onto the skysphere from several calculations to convert their real coordinates to skysphere coordinates, then rotated and positioned onto it. The planet is still something Im trying to work out how best to implement. Currently it is just a large textured sphere positioned at the edge of the skysphere. But this leads to several problems that make it look odd at times. I have a few fixes in mind and will be trying them in the coming days.
</p>
The clouds I cant take credit for, I got the code to generate them from the forums/codebase. I will be changing it however, as I am not very pleased with them for a final product.
</p>
Anyway, thats all for now, leave any comments or questions if you like, and thanks for reading!

The Great Nateholio
<img src="http://ixeelectronics.com/Nateholio/Pictures/Sigblock.PNG">
Crazy Programmer
AGK Developer
20
Years of Service
User Offline
Joined: 6th Sep 2004
Location: Lost in AGK
Posted: 26th Nov 2006 00:19
Not to bad...cant wait till the finished product comes out.


Load Programmer "Crazy Programmer",1
Programmer Dave
21
Years of Service
User Offline
Joined: 25th May 2003
Location: Australia
Posted: 26th Nov 2006 00:58
That's pretty neat

Sigh
18
Years of Service
User Offline
Joined: 26th Dec 2005
Location: The Big 80s
Posted: 8th Dec 2006 17:15
Just another screenshot of terrain with trees this time.

I spent about a week reorganizing the code into functional blocks, so progress has been a little slow.



As you can see, LOD hasn't been implemented yet so the engine stops drawing trees not too far in the distance, about 750ft.

The next important things I'll be working on are LOD and terrain/plant/scrounge placement so things don't end up on top of each other sometimes.

The following is just to show how things are loaded into the engine, and how easy it can be to manage objects using names rather than object numbers.



When a request to load a resource such as a texture or mesh(object) is received by the various managers, they check to see if that particular file has already been loaded. If it has its just assigned a new number and cloned (in the case of objects). Otherwise its loaded from disk. After that its assigned the name specified by the "load" command. No two resources can have the same name, as this is the way resources are normally referenced by other processes. Resources also are grouped into classes for tasks such as collision checking, placement checking, etc. For example, "Foliage" would be a class, "Tree" a subclass, and "Scrub Pine C" the name of a particular object.

The reason for classes and subclasses is to allow easy parameter checking. The following illustrates this:



The line "Name$ = NearestMeshClass("Terrain", X#, Y#, Z#, "", "", "")" returns the name of the nearest mesh to the given x, y, z coordinates. A class can also be specified, which is "Terrain" in this case, so it will return the name of the nearest terrain feature. Also notice the three empty strings at the end of the line. They are used to exclude up to three different named objects from the check for other functions such as object placement calculations.

The Great Nateholio
<img src="http://ixeelectronics.com/Nateholio/Pictures/Sigblock.PNG">
Chris Franklin
19
Years of Service
User Offline
Joined: 2nd Aug 2005
Location: UK
Posted: 8th Dec 2006 17:19 Edited at: 8th Dec 2006 17:20
Great work , what's the terrain made in?

Edit:
In case you coudn't tell the last bit about what was the terrain made in was a joke hence the

Sigh
18
Years of Service
User Offline
Joined: 26th Dec 2005
Location: The Big 80s
Posted: 8th Dec 2006 17:57
Yeah, I knew it was a joke, but since you brought it up, each terrain feature is made in Milkshape 3D and exported to X format with Ultimate Unwrap3D.

Here's a shot of the trees in MS3D:



I didn't make the trees, but I am in the process of modifying them for my needs. I frequent GarageGames more than I do TGC, and I've worked with several individuals there to license and/or contract content out. The link to the trees, and how to buy a license to use them follows:

http://www.matthewcjones.com/Tree/Tree.html

The Great Nateholio
<img src="http://ixeelectronics.com/Nateholio/Pictures/Sigblock.PNG">
Nateholio
18
Years of Service
User Offline
Joined: 30th Dec 2005
Location: I\'ve Been Everywhere
Posted: 15th Dec 2006 05:08
In my attempt to start and keep a habit of posting at least once every seven days (time and work permitting) I'll go ahead and post today, with a screenshot. I think that if I include a screenshot it will give me a little motivation to make good progress so they all dont look the same.

This week's progress was ok, I could have done a lot more, but alert keeps you busy sometimes. Im pretty sure that over the past seven days I spent about 16-20 hours on the jet each day troubleshooting equipment, putting officer's heads back on straight, and doing general management activities for what amounts to a nationwide DOD telecom network, network manager for a 100-ish user network, and a crapload of other electronics stuff. And of course, there is the leadership and mentoring of a bunch of Airmen. All of this done in-flight and between flights. I think it was one of the busiest weeks Ive had since Sep. 11, 2001. Along with all this I've decided that I need to take a different attitude, a positive one, so I dont have a stroke in an internal anger fit over equipment or Airmen. A positive attitude also has the benefit of helping one treat others better, developing leadership, and developing leaders around you (Just another thing my dad told me and I ignored until now, lol). So In my posts I'll be thinking of things in a positive manner, even if not much was positive.

After a jeer of sorts in IRC about not having anything but trees and terrain, I decided to start making other parts of the engine such as the HUD. I had a comment from someone in IRC about not having enemies and such, granted its boring not to have them, but Im not to that point yet. So now I have a digital compass readout top-center and a circular radar display top-left. The compass works perfectly, but the radar sits there as there is nothing for it to track in the level yet, and no code to control tracking even if there were objects. Next things on the HUD to do - elevation bar, targeting recticle(s), weapons status display, targeting window, speed/temperature/time/etc readouts, and a damage display. Some of these will depend on other functions and objects being loaded, but I can at least make the display portions for now. Besides, doing my HUD now will allow for more critique as I post screenshots, so I can change things around to get HUDs more user friendly.

Now for the (note to self: think positive, not witty) screenshot:



So as you can see, nothing has changed overall except for a compass and radar up top. Some of you may recognize these as being very very similar to other games of olde, but I like them because they are simple and informative. The compass still needs the digital number readout below the bar readout, but the compass itself works fine.




The compass works by taking the heading of the player and converting it to a measurement of how many pixels it is equal to in reference to a set standard, i.e. the above image. It then chooses the proper row to grab the angle image from, and grabs a 256 pixel wide area which centers on the desired angle. Originally I was going to just have the angle readout, no black background or frame, but it proved hard to read under certain conditions.

My plans are to make an altimeter in the middle-left similar to the compass readout, weapons display/status in the upper-right, turret/torso "angle-from-center" indicator above the compass and a similar one for aim/target elevation next to the altimeter, a damage displayin the lower-right, a targeting display lower-left, and systems status lower-middle.

<iframe src="http://www.greatgamesexperiment.com/greatgamesbadge/user/TheGreatNateholio/" height="140" width="204" scrolling="no" frameBorder="0"></iframe>

<iframe src="http://www.greatgamesexperiment.com/greatgamesbadge/K96/" height="140" width="204" scrolling="no" frameBorder="0"></iframe>

Login to post a reply

Server time is: 2024-11-23 21:43:06
Your offset time is: 2024-11-23 21:43:06