Pixel Perfect

That's handy to know

The next question that comes out of this is how similar is the API intended to be. I'm thinking along the lines of how easy or hard is it going to be to convert an engine based on leadwerks 2 to Leadwerks 3.

So essentially it's a complete re-write then

So you are hand translating the BlitzMax into your intrim language then Josh, not using some BlitzMax to intrim language convertor? Basically using your knowledge of C++ to aid your translation and the resultant structure but speeding that up by using this intrim language. The intrim language then being converted into standard C++ syntax in a second automated phase. Would that be a correct assesment?

The alphatest and alphablend shaders from my understanding are used as follows: alphatest: To provide simple transparency where the texture is concidered to consist of opaque and transparent areas but the transparent area is concidered to be fully transparent. The shader will treat any Alpha values above a certain threshold value to be full on transparent and this is generally faster. This appears to work in the foreground world without problems. A typical example would be a leaf texture for a tree where the leaves are opaque and the surrounding texture fully transparent so it is not visible when rendered. alphablend: To provide full graduated transparency in textures where the full 8 bit alpha channel is converted into differing degrees of transparency dependent on the alpha value. This requires rendering in the transparent world to be rendered correctly. An example might be a block of ice with differing transparency dependant on the thickness or impurity distribution.

You are quite welcome DarthRaff ... happens to us all at some time or other

If you are using this new language simply as a vehicle to eventually produce valid C++ syntax and it works then fair enough, that seems a perfectly valid way of producing a larger bulk of code more quickly (a kind of coding shorthand if you like). However, if this is to simply convert existing BlitzMax structured code to C++ without any thought to redesign to take advantage of the destination language then I'd suggest you might get a less than optimal results. It's quicker and may well work but may not really utilise C++ to its full advantage. Only you can make the judgement call on this Josh as we have not seen (nor probably want to) the full source code.

I updated my game engine code to 2.40 with no issues other than a parameter change to one command (see below). The framewerk worked perfectly so I suspect you have your files a bit mixed up. I'd go back to your original version that previously worked with framewerk and whatever version of Leadwerks and copy the project as a backup. Then update the original to 2.4 and copy over your framewerk files (confirmed they are not in the 2.4 release) and try again. It should work ok. The syntax of the following function appears to have changed between 2.31 and 2.4 with no reference to it, that I can see, in the version file: 2.31 typedef void (_stdcall *TEntityViewRange) (TEntity entity, flt nearrange, flt farrange, int recursive); 2.40 typedef void (_stdcall *TEntityViewRange) (TEntity entity, int range, int recursive);

If I have time I'll try it tonight with 2.4 and see if I have the same issue

Have you copied the framewerk.cpp and framewerk.h files from your previous version. These are now fixed (not being maintained) and I don't think they are distributed with new builds any more. If you have no need to modify the framewerk then there is nothing to stop you from using the embedded framework syntax but you will never be able to alter this in any way should you want to. I don't know off hand what the syntax is but isn't there a page in the Wiki on both the framewerk and the framework.

In my case yes ... so I'd like to see the solution to this if this is indeed the case. I'm using my own modified version of the framewerk which was retained (if not maintained) so we could do just this! I'm still working with 2.31 When you say 'Framewerk it's not working in 2 40' what problems are you experiencing ?

AndyGFX produced a library in BlitzMax for this sort of thing. I don't know what language you are using but I'm sure it could be fairly easily converted or serve as some inspiration for your own design. You can find it here: HUD Library

Sorry to hear about your continued problems in this area Michael. It does sound like you are having a particularly bad time of this as I've not experienced problems like this. But no doubt you are pushing the vegetation system and possibly others well beyond the boundaries I previously have and the size of the sbx files too. However, so long as feature requests like the one for the Undo facility are ignored, I will continue to have major concerns about the validity of using this engine for my game project. I picked up on the fact that some people seemed surprised by previous comments I've made regarding my worries about future fixes being timely and not hitting major delays should I hit problems with the engine. This only serves to act as an example of what I meant by that. I know Josh is a very busy person and I have nothing but respect for what he's achieved so far but I still lack confidence in this support aspect of the product! The Undo request has been ignored for 6 months … that is simply not acceptable!

Nothing lol. It was just an example of how to draw onto a texture in a buffer that happens to use OpenGL. It's easy to mix and match OpenGL so really not that complicated and, unlike BlitzMax, users of other languages don't have access to all the properties you do so was a more general solution. Good that you have a solution working that suits your needs

I totally agree and this issue just gets ignored and ignored and ignored!!! I feel like we are just banging our heads against a brick wall. It just makes Leadwerks Editor feel very unprofessional and causes untold frustration when things do go wrong.

Yes, the one I gave you a link too above. It explains how you bind a texture to a buffer and draw too that. You can then just use the resulting texture in the buffer, no need to save unless you need to have a copy in file format for what ever reason. You can do just the same using LE commands directly but I think the 2D Drawing commands only work with the back buffer which is a bit more restrictive. You probably have easier access to OpenGL from BlitzMax too.

Yeah likewise, great in game screenshot. Very impressive! Josh would be by far the best person to advise on this question on texture blending. Hopefully he'll respond fairly soon!

This looks really cool .... makes me wish I was using 3DSMax. I'm sure those who are will welcome this addition!

Probably the best way is to use OpenGL directly to draw into a Leadwerks buffer as it's a lot faster than the internal 2D drawing commands. See Using OpenGL for drawing

Yeah, they employed this guy after he developed this to put it into Unity. It's just one of many similar systems being developed around the world by various people and companies. Some of the AAA houses have had this capability for some time although it's surprising how many haven't. Just look at Dragon Age for a perfect example, as nice as it is, of feet floating firmly in the air when descending slopes In many respects the advanced animation blending techniques probably have more visual impact than the IK corrections for foot placement, that's the final icing on the cake!

Great to see you back and active in the forums again MG. Thanks for sharing this very useful code, much appreciated.

Yeah, great example there Pancakes! This is also worth watching:

Chris Paulson has been working on this for the past 3 months or so, but also including much more sophisticated animation blending. I know he's been using a similar technique for the foot placement where he uses picks to determine the ground height and gradient and lets the IK take over for the final foot placement. Makes a huge difference to step climbing too. His animation blending is looking really good but requires a lot of analysis of the skeletal movement to ensure frames from different animation sets are perfectly synced together. He's away on holiday at the moment or I'm sure he would have responded with a lot more info! But yes, you are right. These sorts of techniques make for much more realistic and believable animation.

Yep, this is a known problem or side effect. It's due to the creation of an internal data structure in the engine. Current work around is to pick everything once prior to starting the game. Not great I know! lol looks like two people beat me to it

Found the answer in a quote from Josh in the old forum: So I'm guessing the color buffers etc are the renderbuffer objects attached to the FBO