Jump to content

Hadien

Members
  • Content Count

    247
  • Joined

  • Last visited

Community Reputation

39 Excellent

About Hadien

  • Rank
    Member
  • Birthday 04/18/1986

Previous Fields

  • Languages
    C#, CSS, HTML, Javascript, Java, MySQL, PHP, Unity, Unreal Engine 4, VBA, XML

Profile Information

  • Location
    Orlando, where it rains every 5PM
  • Interests
    Games, food, and a lot of Diet Coke.
  1. Try and understand the design concept of MVC, or (Model-View-Controller). its a design pattern used in many software applications but is a very solid choice for most website applications. Model - Stores all the internal data that the application uses. e.g. the database for websites. View - What the end-user sees, experiences, and interacts with. e.g. the webpage in their browser. Controller - The internal software application that "controls" the information flow between the model and View. e.g. the server This mindset helps define the responsibilities of each section of the application: The View is responsible in making a nice and friendly interface for the user and translating the inputs the user sends into actual requests the Controller can understand. The Controller is the Brain of the application, it takes the requests from the user and considers what requests can or should be fulfilled and communicates to the Model. The Model is simply raw data (database) full of information who's entire job is to grab or store massive amounts of data as efficiently as possible return any responses back to the controller. The Controller then filters the data returned and passes it back as a smaller chunk of information to the view Finally the View takes this chunk of information and arranges it in a way that makes it easier for the end-user to understand. notice that the Model and the View do not talk directly to each other, they must go through the controller. the view shouldn't reach the model for security reasons. like-wise the model shouldn't reach to the view because its not supposed to worry about the context of the information its generating. The controller is the proxy, translator, operator, or ambassador, whichever makes best sense to you. So how does this apply to your question? Javascript is pretty laid back and lightweight and uses an interpreter to run the code. This enables it the flexibility desired to run on most platforms and remain stable, but is usually slower than its counterparts. as such Javascript is usually best used in the View section of the web application (the user's browsers) since the end user will be running on a huge array of operating systems, from PC to Phone, or even console, where its flexibility can be taken advantage of, and speed isn't an issue. PHP is a little more strict but faster than Javascript. It has a lot of control (not as much as C++, but then again you don't need as much as C++) and is strong enough to process a decent amount of logic effectively. So you typically see either it or Java used as a server-side language for servers that may need to process thousands of requests a minute. SQL or Oracle are all about grabbing and storing data FAST, and less about figuring out what to do with the data which would greatly slow them down. so these languages are not designed to have the same level of flexibility as the other languages because it needs to search billions of rows of data, gather it, and return it as fast as possible. and so make great choices for Model sections of applications. My advice is that it would benefit you to learn both, it would only help your resume, and simply understand the roles that each language works best in. Your priority depends on which section of the MVC pattern you feel is most important to your current project (they're not always weighted the same for all websites).
  2. this line is the problem: orangeCost = (5); in your example orangeCost was assigned to an anonymous function (Its attached to the orangeCost variable, but the function itself is unnamed). That offending line is actually overwriting the function you wrote, thus deleting it. So the orangeCost variable is no longer pointing to a function, but to a plain 'ol number 5. To call it correctly this should be the valid syntax: orangeCost(5); Javascript will see that and think "oh, so you want me to run a function that's stored in the 'orangeCost' variable and give that function the number 5".
  3. var rect = one.getBoundingClientRect();var DeltaX = e.offsetX - (rect.left+rect.width/2);var DeltaY = e.offsety - (rect.top+rect.height/2);var Magnitude = (DeltaX^2 + DeltaY^2)^Delta^0.5;//should provide a degree range of -89 to 270var degree = (DeltaY>0)?Math.arcsin(DeltaX/Magnitude) :180 - Math.arcsin(DeltaX/Magnitude); When I have some time I'll come back and provide some polished code, but now I have some work to do. hopefully you can use what I gave you. EDIT: So here is the fully updated code after I had the time to actually sit down and work with it http://jsfiddle.net/afo7ky03/21/
  4. its "simple" math really, run a google search on "graph arctan2" and choose images, you should see what going on from that. basically when the y input into Math.arctan2() approaches 0 the number becomes undefined and returns a NAN. use ArcSin instead. you'll need the X delta (which you already have and pathagorean therom to find the distance (the hypotenuse or magnitude) which the mouse is from the origin. then... Math.arcsin(deltaX/magnitude); you'll never want to use arctan (DeltaX/DeltaY) in this case as you'll have the risk of DeltaY nearing zero and giving you a div/0 error
  5. well its inside an elseif so you don't even need to test if the number of apples is less than 4,just if it greater than 1. inside the first "if" expression you test to see if the value is greater than or equal to 4. so if that didn't evaluate to true the value would already automatically be less than 4, checking again in the elseif would just be redundant
  6. you are using vanilla jQuery, for this to work as expected on touch screens use jQuery Mobile. For mobile screens you want to use jQuery Mobile's .on("tap",[function]) as the event handler. The beauty of this is that jQuery Mobile will adapt some functionality to PC. If someone loads the screen onto a PC the tap handler will behave like a click handler, preserving functionality. Also if you only want it to activate in the bottom corner then you'll need to move the handler from that <div class="panel"> to a small div inside the panel <div class="panel"> <div class="front"> <!-- Stuff for the front side--> </div> <div class="back"> <!-- Stuff for the back side--> </div> <!-- Add this element --> <div class="dog-ear"></div> </div> then apply css for this new dog-ear class: .dog-ear{position: relative;bottom: 0;left: 0;width: 20px;height: 20px;} $(document).on('pagecreate',function(){ function flip(){ $(this).parent(".panel").toggleClass("flip"); } $('.dog-ear').on('tap',flip);}); If you're developing for mobile using jQuery try and read up on jQuery Mobile. the framework is written in a way to try and encourage you to follow the best practices when building for mobile applications, so it should be a fruitful read.
  7. Hadien

    Debugging!

    the reason I didn't run into that problem in my code was because of how I wrote my event handlers that link to the methods. in your script you use add event listener window.addEventListener('load',mynamespace.init); here you have addEventListener reference the init function to window directly. addEventListener forces the this reference to point to the window object when it runs init in my script I wrapped the object methods inside a custom tailored callback function... /*.....*/ele.button.onclick = function(){ if(flipflop = !flipflop){ ele.button.innerHTML = ele.button.value = "Encode"; ele.demo.innerHTML = encoder.encrypt(ele.demo.innerHTML); }else{ ele.button.innerHTML = ele.button.value = "Decode"; ele.demo.innerHTML = encoder.decrypt(ele.demo.innerHTML); } };/*.....*/ inside the onclick handler the "this" reference is pointing to the button which triggered the handler. but that doesn't matter because I call the encrypt/decrypt functions without passing on the this reference. The "this" that points to the button remains in this scope, while the "this" thats used in both crypt functions point to encoder since thats the object holding them and I'm not using any form of call or apply (this includes addEventListener). If you still want to use addEventListener then wrap the function reference inside another function window.addEventListener('load', function(){ //in this scope "this" will still point to the window object cause addEventListener forces it to. // but inside the init() "this" will point to mynamespace. it'll be preserved. mynamespace.init() }; or simply use bind to ensure this is using the right pointer window.addEventListener('load',mynamespace.init.bind(mynamespace));
  8. Glad to help! If you have any questions feel free to ask.
  9. Hadien

    Debugging!

    I'm not sure how you're having problems with the onerror scheme not showing you were a bug is happening, what browser are you using? Works just fine in chrome, when I add a simple throw in my functions, tells me exactly the line where the error happens and everything. Personally I use Chrome's developer tools to help me locate my bugs. simply open up the console and click on the error log and it zips you to the bug. There are two types of functions in OOP, "smart" functions and "dumb" functions. "dumber" functions tries to think as little as possible and only focus on one or two things. they have their own little world and the smaller it is the less likely it will fall apart."smarter" functions work by juggling multiple responsibilities at once. the smarter a function, the more it can do, the more responsibilities it has, and the more likely that things can break in it. An effective application tries to have many, many dumb functions and very few smart functions, ideally just one smart function (though we can't always get what we want). now I could have merged my functions in the encoder into one and have them flipflop functionality instead of delegating that to the function inside the onclick handler. but my code would be less flexible as I could only work on a single group of text per page. I kept encrypt and decrypt relatively dumb so that other code blocks would have more control over it. The functions run perfectly and as expected with the given encryptKeys and as long as things stay that way its not their fault if things break. when they do break (like you add in a "!" which is not stored in the encryptKey), the fix to that problem lies outside the function. Any instance where my functions fails silently is the intention. If the string the user inputs into encrypt/decrypt is invalid then the function simply returns an empty string and it lets a smarter function worry about it. If I was actually getting an error bounced back at me from inside those functions, which can still happen if I tried, then I would have to worry about fixing the code. My encrypt/decrypt could be dumber if I really wanted to break it out even more, but I really don't need the extra control it would afford. if it mattered and I wanted to create an entire framework for encryption then sure I would be breaking down functions left and right. Not sure how this argument is against using Objects. Thats true even when your not using objects. With the right coding habits this should almost never happen anyways. This is javascript so pretty much every object in exsistence will have a namespace of any size its just the nature of the language. you can dig deep into the Object functions and exert more control on your new objects, but you usually don't need to waste the time. Beside its far better encapsulating related data into single object namespaces than having it all in the global space where its more likely to collide with another variable using the same name.
  10. Hadien

    Debugging!

    remember the four basic qualities of Object-oriented programming: Inheritance, Composition, Encapsulation, and Polymorphism. Inheritance: Theres no true Inheritance in Javascript, you can only fake it through prototypes, but If you're not planning to extend the functionality then its not worth the effort in messing with prototypes. Composition: As a general rule in any language always favor using Composition over Inheritance. though you'll end up with an explosion of classes/objects to work with compared to inheritance, your code will be a lot more flexible. Javascript lacks an <<interface>> structure and <<abstract>> reserved terms so like with inheritance you can't achieve true composition. the insensitive type-casting can let you fake it, but it doesn't place the same limitations that other languages do, so its not as stable. Encapsulation: Make sure the least amount of objects know about your object's properties and methods. the less an object knows about another object and what it has or does, the less it relys on it. if your objects/classes lack proper encapsulation a single change in one object will force you to go back and update all other objects that depend on it. and if one piece of code breaks it's likely breaking somewhere else too. Javascript makes this hard to do as well since they want to make virtually every object transparent, but you can use closures to great effect in giving your object encapsulation. Polymorphism: one great thing about Javascript is how easy it is to change the object from one to the other without much worry to datatypes, so its simply making all objects which you plan to swapping with each other to have the same function names and similar behaviors to make them polymorphic Encapsulation is the easiest one to code for as it takes the least amount of pre-planning and most javascript scripts won't need for you to apply the other basic qualities. the very first thing I would do is group all those functions with encryptKey and make them properties of an object. this is the first step to encapsulation as now the rest of your code will only directly see an encryption object and what ever that object wants to show they they dig into it. take a look at my code for the encoder{}, specifically the two functions encrypt and decrypt. nearly all the data that those functions need can be found inside the encoder object. only needed a couple properties from the string object (length, split, and substr) and array (shift). So those two functions are well encapsulated inside the object, you could change all the code outside the encoder and so long as the specifications for javascripts string and array stays the same, encoder will purr along, and I won't have to come back and change it until I want a different encoder/decoder. encryptKey, code, and decode all need to wrapped into one object. You see, these functions work under the assumptions of whats in the encryptkey, it depends on them. say for example you make a new encryptKey where the each character translated to a 3 charater word instead of 5. Suddenly the decode function won't work cause its based on the assumption that its character translations will ALWAYS have five characters. decode depends on this specific encryptKey so you should encapsulate it into the encoder (you can because its not encapsulated to something else) its also a pet peeve of mine that if I only plan to use a variable only once inside a scope, I shouldn't allocate it to its own variable. you don't really need a var length = words.length; since its only used once in your code. so you could have gotten away with using it directly inside the for loop. your code will have less lines of code, use up less memory (even though thats not much of an argument here, it really does add up for specific data structures and larger applications) and you're less likely to have bugs in it (less code, less room for there to be mistakes).
  11. Could you post a link to the webpage with the problem so that we can see the entire issue you are having and thus provide the best solution tailored to you? Off the bat I can see you are using table tags to format your page, which could cause for some of the difficulties you have. but how serious depends on how you've set up the rest of the page and the CSS styles you're using. also this is not so much a Javascript problem as it sounds mostly like a CSS/HTML problem. catching the mouse via javascript can be done, but I'm not sure if you can map it to the playback speed of the player as every video player can be very different. A lot of questions can be answered and even more potential problems can be discovered if we can have a link to the page.
  12. Hadien

    Array problem

    Javascript uses references for non-primitive datatypes. when you had B1=A and B2 =A they both "point" to the same memory location of A. Javascript wants to save memory any chance it can so it uses direct references to avoid eating up memory for identical memory values. In order to copy the entire array to a new variable you'll need to manually walk through all its elements and assign them on by one, as dsonesuk demonstrates.
  13. Ingolme beat me to it. Its better to get more acquainted with object-oriented programming in general and not stay specific to any one language. That said, C++/C# and Java are the dominant languages when it comes to game dev. and much of the fundamentals that you would learn in C++ you can take to many many other languages, including javascript. the other way around is risky as javascript can lull you into a complacent style of programming by relying too much on letting Javascript handle the things you would worry about in other languages. and you may end up having to relearn some fundamentals when you move to something like C++. When you get more familiar with the basics of a language start using frameworks. frameworks save you a lot of work by preventing you from trying to re-invent the wheel and all the bugs that would come with it. Also after you got the basics down, grab books on design patterns so that you can better plan how you'll need to code your games before you even start the coding process, and a better plan makes for faster, more effective coding. Knowing the right design patterns can guide you to making compact, efficient, stable, and flexible programs as well as getting you into the habit of thinking in OOP, and not procedural programming. plus knowing design patterns is essential if you plan on making your own game engine, but that's a long, long way down the road.
  14. Hadien

    Debugging!

    oh got the dreaded else if chain, just a tip that if you find yourself making a chain like this there is usually a far more efficient way of doing this... by the way did you know that you have an encryption for "Z" in there three times? also what is the purpose the hey and lol variables? they're not used...here is a rewrite... var encoder={ encryptKey:{"a":"86832", "b":"11111", "c":"10101", "d":"13364", "e":"54272", "f":"48382", "g":"94702", "h":"47029","i":"74302", "j":"10111", "k":"13831", "l":"12434", "m":"13338", "n":"14352", "o":"15356", "p":"55316", "q":"37417", "r":"16478", "s":"99190", "t":"23374", "u":"23741", "v":"22473", "w":"26433", "x":"23454", "y":"57439", "z":"26143", " ":"00000", "A":"01111", "B":"00101", "C":"13304", "D":"50272", "E":"40382", "F":"9e702", "G":"47h29", "H":"7E302", "I":"10011", "J":"0a831", "K":"12034", "L":"00338", "M":"14052", "N":"15056", "O":"55016", "P":"30417", "Q":"16M78", "R":"921A9", "S":"G3542", "T":"230W1", "U":"2A473", "V":"26Aa3", "W":"23D54", "X":"57A39", "Y":"QB143", "Z":"KKFD3", ",":"mac00", ".":"B4[](", "+":"+1+2*", "-":"-----", "*":"*****", "/":"/////", "1":"1234q", "2":"ddh21", "3":"bbdjz", "4":"K1113", "5":"53FD3", "6":"11111", "7":"94932", "8":"W4322", "9":"E42SD", "0":"-000-"}, decryptKey:null, encrypt:function(inWord){ var output = ""; if(typeof inWord === "string"){ var explode = inWord.split("") while(explode.length>0){ output += this.encryptKey[explode.shift()]; } } return output; }, decrypt:function(inWord){ var output = ""; if(!this.decryptKey){ // if the decrypt key not built yet, build it now // we wait to do it here and not hardcoded it in to save on maintainence this.decryptKey = {}; for( var key in this.encryptKey){ //swap the key and value from encryptkey for decryptkey this.decryptKey[this.encryptKey[key]] = key; } } if(typeof inWord === "string"&&inWord.length%5==0){ while(inWord){ output += this.decryptKey[inWord.substr(0,5)]; inWord = inWord.substr(5) } } return output; }}// now the code to link the encoder to elementsvar ele = {};window.onload= function(){ var flipflop = false; ele.demo = document.getElementById("demo") ele.button = document.getElementById("but") ele.button.onclick = function(){ if(flipflop = !flipflop){ ele.button.innerHTML = ele.button.value = "Encode"; ele.demo.innerHTML = encoder.encrypt(ele.demo.innerHTML); }else{ ele.button.innerHTML = ele.button.value = "Decode"; ele.demo.innerHTML = encoder.decrypt(ele.demo.innerHTML); } };}; <p id="demo">I am full of really cool text.</p><button id="but">Encode</button> good thing here is that all that code is contained inside the encoder object, theres no huge elseif chain, and both encryption functions are super fast to run back and forth. plus I created that key only once, massively reducing the risk of having a typo, while making it really easy to change both the encryption and decryption keys at the same time.
  15. sounds like just css alone solves 90% of your problems. <div class="container"><textarea class="overlay"></textarea><img src="" class="underlay"></div> .container{ position: absolute;} img.underlay{ position: absolute; z-index:0; background-color: red;// or whatever color or background-image you want... width:100%; height:100%; top:0;} textarea.overlay{ position: relative; opacity: 0.5; z-index:1;} then use what ever code you already have to resize the textarea.if you want them to stick the window without scrolling away simply switch contiainer's position to fixed and play with top and left styles to put it were you want it to be on the screen regardless of scrolling.
×
×
  • Create New...