Paul Thomas

You going to tackle this, Tyler?

Ok

I can give this a shot tomorrow.

I would have went with C# if it was more supported back when I started learning LE. I was introduced into BlitzMax because of that though. BlitzMax is a great way to program quickly, but I just wish it had some of the features I like with the C language, like overloading. I would love overloading with BMax.

All games will have a loading portion. Fallout 3 doesn't have terrain loading, but most of it is loading each structure/underground portion of the game, much more loading than Far Cry 2. Fallout 3 sacrificed terrain loading with structure/underground loading, and if you ask me, way more loading screens as apposed to a loading screen to load another 4096x4096 terrain. Depending on how your map is designed, it could take a player a long time to reach that point. Far Cry 2 requires no loading when entering a building and only has a single loading portion when traveling far south passed the first terrains size limit. Fit the engine into your project or find another engine and/or make your own. Josh isn't blurting out sentences just to go against you, he's telling you that it basically requires another engine built for that specific need, and has no plans to change this engine drastically to fit that need.

Framewerk definitely makes things easier. I grab the source of Renderer, start reprogramming it, and build upon it for additional post-processing effects, and recently the addition of my clouds. Not to mention, if you poke around in Framewerk often, you'll eventually have a greater grasp at how the engine works with rendering and so forth.

Yup, there seems to always be a trade-off in the world of game development, lol. I believe Fallout 3 used 512x512 terrain cells. I wanted to go their route but like you said, distant terrain looked fairly horrible, and figured I'd just use very large 4096x4096 terrain or so. Force terrain loading but at such large terrains it wouldn't be very often. I see a lot of trail and error in the future when I get to this portion of my project, lol.

Fallout 3 required loading when going into any structure or subway station. Far Cry 2 does a load map when you eventually venture further south after you finish the first missions for the factions. You'd have to load going into that area and load leaving that area, they just tend to keep all the missions within that specific loaded area, but you could venture back if you wanted to. I've never played World of Warcraft, but I thought I've seen loading screens once you get a certain distance and have to load the next block of terrain. I could be wrong, but like I said, I've never played World of Warcraft; I've seen people play it but never payed much attention to it. My project requires terrain similar to Fallout 3, but I also don't want to have the player load each interior, and it defeats some of the proposed features of the game. Therefore, I'm going with terrain loading instead of interior loading, and most likely will use a strict set of heightmaps to ensure the terrains are seamless. I have yet to get to that portion of my project but it's something that's always on my mind.

You'd have to make your own LoadScene() as a start. I'm not sure how to communicate with the engine for the vegetation data though, it doesn't seem to be exposed, or at least not documented to know how to use the functions.

Would be nice to assign material files instead of just dds textures. If the editor was changed around to do that it could easily raise the limit to ten (or more) by assigning two texture files and using a blending value. 0.0 would be texture 1, 0.5 would be a blend of both, 1.0 would be texture 2. Just some ideas. I'd experiment such a thing but I need the sandbox source or to finish mine, lol. Edit: Not to mention additional effects, like parallax.

Reminds me that I need to do my stars as well. I'll let you know what I come up with.

I better do that then, did a clean install the last time, but I'll do it again. Thanks mack.

Hey mack, yeah just been programming a lot, lol. Yeah, I did the sync then, and recently (to make sure I have everything updated). Still had the same mistake I had found that last time.

The current framewerk with version 2.28 has two mistakes I've found. One completely stops HDR from being enabled, and the other I haven't tested which is for SSAO. For HDR, line 680: blurbuffer[1].colorbuffer[1].Clamp() Should be: blurbuffer[1].colorbuffer[0].Clamp() For SSAO, line 747: TextureFilter(gbuffer.colorbuffer[0],TEXTUREFILTER_SMOOTH) Should be: TextureFilter(gbuffer.colorbuffer[0],TEXFILTER_SMOOTH) You'll have to include/import framewerk or build the module after the corrections.