Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Feb 2009
Offline Last Active Mar 07 2015 12:32 AM

#5196754 Programming Laptops (-numerics pad)

Posted by on 07 December 2014 - 02:18 AM

I use a ThinkPad W530 for my programming at home (at work, I don't have a choice in hardware). Most ThinkPads (if not all) don't have a numeric keypad.

#5190835 The intersection between cubic Béziers

Posted by on 02 November 2014 - 08:58 PM

I started sweating just reading that function call.

#5188020 How to remove GET variables from URL in php

Posted by on 19 October 2014 - 01:20 PM

GET, then store in session variables, then redirect to an export script that reads them?

#5174865 Apparently, no so simple Math.....

Posted by on 19 August 2014 - 04:43 PM


I see your min/max ops and raise you blocking logic!

int damageTaken = attack - defense;
if (damageTaken > 0)
    health -= damageTaken;
    Console.WriteLine("Attack blocked!");

In pokemon, all offensive attacks do at least one damage even if they should be 100% negated(except for move types that are uneffective against the opponent types(i.e ghost/normal iirc))

so, let me just fix chubu's real quick:
health -= max(attack - defense, 1)

I was just about to say that. :)


Then make two?

If you find yourself saying that, consider making it a method of the class.

#5173186 "No such file or directory" but it's obviously there!

Posted by on 12 August 2014 - 04:01 PM

They're included in a couple of files, all of which include both.

Edit: with the exception of Mat3x3, which only includes Vec2.

Don't forget that the paths are relative to the file being included, not the current working directory of the build process, so be sure to double-check your paths; if the path is specified wrong, it may attempt to check the path relative to the paths in your include path environment variables or commandline switches. This would cause it to work with the -I switch, but not otherwise, if this is the problem.

#5169642 What is a potatoese?

Posted by on 27 July 2014 - 07:05 PM

Hardware acceleration removal would mean no OpenGL/DirectX is being used?

Yes, only as an after-thought for speed if enabled during build.


Usage of Javascript means that is another language used besides the core C++ , so that is the reason that you cannot agree to the subset of my statement "it's simply C++"?

"Usage of another language means that another language is used, so is that the reason that you cannot agree to my statement that only one language is used?"



Did you seriously skip the whole article, looking for the first link? The fact that it uses Cairo is irrelevant: it is what it does, not how.


Menus and similar "Control Graphical components" are usually implemented using other libraries, but can be implemented using one of (many?) rendering APIs like OpenGL and/or DirectX.

What if I told you that window toolkits like GTK+ don't need to and probably don't use OpenGL/Direct3D? 3D hardware rendering is unnecessary.

#5169626 What is a potatoese?

Posted by on 27 July 2014 - 05:36 PM

In the sense that it's simply made of C++ and OpenGL/DirectX,

You can compile Firefox with hardware acceleration support removed, voiding your claim.
Note that since a lot of the Firefox UI and preference engine uses JavaScript, this voids the claim that C++ is all that's used to write the program.

rendering( graphical interface components, images, fonts ,ect ect)

A lot of the font rendering and GUI is GTK+ in Linux. Look up windowing toolkits!

After having read the above, can you confirm that, or am I missing/misunderstanding something?

Please, please look up any of the terms in this thread in Google. It sounds like you decided that Firefox is just C++ and Direct3D/OpenGL, and you're going to repeat your question until we agree with you.

#5169583 What is a potatoese?

Posted by on 27 July 2014 - 02:02 PM

The case with a VM is additional for more unusual usage.

The application runs in a VM the same way it does on a normal physical computer. You have the option to turn off hardware acceleration right now, so it isn't unusual if you have a driver bug, or something.




BUT, on the VERY BASIC and CORE it's just C++/etc and OpenGL/DirectX.

That ignored everything I just said.




Do tell me otherwise if that is not the case though.

A cursory Google search will tell you what it is. It is (in this case) the process of rendering a 3D scene without using hardware acceleration, done completely in software. In other words, performing the tasks of OpenGL/Direct3D without the use of hardware acceleration. The Mesa library is a good example.


Edit: Also, the use of toolkits like GTK+ is of considerable importance.

#5169564 What is a potatoese?

Posted by on 27 July 2014 - 01:04 PM

I needed only a simple answer like "SimonForsman" pointed out, it uses C++ and OpenGL.

Firefox uses C++ GTK+ and OpenGL on Linux atleast

Not quite what he said, and it sounds like an oversimplification of his post.


Based on that I can confirm that browsers(internet, typical/graphical) are indeed simple applications utilising DirectX/OpenGL and C++(or other programming language(s)).

This isn't accurate. When I run Chrome in a VM, I have to disable hardware acceleration to keep it from drawing incoherently. Thus, without hardware acceleration, it is using a software renderer. That contradicts your conclusion that Direct X or OpenGL are in use at all times. Mozilla has long since had the ability to use DirectDraw or X Render, whether or not it's recommended in the presence of other, more efficient APIs. This is another contradiction of the idea that these Direct X and OpenGL are the only two APIs used.

#5169534 What is a potatoese?

Posted by on 27 July 2014 - 11:16 AM

Let me ask the remainder of the question, what rendering is used for Firefox? (thanks for the links, but I wouldn't spends hours or days looking at the source files just to be able to tell)

Also note that a lot of browsers support other acceleration, like DirectDraw, and have the capability to turn off hardware acceleration if it turns out to be buggy, doing everything in software. There may not be one answer for you.

#5162928 Help with the math on this?

Posted by on 25 June 2014 - 10:42 PM

If you are not interested?

No one said I wasn't interested. To be honest, I never thought of it that way.


it is NOT useless to fill in more information about a topic.

Never said that.


Of course, if Paradigm Shifter was attempting to build on fir's answer with more information for the sake of knowledge, then that's well and fine.

I have no idea where you are getting the idea that I am against his insight.

#5158643 Is working in terminal/console really a waste of time?

Posted by on 06 June 2014 - 02:47 AM

After tutoring several students in C++, Java, and x86 ASM, the thought of trying to have them learn GUI programming at the same time terrifies me. These beginners don't understand pointers, they're unsure of how a for loop works, and they think a bit shift is a geological term. I feel that it would take them twice as long to make even a simple "guess the number" or "tic-tac-toe" game if they're thrust into using a GUI immediately for these reasons (off of the top of my head):

  • They now must learn about memory management way early, before they can even get any output drawn (unless they lucked out with a language that has garbage collection).
  • They have to learn not just the core language, but also the API of a graphics library that makes use of more advanced features, and manage linking and dependencies.
  • They are force-fed inheritance lessons for many languages; if I want to watch for input, I have to add an event listener object, and have it inherit from a standard base class? What is "inherit", and what's a "base class"? I didn't even get much more than a "hello, world" yet.
  • Unless they plan to learn how fonts work to print text, there's going to be a lot of taken-for-granted boilerplate code and hidden default values being used. I've experienced that teaching people right away, "Do not pay attention to this. It is magic," only discourages them, thinking that they'll never understand it all, it has a mind of its own, and that they'll never actually need to know it. It's the kind of training that teaches them to start every source file with:
    #include <iostream>
    #include <string>
    #include <windows.h>
    #include <conio.h>
    #include <fstream>
    #include <iomanip>
    using namespace std;
    whether any of it is actually needed or not, because they had problems once and that made it go away, so they may as well put it everywhere.

If you aren't a beginner to programming, but only to game programming, I interpret this thread as not applying to you, as you should already know these basics.
Furthermore, to suggest that rather than teach people from the ground up with the terminal/console, or scare them with GUI programming and its requisite complexity, we give them a very high-level scripting language, that may not be beneficial. If they want sounds and pictures now, okay, fine. If they actually want an understanding of how things work, it won't be at all obvious (what's a hash table look-up, and why is my loop slowing to a crawl by not caching the property value?); low-level knowledge spots anti-patterns in high-level code. If you want to start someone on high-level scripting languages, plan on having them go back and learn a low-level language later before they actually start producing their life work, unless you're banking on them striking it rich with their Alice, Scratch, or DesignBlocks skills.


#5158636 Checking if a bit is set in a byte

Posted by on 06 June 2014 - 02:07 AM


I do it like this, but I'd have the enum in it's own header to be reused

enum struct BIT{
	_1 = 0x1,
	_2 = 0x2,
	_3 = 0x4,
	_4 = 0x8,
	_5 = 0x10,
	_6 = 0x20,
	_7 = 0x40,
	_8 = 0x80,

int eg = 20;

if(eg & BIT::_5){


That forces people to be one-indexed for bit enumeration; sometimes, being zero-indexed is easier, when you use that index directly as the number of positions to shift. Or, put another way, if the index is the exponent of 2 for the value represented by the bit at that index.

#5155163 A Rose by Any Other Name...

Posted by on 21 May 2014 - 08:39 PM

How about on case-sensitivity?

...That doesn't quite answer the question. As outlined, there are other languages (disregarding accents) that have different character sets that can be substituted for each other (barring grammatical convention). When we think "case-insensitive", we tend to think of common Germanic, Romance, Indo-European, etc. languages only. There's a potential for this behavior in other languages that we intentionally ignore. It seems rather strange to have this core kernel feature that is only effective for a portion of the languages spoken by the user base, and thus, I don't feel that it belongs in the kernel. It seems like an esoteric part of the time period where a subset of the English alphabet was all we cared about, with everyone else as an after-thought.


I think that's a different issue - isn't that just a matter of the filesystem not actually enforcing full case-insensitivity?

swiftcoder nailed this one precisely - I frequently dual-boot between Windows and Linux. I could mount my NTFS partition right now and create two files that differ in name only by case. It doesn't seem wise to pretend that this can't happen (though, I know it will forever stick around due to the compatibility issues of ever changing it).


My stance is that case-insensitive filesystems (for those language for which case is actually a relevant concept) are more convenient to the user than case-sensitive filesystems.

Though I'm a developer, I'm also a user: I find it a big pain. Nothing like trying to find something you've referred to, only to have trouble finding it because it wasn't named with the case that you've always that it had. I find case-sensitivity to be very brittle; any break in the case-sensitive seal, and all hell breaks loose. Often, as a user, I find that software doesn't do case insensitivity properly.


This reminds me of a bug in the product inventory software I had written at work. To make life easier on the people entering the data for product listings, you could enter a partial name, and it would show a drop-down list of possible matches based on a case-insensitive search. Well, it would search case-insensitively, and it would find it for display, but if you didn't click on it and have it fill out the correct name for you, and you didn't type in the correct case, it would pass the check to see if it is in the database (case-insensitively) after submitting, but it would choke when it accidentally looked up the ID of the product in a case-sensitive manner, resulting in several listing records having null product IDs, failing after the input was already validated.


My point to the story is that if you ever decide to uphold case-sensitivity, your workload is now doubled: if you slip up even once and do something in a case-sensitive manner, it may produce serious bugs that defy expectations, especially if it fails on the backend, after the input's already declared valid.


This is why I feel that case-insensitivity should be in the top-most layer, facing the user, and out of the core:

  1. It is only useful for part of the user base.
  2. Not all users enjoy the feature; many hate it, especially those that spend more time in other operating systems.
  3. It is very brittle.

#5154516 A Rose by Any Other Name...

Posted by on 18 May 2014 - 05:21 PM

That used to be (still is?) an issue with "portable" webservers, too. If someone named the page you were trying to read ThePage.htm, the webserver would show a 404 because you would of course try to get http://example.com/thepage.html (which would fail on two accounts, the capitalization and the extension). But hey, why do you have to do the dance for the darn computer? It's not like rocket science to figure out what you want if there is just one name with the same (except capitalisation) basename and an alternate spelling of the extension.

On one hand, users shouldn't be exposed to bare file path URLs, with modern URL rewriting and the majority of pages being accessed through links from other pages.




On the other hand, I don't care whether a file that I want to open is spelled foobar or FOOBAR or FooBaR, there exist no other files with alternative spellings, and I'm just interested in opening the darn thing, regardless of such sopistries whether "F" and "f" are binary identical or not. laugh.png

Whoops, forgot you were only talking about file names, sorry.


I've always felt that the case-insensitivity in file names was a relic of an outdated era (like using FAT32, with its case-insensitivity, but case remembrance), and was due to the constraints of the technology (and the convention that followed from its use), rather than conscious design decision on the OS' part. Case sensitivity also reduces the number of possible file names by a great factor.

Now, where do we draw the line on case-sensitivity? What about diacritics? Should an 'ñ' and an 'n' be considered the same letter in a case-insensitive file system? A lot of people make no distinction between case-sensitive and accent-sensitive. I wouldn't want to be the poor sap that was writing a Spanish application that looked for "año.jpg", and found "ano.jpg". How about Japanese? I found it useful to be in a Japanese book store, and look for a particular book by typing its name in katakana in the search terminal; I know how the title is read, but I can't write it in kanji. However, for file names, that's a poor solution (see an example of this, using romaji instead of katakana, here: http://www.cjk.org/cjk/reference/japhom.htm#2); there are many different words and phrases that wind up being homophones, so being able to type a file name in katakana or hiragana means that you'll hit serious ambiguity with several different file names of different meaning corresponding to the same phonetic sounds that can be expressed in katakana or hiragana. So, while this is suitable for, say, a book store search terminal to allow illiterate people like me to find literature, I find this to be a poor solution for a file system. There are many other languages to consider in this regard.


In short, our notion of file system case-insensitivity generally only apples to ASCII English characters, and, in my opinion, is a hold-over from when even that was more than we wanted to or could care about. It's a slippery slope, without considering the implications of anything that isn't English, leading to an inconsistent representation of file names. Furthermore, we already know it is possible to encounter "File.txt" and "file.txt" at the same time in a lot of filesystems; using a scheme that can't deterministically pick one or the other just asks to be bitten by this.