Naughty Alien

..sure i can..sorry for delay guys, I am on other side of the planet.. I didnt post publicly because its not games related, so I wasnt sure is it going to be deleted or not, thats all..here it is..I was messing around with some IP camera security software, and i came accross this open source software called iSpy (http://www.ispyconnect.com/) .. so I downloaded it, tested (compiled version) and decided to take source as it will be great to integrate with my new studio office door system...so I did downloaded source and according to web site, 'its all there ready to compile'..except its not, as some dependencies need to be removed, but i somehow couldnt manage to do so, so i was wondering is there any C# guru here who could took that source and just clean up those things mentioned in readme file, in order to biuld/compile, as I have no idea how to do it, to be honest, and upload existing solution already provided, but really ready to compile??

Hi guys...im wondering do we have skillful c# coder here, I need small favor..

..i was under impression that its already running on OSX??

..depending on hardware available, you could go more than that..bigger number of sources i have seen is 32 on test rigs i have had..but you should not completely rely on raw amount of available sources, and instead some sort of sound manager should be created so sound sources could be utilized more efficiently and according to scene/camera position, if limit is reached..

..that is partly truth..it is truth provided that target audience are people who are equipped with latest hardware..it is truth to say that from engine standpoint..from standpoint of game/application developer its a big no no, as it radically cutting down available user base. It was the same claim during LE2.x time..and i have had first hand experience where i could have 45-50% more units sold if renderer could go slightly lower than its specs at the time..most of people here developing casual, small scale games, and their audience cant be just high end hardware..if they want to make any money, they must cover wide audience as possible..simple as it is..with locked down renderer to one OGL flavor, its not really going to work that way..

..that is something to realistically expect, provided that engine seems to be always tightly attached to specific OGL version, what also makes engine unable to do autofallback for older hardware..i hope im wrong, as I would like to go back to LE at some point..

hahahahahaahahahahahha

You haveee, sooooooooo much unused UV space..

..what i did in LE2.x was creating timer independent from rendering and calculated time between frames and then applied changes on to dynamic entities in game..it worked well and accurate..

..LE2.x was exposed to same issue..i never used it to stabilize motion in game as it was useless, with same issues as you describing..I guess, code base for that particular function remain same..

Bugs are something considered broken, non functioning, therefore, why would you pay for something what suppose to work properly? Payed upgrade of system is ok, but paying for fixing something broken?? Also, I believe Linux userbase is significantly smaller than mobile user base, and im afraid LE author will learn that hard way. It should be done what was le2.x community requiring a year plus ago, and now will be a lead dog on the particular field..

..this is exactly what LE2.x folks claimed some time back, and it was refused because 'market is on mobile platforms'..pity to see such talented guy, wasting time and community on to wrong business decisions..

..this situation seems to be rather identical or very similar to crossroad between LE2.x Leadwerks 3.x, when existing user base asked for desktops(WIN/Linux/OSX) what was rejected in favors of mobiles..deja vu..

Great idea...I have had such thoughts, based on hope that le2.x will turn to be open source, after le3 was released, so some of us with large codebase around le2.x could push it further, and even extend it as a cross platform, open source comunity project...good dreams..

I do not have Leadwerks 3, but im carefully observing forums, as I may look for it, but not at this moment. Having said that and regarding this topic, have you guys maybe pinpointed which part of your scene causing fps drop? I would really like to know.

..actually, its rather simple to do that..it doesn't require any additional checking, but volume check..now, what im about to say is based on my understanding of Leadwerks 3, i dont have, but i expect that simple command set for sounds are same as LE2. ..if you want your enemies to hear you(main character), basically, you will simply, attach 3D sound you want enemy to hear to each enemy with EXACT settings your main character have..by saying attach 3D sound to enemy, I mean, keep position 3D sound you want enemy to hear, to exact enemy location..lets call that sound a marker sound. Marker sound should be just silence, 1 sec or so. Now this is what you do: 1) Load marker sound with exact settings as sound you want enemy to hear from main player, such as footsteps, and so on(range, etc) 2) Play marker sound(silence) in a loop, so you cant hear it anyway 3) Every time enemy moves, reposition marker sound at enemy position 4) Every time main character moves, check VOLUME of your marker sound(this depending are you want to listen walking sounds or reloading weapons, etc, adjust check based on this and individual marker sound) 5) If marker sound volume is over 0.0, enemy HEAR your main character On the top of this, you can add any additional check such as visual sighting, etc, to improve your AI, if you want to.. This will do..tested and it works.. I hope it helps

My question wasnt related to any of tools discussed here..I just thought, you may be lurking on other side of modelling where accuracy is main objective, and if so, Im interested to see what is it done on that field..

@ YouGroove ..it seems you are messing with plenty of different tools..having said that, have you did anything in terms of modelling, technically accurate?? eg. building a structure out of DXF files or so??

I think its normal behaviour. Keep in mind that you watching visual interpretation of physics body, exposed as a wireframe trough renderer, while at same time renderer and physics update, ticking on a different way, what you see as a difference on rendering interpretation side, while physically, its all fine as your camera/characters, moving just fine. I believe, that behaviour is normal thing to see.

..hi guys..do you know any SDK tools available for Android/IOS, what can be used to develop karaoke style game, (recording voice and then scoring, etc etc) ?? I couldn't find anything specific. I know i can do it with BASS lib, but i would rather go for something established for such task, if exists..anything?

..i guess controller is always aligned along gravity vector, so in that case proposed solution will work, provided that parameters are taken along direction controller is facing..

...nobody said it cant be done..i haven't seen a one post saying that..but I will be more than happy to see a game spreading from latest modern hardware down to hardware just 3-4 years old (as a developer, you should care about this, unless you are Crytek or Epic and pushing up high end stuff), and using tessellation across all hardware setups (not just nVidia)..it was never question is it doable or not or does it exist..DX9 can do it just fine and its well documented in DX9 SDK, so its already how long?? 10 years? There is a reason why mentioned technique is not become a 'standard' yet, even exist for some time, and reason is NOT is it doable or not, but hardware mess, manufacturers created, what makes your code rather difficult to deal with all that, hence, making your code probably crash on some configurations...thats all...if you want to run your game on latest hardware, go for it by all means..if you want to hit much wider audience, you will not go with tessellation.. @Rick My apologize, if my contribution here caused confusion, as your question was rather simple. In order to make it simple, much as i can and know, Ill tell you this. Do not trust a word i have said. Maybe take it as a some sort of remark or warning, if you please. I suggest, you try yourself mentioned techniques, and see for yourself what will do best, and how your code will perform and then make up your mind based on personal evidence you will collect trough such process. I have done similar things few years ago, and that was basis of my claims here. I may be wrong, of course, as my knowledge about matter is limited, but i do understand principle behind it. Do yourself favor, and test it yourself, as entire this thread is turning it to a confusion. All best bro..cheers..

..simple way to determine memory pressure based on textures.. RGB Compressed DXT1 0.5 bpp (bytes/pixel) RGBA Compressed DXT5 1 bpp RGB 16bit 2 bpp RGB 24bit 3 bpp Alpha 8bit 1 bpp RGBA 16bit 2 bpp RGBA 32bit 4 bpp To figure out total texture size: width * height * bpp. Add 33% if you have Mipmaps. ..as for triangles..Geforce 6600 can do 375 million vertices per second(provided that no texture or anything is loaded),and its VERY old card, and as you can see, there is more than enough triangle space, far more than you can have with textures..

Rick, it wouldnt affect speed at same rate simply because you will share same texture/materials, over same model..vertices are cheapest thing to keep in memory...test it yourself..load in to any engine, one single large mesh, let say, 150K triangles, no texture of any kind attached to it..record frame rate..now, exit and load identical mesh but this time, with texture attached to it..look at frame rate now..it will be noticeably lower..vertices are cheapest to deal with, and long as your LOD meshes share same texture/material, speed impact will be minimal...heavy memory load is related to textures in memory, not really vertices..however, processing vertices(due amount), can impact performance, but classic LOD if you need it, doesnt really do that so it will be for sure, faster on not so modern hardware than any tessellation processing...on modern hardware however, as stated before, you really don't need LOD, relatively speaking, to amount of characters you will have seen at once..

..tessellation is no magic and rather simple process, yet it can be time GPU time consuming..there is no doubt that it can be used, but fundamental question is, do you really need it when modern hardware can crunch triangles necessary for good looking model with ease..it is truth that in such scenario, use of tessellation would be downsampling, in order to get less triangles to render..however, having in mind that modern hardware have huge vertex buffers, capable to store enormous amount of vertices, so, tessellation is really not a necessary option to have really even if you want to downsample your character mesh..point is, if you have not so many characters on scene, and using modern hardware, you really dont need any tessellation as LOD on mentioned characters..if you have plenty of characters (eg. 100), in order to keep your performance up, you will most probably rely on instancing in order to populate such amount of characters(same skeletal/mesh with different textures), rather than have tessellation over every single character..other people in some AAA ranked studios, realized that and I dont understand whats the problem here..i see tessellation well used over static geometry, but not at all on animated characters (if we talking modern hardware).. If game need to be executed on modern and not so modern hardware, and far as im, as a developer concerned, I want that,,in that case, use of tessellation is no go for both, characters as well as geometry, because chances are, it will not work on plenty configurations or it will be very slow..all in all..its nice and not worth trouble you may get yourself involved..simple as it is..