Pixel Perfect

I don't believe the EULA prevents the creation of development toolsets at all, I think maybe what you are refering to is providing the gamer with tools which allow him modify/change the game so that for in all intents and purposes it becomes another game! Although, in actuality, even this may be possible but requires prior consultation and agreement with Josh. I do think Elmar is refering to a multiple veiwpoint scenario though where one is a view of the whole scene and the other a view of the selected mesh from the scene. Maybe even a picture within a picture would suffice, I don't know without more info on what you're trying to do Elmar?

The level looks fantastic Ubu ... you have managed to perfect that 'dreamy fantasy' type look and feel. Whats with that weapon though ... is it a sword or a chain saw

That may well be, but Josh also said prior to the release of 2.3 that no-one not wanting to go down the Lua route would be forced to .... so I upgrade to 2.3 to find he's removed the generic property editor and replaced it with a Lau script based system. Ini files offered an alternative (are are also far easier and quicker to maintain) and now we are told they are to go too. I don't want to stand in the way of progress but developers have a certain responsibility to their customers too. I agree that if the Lua files can be made more 'update' friendly then that would help. If I have 50 or so complex objects that I want to have slightly different property settings I'm not going to be using the 'in editor' property system to update those!

Yes, I agree. Reading in my own ini files is probably the solution I'll implement too, but it's annoying as it's all additional work to be done on top of the already massive task of writing a game engine based on Leadwerks and doing all the level design etc. Like a lot of other Leadwerks users I'm a single person game developer doing this in what little free time I have available. What does he really gain by removing ini support? I suspect very little! I feel at times like I'm being railroaded down a track of Josh's making for no better reason than because he can! I've invested so much in this engine and its overall capabilities that I'm reluctant to move away but I do feel that he needs to better justify decisions he makes at times. As his loyal customers I believe we deserve that!

I agree Mike, that hadn't gone un-noticed, but there was a general inference that the C++ framewerk was not going to be maintained in the reference to 'you can continue to use the existing C++ framewerk' rather than an actual statement that it would be. Hey, he'll be getting rid of ini files soon which will really piss me off, seeing that I'm not using Lua, but what can you do other than vote with your feet and move to another engine!

Looks around him for his modelers and level designers Most of us small Indie outfits dont have that luxury! Anything that helps and makes the flow more productive has to be a good thing.

Ah thanks Ubu ... we were away at Christmas so I guess I missed that. It'll probably continue to use it for some time despite it no longer being maintained as I've no need for Lua at the moment and unless Josh changes the current API it will continue to work with future versions.

So when were we given notice that framewerk was going to be dropped?

Haha .. you guys make me laugh at times. If you're using GetEntityUserData to obtain a pointer to the trigger class instance then that, to all intents and purposes, is a global variable as its in global space and available to everyone Glad you have it working though! Are you still on target for your demo release Shard ?

Yes, the callback function is in global space so you need to get a pointer to the level class to it. You could either make a pointer available globally which the callback could just reference or pass the pointer as stored data to the trigger object using SetEntityUserData and access that from inside the callback routine.

Chris Paulson mentioned this too me today too, and now I've gone and looked it does look awesome. For a minimal investment this could be a massive time and expense saver!

Now you have got me interested ... why assembly language .... what requires such speed that you're forced to use assembler or is it just an exercise ?

Looking fantastic Flexman, you guys are really on top of this project now!

I'm sure there are more elegant solutions but you could simply convert to a string, swap the characters and convert back to an int again! You can shift left and right in registers to do this sort of thing but that's in binary which isn't going to give the result you're after (not without going beyond my limited maths anyway lol). I am intrigued as to why you want to do this though!

That looks really cool Gandi ... nice work!

I'm using terrain created in the Leadwerks Editor, so essentially loaded from the saved heightmap during the LoadScene command. My editor needs to place items on the terrain as well as on other objects and an example of some code I use for the camera pick is as follows: // Place model in picked position if(bPlaceModelMode && bLeftMouseButtonClicked) { // Perform a camera pick (raycast) iGotSurface = CameraPick(&pickStruct, camera,Vec3(MouseX(),MouseY(), 1000),0,0,NULL); if(iGotSurface) { vec3PickPos = Vec3(pickStruct.X,pickStruct.Y,pickStruct.Z); // Position the model at the picked location PositionEntity(entModel,vec3PickPos,0); ShowEntity(entModel); bPlacedModel = true; } } It's in C I know, but hopefully this might help.

I used the same functionality way back in the version 2.0+ days of Leadwerks and there were problems with it then too. I had to alter code following instructions from Josh to get it working. With regard to CameraPick and picking terrain, I use this all the time in my editor and have no issues with it, it's all working fine! I'm using version 2.31 at the moment but its worked with at least the previous 4 versions that I know of.

Welcome from me too ... hope you enjoy the forum just as much

Well to be honest the caller must always check the return value of a function as a function must always return something and if it can't return something valid it has no choice but return something else. I prefer to code functions which always return a boolean result which is true if the function has succeeded and false if not. The actual required value being assigned to a variable passed by reference. This way the user gets used to always having to provide code to check the return value is true before using the updated variable. In this way the checking is actually done in the function itself and the callers return value check is consistent across all function calls. It just strikes me as a better way of encapsulating code which is what Mike, I think, was suggesting. But either way, a check by the caller always has to follow the call to the function unless the return value is known to always be valid.

I have to admit that Lumooja's posted code does seem to offer a safer way of determining that the entity returned is indeed the top level model. Note, there should still be a check for a NULL Entity prior to supplying it to any function.

Yes, sometimes when we don't have knowledge of the inner workings we just have to derive solutions empirically

Exactly, I can't see how this could be done with anything other than key framed animation and then would only provide partial improvement. Sorry for hi-jacking your thread btw I seem to recollect Josh saying somthing about Newton liking to run at a set internal speed but I don't remember the detail, so maybe the effects you are seeing are as a result of a clash with that. Josh would throw some better light on this!

Granted carefull syncing of key frames at that low frequency may help with the continuity of percieved motion but it will never look like it being animated at 60FPS and must still look jerky as most of the between animated frames (or hardware interpolated frames) will be missing! That could be a useful technique for improving the effect of animation in the region between 20 and 30 FPS though. I am quite intrigued as to how they would calculate the neccessary frame syncs! Are they simply ensuring that only key frames are presented at each available frame window ?

But 5 FPS means that the rendered frames are only being updated 5 times a second. How can that produce smooth animation which generally requires at least 20 FPS to be acceptable (but not comfortable) to the human eye (30 being generally regarded as the minimum these days).

Timing techniques can be used to ensure movement in games remains a constant regardless of frame rate which prevents the obvious speed differences you tend to see otherwise with low frame rates. However, I fail to see how movement in a game running at 5 fps will ever look smooth like a game running at 60fps. The very reason your hardware is running the game at 5 fps is because it's taking it that long to calculate each new frames data and render it. It may still run in real time speed but the animation will look awfully choppy!