Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MagmaMcFry]

Here's my code for that particular problem (it works for me):

Code: [Select]

       if (player.getColor() == '#f00') player.setColor('#ff0');
       else if (player.getColor() == '#ff0') player.setColor('#0f0');
       else player.setColor('#f00');


[miauw62]

Oh, right. That made me realize my stupidity.
I only used normal ifs, so my color would cycle all the way through back to green >.>

E: Wee, completed the game. Managed to get past endoftheline.js, too.

[alexandertnt]

Some more testing, it seems to be the amount of screen filled, not how close the camera is. I tested this by putting the camera in a position where everything was running smooth and scaled it all up. Which seems to be evidence for some sort of fragment thing.

The problem is called over-draw.  What happens is that you are drawing the same pixels over and over.  When there is no transparency the renderer renders from near to far and can use the depth buffer to cull fragments early, meaning that each fragment is rendered only once.  This wouldn't work with transparency.

One idea that I have had on this subject is to repurpose the depth buffer to an opacity buffer that culls when a certain opacity level has been reached.  This would only work in a system where a total ordering of polygons is possible, so I don't expect any closed-source general-purpose renderer to be flexible enough to allow this.

P.S. Some ways to ensure the existence of a total ordering of polygons are: a BSP tree, an octree, or a voxel grid.

Unity apparently has an overdraw rendering debug thing, and this does appear to be the problem.

At least now I know I can have lots of decals as long as they are not all on the same spot.

[dragnar]

Ah, the joys of trying to look up something you don't know the name of...

I'm working on a simple(ish) Javascript page for class, and need to set up a pair of, er. Selection boxes? Two side-by-side boxes full of options and a pair of buttons with arrows on them that move the selected option from one side to the other. I can't imagine this is anything too complex or anything, but I have no idea what that sort of interface is even called to look it up.

Also if anyone knows a clean way to load variables from PHP into javascript that would be nice. I've figured out a way to do it, but it's rather inelegant.

[Levi]

Ah, the joys of trying to look up something you don't know the name of...

I'm working on a simple(ish) Javascript page for class, and need to set up a pair of, er. Selection boxes? Two side-by-side boxes full of options and a pair of buttons with arrows on them that move the selected option from one side to the other. I can't imagine this is anything too complex or anything, but I have no idea what that sort of interface is even called to look it up.

I don't think there is a widget for that exactly, but you could code one up out of select tags (<select size='10'><option value='1'>Option 1</option></select> ) and javascript.

Also if anyone knows a clean way to load variables from PHP into javascript that would be nice. I've figured out a way to do it, but it's rather inelegant.

Probably using JSON is best.  I'm not that familiar with PHP though, so I'm not exactly sure how to do that.

[Maklak]

> Two side-by-side boxes full of options and a pair of buttons with arrows on them that
> move the selected option from one side to the other.
Combo Box : http://en.wikipedia.org/wiki/Combo_box
Search for "Combo box html" of "Combo box javascript" and you'll find it.

[Mephisto]

If you have trouble with Javascript, it's generally not your fault, but Javascript's. Try using == instead of ===.

I know your post was made two days ago, but I finally (re)found this site again. Enjoy.

http://dorey.github.io/JavaScript-Equality-Table/

[MorleyDev]

The difference is == does type coercion, === doesn't. So a number will never === a string, whilst with == if it can cast the two to a common type it will. So ("12" == 12) but !("12" === 12).

== is both less efficient as a result, and can introduce unintentional behaviour due to the underlying rules used being unintuitive. The rule of thumb is to err on the side of ===, and only use == if you deliberately want type coercion.

Javascript, grr *shakes fist*

[Mego]

JSON + Python is so sexy. That is all.

[Mephisto]

I just like making fun of the steaming pile of good intentions that is Javascript.

[dragnar]

> Two side-by-side boxes full of options and a pair of buttons with arrows on them that
> move the selected option from one side to the other.
Combo Box : http://en.wikipedia.org/wiki/Combo_box
Search for "Combo box html" of "Combo box javascript" and you'll find it.

Aha! Yeah, that's pretty much what I want, thanks.

[Skyrunner]

Woaah.

You can do 99**99 in Python and have it not error D:

[Mego]

Spoiler: It takes a lot to break Python (click to show/hide)

[Skyrunner]

I bet the actual calculation was done quicker than the stringifying.

[Skyrunner]

Am I good enough to 1 on 1 tutor someone to learn  the basics of programming? D: I'm casually doing that, but I'm mildly worried that I'm not doing it well enough or that I'm going to ruin it all.