Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Aug 2002
Online Last Active Today, 02:51 PM

#5128333 Why would devs be opposed to the PS4`s x86 architecture?

Posted by Nypyren on 02 February 2014 - 11:30 PM

Imagine you have just spent eight years and many million dollars developing a library of code centered around the Cell architecture. Would you be very happy to hear you need to throw it away?

Imagine you have spent eight years hiring people, and your focus has been to include people who deeply understand the "supercomputer on a chip" design that Cell offered, which is most powerful when developers focus on the chip as a master processor with collection of slave processors, and now find that all those employees must go back to the x86 model. Would you be happy to hear that those employees will no longer be necessary?

The parallel architecture is a little more tricky to develop for, but considering all the supercomputers built out of old PS3s it should make you think. Building parallel algorithms where the work is partitioned across processors takes a lot more of the science aspect of programming, but the result is that you are trading serial time for parallel time and can potentially do significantly more work in the same wall-clock time.

Why would you throw away such a library? There is still good money to be made from PS3 ports of new games, just like there was of PS2/Wii ports of 360/PS3 games.

If I had a large number of employees who understand how to write PS3 games very well, the transition to x86 is not a catastrophe. The primary change that occurred with the PS3 was it forced people without multicore processing experience to learn it. The new processors are not going back to a single-core model, so the primary skills that those PS3 developers learned are still relevant.

If I were smart, I wouldn't get rid of the existing engineers at such a company. I would spend some extra time and money to get them up to speed on x86-64, just like that spent to get them experienced on the PS3. Also, after 8 years of working together, these people will have become a well-oiled machine of teamwork, and that is just as important as their technical abilities.

If the hypothetical library is written entirely in assembly, then yes, I would be bummed (for various other reasons as well - why is it entirely assembly in the first place?!). But if the majority of the library was written in C or C++ with some small sections in assembly, then I would not be bummed.

#5128305 how to prevent save cheating? (for games where saving is NOT allowed)

Posted by Nypyren on 02 February 2014 - 08:34 PM

You could use an NTFS alternate data stream.  Very few people know about them, and it would take someone with a disk I/O monitor to realize what you're doing.


To make it harder for someone to notice the ADS in a disk monitor, you can put the ADS *on the folder itself* with the same name of a standard, red herring file in the folder.




Folder:Save1.dat   <- this is the ADS

Folder/Save1.dat   <- this is the red herring (just write a ton of random bytes to it to make it look encrypted)


The : and / will be hard to spot in the disk monitor and it may appear to the cheater that only one file is being accessed.


Here's the fun part:  Copy/pasting something with an ADS attached to it *does not copy the ADS*.  This means that if the player makes a backup of their save folder, then restores it later, the original ADS will either be unmodified or completely lost.



The most obvious downside is that people unaware of the ADS will not be able to make any kind of backup of it.  If they try to copy the game to a new computer, their game will be lost.


It's not perfect, but it'll probably confuse the hell out of people for a while.  Still, it only takes one person leaking the information about how it works for the technique to be ruined.

#5128297 Visual Studio Questions

Posted by Nypyren on 02 February 2014 - 07:59 PM

Even if something doesn't sound important to you, it's likely that Visual Studio needs it.  If you start uninstalling portions of it, it's very likely that Visual Studio will start giving you strange errors.  If you decide to do so anyway, you're on your own as far as help goes when things start acting up.

#5128279 Problem with loading a DLL through a code cave

Posted by Nypyren on 02 February 2014 - 06:14 PM

OK.  Your first order of business is to debug the program to find out why it's exiting prematurely.

#5128035 how to prevent save cheating? (for games where saving is NOT allowed)

Posted by Nypyren on 01 February 2014 - 04:34 PM

It only takes a single person figuring out how your save system works and telling the entire world about it to ruin any client-side protection you try to use.

The only way to prevent the player from manipulating their save data is to perform all important actions (even gameplay) on a server you control. In other words, the way an MMO does it. The cost of actually doing this scales with the number of players you have, even if the game itself isn't an MMO.  It will also piss off the players, because they will have to be online all the time.

It all boils down to:  How much effort and money are you willing to spend to stop cheating?

#5127822 human intelligence

Posted by Nypyren on 31 January 2014 - 03:15 PM

I repeat the challenge: Design a test of memory prowess where you think you can do better than a laptop.

Ow darn you, now you are compelling me to prove something that's so obviously wrong on all accounts biggrin.png
I can remember events from my childhood. That's 40 years. My grandparents can remember things from theirs, that's 85 years.

Both of you are oversimplifying the situation. If you only pick a *single* requirement, either human or computer can beat the other at anything! The reality though is that both humans and computers have to fulfill a LOT of requirements at the same time. Human requirements are dictated by nature. Computer requirements are dictated by Humans.

Just like a computer loses its data due to software bugs, media decay or hardware failures, Humans forget things naturally all the time: Do you remember everything you learned from every lesson in school? How long can you remember things that you never use?

#5127302 Problem with loading a DLL through a code cave

Posted by Nypyren on 29 January 2014 - 04:08 PM

I believe Windows calling convention allows EAX, ECX and EDX to be used as volatiles (i.e. the called function will not back them up, and the caller must assume they got clobbered and back them up if they need to be preserved).  You should save all three just in case.

#5126379 human intelligence

Posted by Nypyren on 25 January 2014 - 04:24 PM

It seems to me that humans and computers currently are good at what the other one's bad at:

Vision/Hearing (humans MUCH better than computers in all aspects):
- Humans have a massive parallel signal processing network which recognizes an astounding amount of different kinds of features in visual/audio input VERY quickly.
- Computers have a tough time with this because we don't have hardware that's as good as human eyes/ears yet, parallelism that's massive enough to process the signal quickly, or the wide variety of different types of feature recognizers that humans have.

Control (robots are better in controlled situations, humans are better in novel situations):
- Robots are better for speed and precision.
- Humans are better for adaptation (for instance, if a servo/muscle stop functioning, robots often cannot perform their task anymore, whereas a human can probably figure out an alternate way to perform the task)

Natural languages (neither human nor computer is very good at this):
- NLP systems have thousands of individual systems all working together to handle typos, solve ambiguities, reason about likely meanings, and learn new meanings on the fly. Humans have lots of trouble getting their intended meaning across to other people. Computers have trouble dealing with imperfect grammar, meanings, ambiguity, error correction, and learning.

Logic and reasoning:
- Computers quickly follow the rules they're given, and have problems when the rules they've been provided aren't sufficient. Humans are slow at following rules but can adapt to cases they haven't seen before. Computers won't make mistakes. Humans make lots of mistakes.

- Computers are much better in all aspects.

System Interop:
- AI research has typically been approached one isolated piece at a time (vision, NLP, control, logic/reasoning, planning). Lots of complex AI problems need to be solved by having the different systems help each other out, but generally AI researchers focus only on their individual problems without seeking to interop with other fields. For example, when attempting to handle NLP input, you won't get very far without a logic/reasoning system to help resolve ambiguities and likely meanings. When handling vision, recognizing characters from a language requires dealing with different orientations/mirroring/perspective changes, stylistic variations, and reasoning about what a heavily corrupted glyph probably is based on the other glyphs around it.

#5126247 Branching in switch statement

Posted by Nypyren on 24 January 2014 - 09:14 PM

<Unreal Tournament Announcer Guy> RAMPAGE!!

#5126245 vc 2008 intellisense calling my class function some thing else

Posted by Nypyren on 24 January 2014 - 09:08 PM

Ah yes. Welcome to Win32's #define hell.

You have a few options:

1. Put #undef GetObject somewhere after your windows headers get #included. This will remove that macro and stop your function from getting renamed.
2. Rename your method to something that isn't #defined.
3. Isolate your Win32 #includes so they only make a mess in a small portion of your code that's easier to handle.
4. Make your own personal copy of those Win32 header files and remove the #defines from them so they don't make a huge mess of things. You will need to move such edited headers into your project so that anyone who uses your code gets these changes as well. I wouldn't necessarily recommend this because it's quite a bit of work and probably against some Microsoft EULA somewhere. You will also need to remember to call the appropriate function depending on your multibyte/unicode setting.

#5126190 Branching in switch statement

Posted by Nypyren on 24 January 2014 - 03:10 PM

Beginners may be reading this thread, so I feel like it's time to deal with some misinformation.


and also applying :, which seemed to me as a keyword, not an operator...

You should learn about how languages are parsed to more clearly understand what you're talking about. The colon in a switch statement is a 'token' which is an integral part of the case statement syntax, and is neither a keyword nor an operator. Guessing what something means without doing research to find out if your guess is correct or not isn't a very good way to learn programming.

Maybe it even produces goto instructions when compiled, do not know, I suspect switch of anything. When I was learning to program, I had to have exact knowledge of every instruction. its definition and abstract.

That kind of knowledge can be gained as simply as placing a breakpoint on a C/C++ switch statement and opening a disassembly window to see what assembly instructions are present. It's no use trying to speculate or guess what could be happening when you can ACTUALLY SEE what's happening if you look in the right place.

I pretty soon discoverd that switch is an instruction that has nothing exclusive to the rest of instructions...

The jump table built by switch statements in some languages is not possible to reproduce in those languages without using inline assembly. No language I know of allows you to declare an array of intrafunction labels and say "goto array[labelIndex];" (that's pseudocode of what a single-lookup table-based switch does in C and C++).

The closest you can get in C and C++ is an array of function pointers, but those incur the cost of calling the function and passing parameters. With a jump table, you don't leave the function, so you don't incur any function call overhead. The compiler is also much more free to rearrange the control flow graph and share common groups of statements in separate switch blocks.


I realize that English probably isn't your native language, but you should really make sure you get your terminology correct. Having discussions with other programmers becomes difficult if everyone decides to use words that mean different things to everyone else.

#5126049 Branching in switch statement

Posted by Nypyren on 24 January 2014 - 02:13 AM

I think he means that he's sick of different languages having completely different rules and behavior for switch statements. (It seems like a pretty minor complaint to me once you learn which style a particular language uses.)

His first post describes how switches work in Javascript, PHP and AS3 (and perhaps other languages that don't care about being optimal). A switch statement in those languages are just syntactic sugar for an if/else chain.

You can even do ridiculous things like this (which I have personally seen in professional AS3 web games)...
switch (true)
    case x < 0:
    case y < 0:
    case x >= width:
    case y >= height:

...which is utter blasphemy for people with C/C++ backgrounds. I haven't seen anyone crazy enough to find out whether assignment expressions work within case statements in those languages, but I would not be surprised.

In C and C++, the compiler can build low-level jump tables if it meets certain criteria, otherwise it builds an optimized if/else binary tree. Case statements cannot be full expressions like in JS/AS3/PHP.

In C#, most of the same behavior from C and C++ carry over, except that complex fallthroughs must be made explicit by using 'goto case' (this is an attempt to prevent bugs with forgotten breaks). Case types are restricted to consts/literals like in C and C++, but strings are OK as well. .Net's x86 JIT step can produce low-level jump tables like C and C++.

The more case statements, the more performance increases in the efficiency-conscious languages compared to what you get in the "let's do it the simple way" languages.

#5125985 Branching in switch statement

Posted by Nypyren on 23 January 2014 - 04:08 PM

you do not have to write  a break in case's body. Runtime behaviour of switch is that it examines every case condition from first-top most to next, and if it finds fitting condition it enters the case's body, and if the break command is present it leaves switch{} body at that point, not examining other conditions. If no condition is met, the last case: should be so called defaut:. This is body that will execute for any value, so it should be last, to assure it is executed for any not found value (most usualy).
lets move to what you are after though I see it shady, but I believe it is this:
case somevalue1:
case somevalue2:
case somevalue1:
case somevalue2||somevalue1:
somevalue2 will run Function2() always, somevalue1 will run   Function1(); Function2(); - in both those example variations.
For the nature of switch statement, I avoid using it , I have actualy never used it. I rather write nested if's in case of more skip-branching. So I do not know for sure that missing break will result in evaluating next case, or , entering it. Someone might confirm the second example.

Specifically to C#, you cannot 'fall through' like you can in C and C++, EXCEPT if the starting case statement is completely empty.

In other words:
// This will compile in C#, C and C++:
switch (v)
  case 0:
  case 1:

// This will not compile in C#, but will in C and C++:
switch (v)
  case 0:
  case 1:

#5125922 Branching in switch statement

Posted by Nypyren on 23 January 2014 - 11:58 AM

What I actually wanted was to jump from one case statement to another case statement in one switch...

Yes, you can do that! And unlike the above examples, it's perfectly acceptable to do this if you want to:
case somevalue1:
	goto case somevalue2;

case somevalue2:

#5125744 Branching in switch statement

Posted by Nypyren on 22 January 2014 - 05:02 PM

No. If you jump to another switch, you will leave your current switch by definition. And you won't be able to jump back because two switch statements cannot both contain labels that are in scope of the other.

It sounds like a really bad idea to me either way.