Josh

That's strange. Maybe the entity view distance is set to a low number?

Here are some of my thoughts on how a future engine might look. I am not devoting any time to this, and it would not come to exist for several years, but it's fun to think about technology and design: I've been fascinated with the game "Fuel". This game has an enormous playable area that is streamed from the hard drive. You can drive for hours and barely cover a fraction of the map. For some reason the game has been given bad reviews. I played Motorstorm on the PS3, and I think Fuel is a lot better than that game, not even considering the impressive technical features. Anyways, I love the large open world. Fully dynamic lighting was one holy grail of game development, and I think a continuous open world is another. I would start this with a concept of "regions". Each region is a square on the grid, perhaps 1024x1024 units. The region has a terrain heightmap, terrain normal map, and an SBX file for all entities in the region. As you move around the world, regions are loaded from the hard drive in a square of playable area around you. Maybe there are 16 regions active at any given time. This number should be adjustable. Only physics and scripts of the entities within this active region are updated. When a region goes out of the playable area, it is saved to a file, and this new file is loaded if that region re-enters the playable area. So you aren't going to have enemies fighting and moving around when they are a million miles away. The engine just updates the regions nearby, because it would be simply impossible to update millions of entities. The AI in STALKER actually uses a technique similar to this, and I think they originally were planning on a huge continuous world but weren't able to pull it off. Each region can be culled on a separate thread, so this design lends itself to multithreading. So far what I have described is a big challenge, but it seems feasible. The real nightmare begins when we talk about networking. If your friend walks ten miles away and interacts with a person who's attitude towards you changes based on the interaction, well the server needs to be running two simulations. One simulation is for you and everything around you. The other simulation is for your friend and everything around them. What your friend does will change the world outside your playable area, so that when you enter that region it will be different than when you left. Now consider physics. Due to the massive distances, there would need to be two separate physics simulations running. Then they would need to be merged together when you approached each other. Wow, no wonder no one has done this yet! Fuel has a multiplayer mode, but it's just a racing game. Your actions don't have any permanent consequences on the world around you. An FPS, adventure, or RPG game will be quite different. I'm not even sure this is technically possible, without severe restrictions in flexibility. Fortunately, real-time rendering is not going to change much in the next ten years. We'll be able to do more as hardware advances, but I think we'll still be using the same basic techniques for a long time. That means that every feature and technique we add now will still be useful for a long time, even in a new engine.

Transform the point from local to global space.

If you want an AABB you can also make a mesh that represents that shape. If we had a model-less entity you drag into the scene, it creates some design problems. Let's say the entity is an emitter. Where does the class script come from? Does script support have to be added to the base entity class, instead of just the model? If so, how does the script delete whatever entity it starts with, and replace it with an emitter, using the same script? What if the emitter is deleted and recreated, as happens when the particle count changes?

I don't see much point in this because the attempts at implementing other physics libraries have not gone very far.

No, it's not, but alpha masking with antialias doesn't have any of the z-order issues alpha blending has. I think alpha blending was more appropriate when texture resolutions were lower. With higher resolution textures I don't think alpha-blending of leaves and things like that is as useful.

Because in LE a model is the only scripted entity, so a model and a script allow you to create any kind of object you want. Particle emitters, lights, roads, etc., can all be implemented using this convention. If you want to get rid of the extra model when your game loads it, this is pretty simple to do. It shouldn't make any difference though, since the model is invisible and normally will have no collision set. If you want to make the model so it isn't even pickable, replace it with a GMF file that has no surfaces...then you would only be able to select the object by clicking on its node in the objects tree in the side panel.

All orders are processed. Thank you.

This thread is marred. Feel free to try again in a more polite manner.

If you just save the script every instance in the scene will be freed (with the old script) and reloaded (with the new script). You should not run a class script.

Probably not.

The reason these entities are linked to a model is because a model has a script, and can be moved around and deleted again. This allows you to make lights, particle emitters, or anything else in script, and the editor doesn't have to have everything hard-coded. If you want to get rid of the model component in your own game loading routine, you can just modify the script to remove the model when your game loads the scene. Something like this: if MyGameIsRunning==1 then object.light:SetParent(nil,1) object.light=nil object.model:Free() end

This indicates the modelreference value equals nil.

See attached. Arial9.zip

Add a call to GCCollect() in your main loop. I don't recommend using the auto GC mode because it is possible for it to cause crashes. The problem is object Delete() methods might be called at any time, and in the case of OpenGL or Newton objects, it might cause the program to delete these things during a sensitive routine when they are being used. It might do something like delete an OpenGL buffer while another buffer is being set, and it is possible this might cause a crash in some situations. In the future I will add the deleted objects to a queue to be deleted during the UpdateWorld() routine, so they will be more safe in auto GC mode, instead of deleting them in the Object Delete() method.

The reason I ask for a demo of your problem is because I suspect you either have some very unoptimal physics shapes or you are using a high value for the update iterations for the controller. Or there may be some other problem. It doesn't make sense for someone else to try to guess and recreate your program. It's much more efficient to see what you are doing and then see if there are any problems.

Well, we're clearly not in the real world of programming, and I guess this engine is not on an equal plane to other engines on the market today.

There's a crazy sale on Steam right now. If you haven't played STALKER yet, you can get it for $10: http://store.steampo...check/app/4500/ In other news... Framework is being compiled into the engine DLL and being made an official part of the engine API. It will remain a separate piece of code for BlitzMax programmers they can just import. A mechanism will be added to add your own custom post-processing effects, though this will not be available immediately. It will be something like this: CreateEffect( callback ) EnableEffect() DisableEffect() FreeEffect( effect ) If you prefer to use the existing C++ code you are free to do so. However, the integrated framework code will allow Lua to access the Framework commands, so your scenes will work seamlessly between the editor and any programming language you choose. The whole design of our buffer/shader system and framework makes a heck of a lot of sense now. It just had to be allowed to evolve so we could determine the best solution. You've got an the easy-to-use framework commands, but still have the low-level buffer and shader stuff which can be used to do many things. The Lua command set is also slowly being exposed. At first, it will just have the bare minimum commands you need to set the variable "fw" to the framework object you create in your program. In time the entire Lua API will be exposed through the DLL. This will allow limitless extensibility for whatever you want to do with Lua. You can expose your own C++ or other functions and classes, or do whatever you want.

I think for nighttime scenes a somewhat desaturated dark blue is good for ambient light, and a white slightly blue light is good for moonlight, with the intensity set pretty low. Unless you want it to be dark for a reason, don't make it too dark. Rely on the blue tint and keep it bright enough to see. You'll notice this technique used in movies a lot.

There may be some fixes for 2.28 but there's lots of other stuff I need to do first.

Well, I don't think you are giving away any valuable secrets in this thread. I just moved it because it seemed like an editor question. There should still be some discussion in the general forum because then the existing users will still go there and it doesn't become silent. And it also gives people a glimpse at how the community interacts, and how people go about making a game. Now if an unknown user starts asking programming questions in the general forum, that's when I become suspicious, but those cases are pretty obvious.

You actually can get antialiasing right now, and not the edge antialias shader. Just render to a double-size buffer, then draw this onto a buffer half that size, with the smooth texture filter set. This will produce about the same results as 2x MSAA. I don't recommend using this technique for anything you release, because the bandwidth usage would be ridiculous, but its okay for testing.

The space limit is raised. Please use better compression for your images.

Can you post a demo showing how 20 character controllers are slow?

I think you will get the most bang for your time with Lua.