Rick

Yeah, if you are doing this in a Thingoid, I think you have to remove the flip hook.

As another option, not to steal business away from Whisper, you can check out RakNet. They have a plugin that does just this also.

WOW!

Can you show us without this technique on the same model to show the difference it makes?

I have an account with that, but can't access it from work. They are picky like that.

Nice. That's what I'm looking for. Thanks.

Good ideas. I'll do that. The old forum just let me send messages to myself and thought that was kind of nice.

I'm so cool that I can do both

Because I often write up code in notepad at work and want to send myself the code. I don't wish to send it via my works email.

Is there a way for me to send private messages to myself?

lua is a scripting language that allows you to basically create your own library with it. So each engines implementation of the functions they created in lua to use in lua will be different.

Where did you get this script? It doesn't even look like any LE comamnds.

That camera pick I posted was what I do on the terrain. It's how I select where I want a unit to move to. I have version 2.31. The below code is what gets called every frame TPick p; p.entity = 0; CameraPick(&p, camera, Vec3(MouseX(), MouseY(), 5000), 0, 1); // we only care about the terrain string cls = ""; if(p.entity != 0) cls = GetEntityKey(p.entity, "classname", ""); if(cls == "Terrain") { ShowEntity(GetAoECursor()->GetPlane()); PositionEntity(GetAoECursor()->GetPlane(), Vec3(p.X - 10, p.Y, p.Z - 10)); // -10 is 1/2 the scale of the plane GetAoECursor()->Update(); }

This sounds like if they actually accept you, you'll have to go to LA in July. I wouldn't be able to make that trip

How far is your z component of the CameraPick? I would imagine the higher that distance the slower it would be. I have a CameraPick() every iteration of the game loop using CameraPick(&p, camera, Vec3(MouseX(), MouseY(), 5000)); and I don't see any drops in my frame rate.

Well, he could not have LOD's and just have the 1 mesh. Sure it'll add polys but he won't have this issue.

Use reliable connected UDP (it's a layer over UDP that makes it reliable and handles keeping it connected for you and still faster than TCP). RakNet has this already built in and I've used it and love it.

Yeah I wouldn't write a ProcessScene for the models like I originally thought. I would take 1 model out at a time from the original sbx file and put it into a temp file, then just call LoadScene() on that file. Do that for every single model in the original sbx file so LoadScene() still does the work of ProcessScene() and all that stuff. So really the code would just parse out the original sbx file into a temp sbx file 1 model at a time. Pretty easy.

It's obviously more that that, because the drawing code would need to be done in openGL, since LE commands don't play nice with multithreading. So now a person needs to know openGL which is more code than using LE. Also you assume just drawing lines on the screen is what people want. Most games will display an image and the progress bar on top of that. So now you have to load a texture and draw it all with openGL. If you are going to ignore that fact, then I'll ignore the fact that once this new LoadScene() is written it's equally the same amount of code for someone using it. Define a callback function, and draw your rectangle in it. Done.

The problem is you can't do that with how LoadScene() works today because it's blocking. That's what we are trying to solve. LoadScene() loads everything and you can't update anything like a progress bar even if you are faking it until it comes back and at that point everything is loaded already. You could that with anything you load in code though, yeah. Your approach would require multithreading to work. That takes code. LoadScene() doesn't come back until everything is loaded and currently you can't do anything while LoadScene() is being called. So for your approach to work you either have to have multithreading to make a progress bar move while LoadScene() is being called, OR parse out the sbx file. If you are spending the time to parse out the sbx file then you already have the information to make it 100% accurate because you'll know how many models you have to load and the information to load them manually.

I like that idea even better, because I only need to call the terrain hugging code once after the plane is scaled instead of each frame as it's being scaled. That'll speed things up a ton. I'll test that shader you wrote on this tonight and let you know how it goes. I'm excited for this because it's the last piece to this kick wonderful person ability

You've seen the list of wants from us. This would most likely be put low on Josh's list. Aka, would never get put in. Yep you could do that also. This would just be a more accurate representation if someone wanted that.

If he reads the sbx file maually and loads those models like you did, but then calls LoadScene() on the same sbx file (with it still having all the models in it), it'll load them again which would be the delay. It should be a slightly less delay but a delay non the less. [quote Well my Hydro test scene loads in a few secs .. and it has far more than 0-1 models lol Maybe your CPU is faster than mine, but I have a map and load a few models in code (probably a total of 35 models including terrain with no roads/veg and a couple cursor files) and it takes about 10 seconds, but even as little as 10 seconds with no visual feedback seems like a lifetime to users. I know as I'm staring at the black screen I'm asking why is this taking so long.

As long as you have 1 model in your scene and we do the terrain loading last you'd see your progress bar go to 50% complete after it loads the first model. Then it would sit there for maybe 30 seconds to load the terrain. You would still get a visual right away, but a small one in this scenario. But honestly if you only have 0-1 models and a terrain in your scene then you wouldn't be worrying about load times in the first place Are you thinking the progress bar would constantly be moving? I guess I don't know why you would need to slow it down. If you have so little of stuff that it loads fast enough then you wouldn't worry about a loading screen.

And that's ok. Progress bars aren't always smooth moving. In fact very few of them are. Think of each model & terrain as 1% of the total. You put up a splash screen with a 2D picture on it and then after each model/terrain gets loaded a callback is called and after that the screen is rendered & flipped so it shows the updated progress bar after each model/terrain is loaded. For things that take longer to load there will be a longer delay. I'm aware this approach won't allow you to have a constantly moving thing on the loading screen because it will still freeze while it loads a model, but it does give a break after each model is loaded which is far better than what we currently have. Right now you put up a picture and it sits for 4 mins while the user thinks his game froze.