gamecreator

Thanks for posting. You can use GetWidth and GetHeight on a texture and use that information to center an image. In C, it would look something like this: context->DrawImage(texture, x-texture->GetWidth()/2, y-texture->GetHeight()/2, texture->GetWidth(), texture->GetHeight()); Where x and y are the coordinates you want the image centered on.

Yikes. Did he break something he shouldn't have?

Not sure how many other users came across these problems but I suspect you appreciate their challenges more now. Glad you're handling this because these issues are definitely beyond my skills.

Have you tried installing OpenAL, even if you think you might already have it installed? https://www.openal.org/downloads/

As Thirsty Panther said... but it might have to do with gimbal lock. Don't know why but Leadwerks doesn't handle this for you.

Yeah, the rules seem pretty easy to set up and probably best to search for minimal terms, not combined terms. If the name contains "steering" then it's safe to assume it's a steering wheel. Name could also be "steering wheel" or "steering_wheel" so searching for "steeringwheel" might not work. Though it's not too bad to ask devs to name limbs specific things (like how we have collisionhull right now), it's ideal to be flexible, if possible, to not even need to have devs alter their models. Also, the model could include a spare tire on the back (or in the trunk), like Jeeps do (https://ddcfq0gxiontw.cloudfront.net/Review/39832078/17545495/medium_square.jpg) so not sure how you'd handle that. I guess if the name includes "spare," it's disregarded.

That video looks pretty solid. I assume we create our own collision mesh(es) for the body? For example, a car. a truck and a plough truck will have different looking meshes. It would also be nice if the code that detects "wheel" and "tire" could also detect the words "front," "back," "left" and "right" in the names. That way there would be no ambiguity and we can name a tire tire.front.left or FrontLeftWheel, for example. Also, what do you mean by a script doing the interpretation? How do people using only C++ get their car tires detected?

Josh may correct me but I think the only thing you can really do is move the camera much closer.

Yes, the debugger ended up helping me. I pretty much never use it and am not really familiar with it. It pointed to a free() function which helped me figure out that I was handling my memory incorrectly. Thanks for the other suggestions too.

I think I might have caught the problem. Of course it was on my end, even though it seemed to crash in a Leadwerks function. I was using a char for an offset and when I introduced more enemies, I think that overflowed. Setting it to an int seemed to fix it.

It does also crash on exit now for some reason. Double-checking to make sure nothing is out of bounds or a memory leak.

What things could potentially make world->Update() crash a program? I have the following code right now and the program regularly crashes after printing D and not printing E to the console. printf("C"); Leadwerks::Time::Update(); printf("D"); world->Update(); printf("E"); world->Render(); printf("F"); gui.draw(); printf("G"); context->Sync(true); printf("H"); As I was typing this up and testing the program again, I got the following error, which seems like it crashed during world->Render(): Searching the forums found this issue (https://www.leadwerks.com/community/topic/10612-world-update-crash/) which seemed to be resolved at the time. I should also make it clear that this doesn't usually happen as soon as I start the game. Sometimes it takes a few seconds, sometimes it's when I fire a shot, sometimes when I kill an enemy. Happens sooner the more enemies I include though. Pretty much never happens with just a few, like 6 or less.

Likely related to these from back in August: https://www.leadwerks.com/community/topic/17516-tips-to-improve-my-vehicle-with-joints/ https://www.leadwerks.com/community/topic/17525-how-can-i-prevent-the-tyres-from-bouncing/

I tested it with him a few minutes ago. So far so good.

Definitely familiar with this stuff, having worked with Steam (and literally working with it right now). Very flexible. Curious if you'll end up implementing some functions for transferring various data types beyond the void pointer Steam uses for packet send/receive.

Love it. I hope there will be a clear example somewhere of how to set it up and what to adjust for certain effects (less or more bounce, tighter or looser steering, etc.).

Here you go: #include "Leadwerks.h" using namespace Leadwerks; int main(int argc, const char *argv[]) { Leadwerks::Window* window = Leadwerks::Window::Create(); Context* context = Context::Create(window); // Load 2 sprite frames Texture* texture1 = Texture::Load("Materials/Developer/bluegrid.tex"); Texture* texture2 = Texture::Load("Materials/Developer/greengrid.tex"); while(true) { if(window->Closed() || window->KeyHit(Key::Escape)) break; context->SetColor(0.0, 0.0, 1.0); context->Clear(); context->SetColor(1.0, 1.0, 1.0); // Display alternating sprite frames depending on time if(Time::Millisecs()%1000>500) context->DrawImage(texture1, 0, 0, 1024, 1024); else context->DrawImage(texture2, 0, 0, 1024, 1024); context->Sync(); } return 0; }

Does that work in 7? And can you rotate/zoom it in the preview pane?

Looks like you found another topic on this but yes, you need to keep track of it yourself because animations can be mixed. I use model->SetAnimationFrame(animationframe, 0.8, animationstate, true) to set a character's animation every frame. I increment and keep track of animationframe myself based on how much time has passed since last frame. Then I use model->GetAnimationLength(animationstate) to check if animationframe has exceeded the end of the animation. If it has, I reduce it appropriately (which isn't necessarily the same as setting it to 0).

I got curious so I tried it and I was able to do 2 bone rigs in a single FBX file. Not sure what I did different from you (or if I misunderstood what you meant). Anyway, all the files (including FBX) are attached for you to look at, if you'd like. 2bonestest.zip

That sounds right but not sure. Could test it tonight if you want. Haha and yeah, never noticed that rating. I wonder how long it's been at that score.

I believe only the bone skinning option works. You can, however, parent models via code and moving/rotating the parent will do the same to children, relative to the parent.

Sounds like a good call; first impressions are important. Good luck with it and looking forward to the release.

There's something so nice about gameplay starting to show itself after some time coding and whatnot. And god bless the people providing free music and sound effects (and though these are all purchased models, those who release free models and textures too). Edit: randomly generated dungeons, by the way, reusing part of the code from here.

I worked around the problem by importing all the animations into the idle animation itself then renaming that file. Not sure what the problem was with the original.