> The way around this issue is to make yourself standout so that it isn't an option for them to go to other people. If you are really good at what you do, then people will accommodate your needs because those are what help make you better in the first place. If you're just doing work that anyone else can do, then there's many people who can replace you.

>

While this advice might be true for many things in life, this is not the case here. In the world of licensing and contract work you can make the best game ever, with some new innovative mechanic, a game like no other that no one else can or has made, many sponsors/portals will tell you they really like the game and are interested in purchasing, but they don't accept C2 games, especially some of the bigger ones. Likewise companies looking for contract games made are looking for devs to use other engines as well.

While I can appreciate good advice, make better games, work harder, stand out from the crowd, have a bigger or better skill set is not the answer or solution to what I am asking.

Now if anyone has any input that is actually working with licenses and contract games using C2 I would love to hear your experiences, both negative and positive.

I don't understand what you're looking for then. If what you say is true, then it seems like your only option is not to use C2.. or find more that accept C2.

How many have actually told you they don't accept C2? How many games have you made?

The way around this issue is to make yourself standout so that it isn't an option for them to go to other people. If you are really good at what you do, then people will accommodate your needs because those are what help make you better in the first place. If you're just doing work that anyone else can do, then there's many people who can replace you.

I don't remember seeing this thread before, but here's my game on itch:

http://prominent.itch.io/quasi

okay, I had a go at trying to improve it..

It's not perfect, but might help a bit..

I don't have much time to spend on it, so maybe someone else can improve it, or you can figure the rest out yourself?..

http://www.filedropper.com/newsnake2

maybe it isn't working if you destroy the sprite before destroying the progressbar(it won't be able to reference the sprite's health thus it won't be set to 0).

You also have to make sure you are picking the correct instance.

You could also use the cosine of the angle to determine the speed at which the arrow moves, and just control the angle of the arrow.

> To imitate that motion, I would find the angle of the arrow, and have the following pieces attempt to align with a position that extends backwards from the current angle.

>

i dont understand at all what you say !!!

that make me confused that simple mouvement like that ... and i dont find it

What part don't you understand?

To imitate that motion, I would find the angle of the arrow, and have the following pieces attempt to align with a position that extends backwards from the current angle.

This behavior can be used with sprites to find the nearest point/corner on its' collision polygon (in relation to a position you provide) and returns the screen coordinates of that point.

I'm putting it in the work in progress section in-case anyone has any suggestions for this behavior to improve it, as there might be other things that could be added.

spritePolygon v1: http://1drv.ms/1HyIzx5

ok try this

https://onedrive.live.com/redir?resid=7 ... ile%2ccapx

actually, I don't know if q3d allows you to do that (since you can't pick a camera when changing the parent), but three.js does allow it.. so might be something QuaziGNRLnose could implement.

try adding the objects to the camera (making the camera the parent of the object). That should allow you to move the camera and the child objects will move with it.

purplemonkey

Very cool! for the trees you can try creating compound colliders by using a thin cyclinder collider for the trunk and a sphere for the leafy ball. In debug mode you can trial and error and visualize the position of any extra colliders you add. this all has to be done with action however you can make it automated in the on-created trigger.

Prominent

You shouldn't need to mess around with manual rendering. If you make your scene background have 0 alpha and layer view-ports you can layer renders, however semi transparency wont cross between layers cause of the three.js renderer design. I will add more manual rendering features when I get a chance since you seem to be expressing interest and it wont take much work.

All transparent objects SHOULD render last, as this is the way transparency is generally handled in forward renderers. Opaque objects render in any order and sort using the z-buffer, and at the end transparent objects/sprites are sorted based on camera view-plane distance and rendered back to front. This should minimize all artifacts unless objects intersect, which is a problem that has no easy solution and is present in even modern renderers. If sprites are rendering last after the back to front rendering of transparent objects thats a three.js bug, but i dont recall this being the case.

http://stackoverflow.com/questions/8763 ... r-in-webgl

An image would help me diagnose what the issue you're having is. usually playing with material depth setting values and preventing the sprites/semi transparent objects from writing to the z-buffer works well, especially if its for smoke or special effects like explosions which utilize blending. Transparency is just an overall annoying problem. Sometimes the best solution is to not use a sprite at all, and instead a piece of flat geometry which is a cutout of the silhouette, so that the object can be opaque or mostly opaque, and the artifacts are minimized cause theres no edge-cases that lead to really bad transparency occlusion problems.

Thanks.. I tried using viewports, and I'm able to create a skybox this way.

The other issue I had with sprites was what that link you have describes. A sprite is behind the geometry and so the part covered doesn't get rendered even if material is transparent. I can probably work around it by using models like you suggest, and putting stuff in another viewport with alpha if I have stuff that should render over any sprites..

does it require more processing to render multiple viewports?.. would it be more efficient to render to one? If it's more efficient to render to just one, adding the manual rendering actions would still be useful.