News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Do Game Developing Companies rely upon Hex Editors?  (Read 4633 times)

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Re: Do Game Developing Companies rely upon Hex Editors?
« Reply #20 on: May 11, 2016, 01:17:27 pm »
I think the halting problem is irrelevant. If there is a problem it is about brute force being slow more than something being impossible.
Yeah, that was the one thing he said where I wasn't sure why he said it.
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

FAST6191

  • Hero Member
  • *****
  • Posts: 2623
    • View Profile
Re: Do Game Developing Companies rely upon Hex Editors?
« Reply #21 on: May 11, 2016, 02:09:41 pm »
That paragraph was more of a curio, and natural follow on from all the rest if we were still talking about systems using 3d, and that in particular was meant more as a "if you are curious then..." rather than I am too lazy to type it out, though I take your points.
If you find a good explanation (the predictive branching the core2 stuff brought to the fore does well here)  it covers code flow/execution paths pretty well, or indeed does fairly well at bridging high level loops/branches with low level concepts. Save for recursion it is not as bad as pointers for messing with heads of new programmers but I have seen people struggle, and equally if HTML is to be considered a large part of programming experience of the OP then it is not like such endeavours would have covered loops all that much.

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Re: Do Game Developing Companies rely upon Hex Editors?
« Reply #22 on: May 11, 2016, 02:52:51 pm »
That paragraph was more of a curio, and natural follow on from all the rest if we were still talking about systems using 3d, and that in particular was meant more as a "if you are curious then..." rather than I am too lazy to type it out, though I take your points.
I was (and am) impressed by the sheer scope of your response. I couldn't really add anything that you hadn't at least started to say something about. I could expand. But what's the point? But the "halting problem" was the only "which part isn't like the others?" to me. Doesn't make it wrong. I just wasn't sure why it was there.

If you find a good explanation (the predictive branching the core2 stuff brought to the fore does well here)  it covers code flow/execution paths pretty well, or indeed does fairly well at bridging high level loops/branches with low level concepts. Save for recursion it is not as bad as pointers for messing with heads of new programmers but I have seen people struggle, and equally if HTML is to be considered a large part of programming experience of the OP then it is not like such endeavours would have covered loops all that much.
I'm working heavily on writing scalable software. This means (in broad strokes) that using a 4-core CPU will provide twice the performance as using a 2-core one would, and that using a 16-core CPU will provide 8 times the performance. It sounds "obvious," to those without much experience here. But almost everyone using .NET and threads really have no clue, here. They imagine that using separate threads does the trick. But it doesn't. Especially if they have any important data structures for which they use any kind of lock. All that really happens with a very expensive server board sporting four 16-core CPUs is that they have 64 cores all tied up at the same serializing bottle-neck waiting for the same resource and the whole thing performs not so much better than a single core. Look up software transactional memory to see a part of what I'm doing with x86 servers. There are other important theoretical aspects (data structure design figures extremely important here.) But if you design things for scalability, then you actually can achieve quite a lot. I know of only a handful of people doing this, though. Most just use the usual means provided by the usual .NET facilities and honestly have no clues at all. And as a result, their products don't really perform when throwing lots of cores at it. It really takes a new mindset to get that to work well.

[I worked on chipset testing and CPU design at Intel, so I'm pretty well aware of branch prediction and most of the other details operating in the x86 family. Up to the P2, anyway. Those things did single-cycle parallel decode of up to three instructions, converting them to RISC instructions, the use of a ROB or re-order buffer, out-of-order execution, branch prediction, multiple functional units that could be used in parallel (two integer ALUs, two floating point ALUs, etc), and how these things were "retired" as well. (And some of the "approaches" used to deal with sad, earlier design limitations -- the push pop floating point stack, which was a serious bottle-neck itself, for example.) There's a lot more to all this. But probably no point writing about it here.]

Anyway, things are interesting today. I'm enjoying all this.
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

linkncb16

  • Restricted Access
  • Full Member
  • *
  • Posts: 159
  • They actually updated this site. Hallelujah.
    • View Profile
    • Patreon
Re: Do Game Developing Companies rely upon Hex Editors?
« Reply #23 on: May 11, 2016, 05:26:55 pm »
Wow. I understood almost none of that so I hope it's not too important for NES hacking!  :laugh:
So do modern systems such as the Wii U run on common code like Javascript?
Final Fantasy Redux is complete! Download

Klarth

  • Sr. Member
  • ****
  • Posts: 484
    • View Profile
Re: Do Game Developing Companies rely upon Hex Editors?
« Reply #24 on: May 11, 2016, 05:34:18 pm »
But if you design things for scalability, then you actually can achieve quite a lot. I know of only a handful of people doing this, though. Most just use the usual means provided by the usual .NET facilities and honestly have no clues at all. And as a result, their products don't really perform when throwing lots of cores at it. It really takes a new mindset to get that to work well.
Scalability is huge in scientific computing where most programs are made in FORTRAN or C/C++. Unfortunately, a lot of the algorithms in the field I published in (computational quantum chemistry) are not able to perform efficiently in parallel past 64 or 128 cores, depending on what your definition of "efficient" is. So institutions that do this work typically buy a supercomputer with 1000+ cores and split up the server into multiple jobs across multiple research groups. This is a bit frustrating because it's a much more expensive approach than what would be possible with GPU or even Intel Xeon Phi if the algorithms could work efficiently in parallel. Additionally, calculations can take days or weeks even on a large number of CPU cores.

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Re: Do Game Developing Companies rely upon Hex Editors?
« Reply #25 on: May 11, 2016, 05:41:19 pm »
Wow. I understood almost none of that so I hope it's not too important for NES hacking!  :laugh:
If you are referring to my writing, no.... software transactional memory, threads, locks, and so on have almost nothing at all to do with NES hacking!  :)

So do modern systems such as the Wii U run on common code like Javascript?
I honestly don't know. I have a Wii U here. But I've not considered what game developers (isn't the Wii U now cancelled for the US?) use to write code for it. This link, Develop games for Wii U with Unity or HTML5, suggests that they use Unity for their engine. (They pay the license fees.) That means C++ to me as the language you need to know about. Not JS. But what do I know? I've not attempted any Wii U code. Looks interesting, because Nintendo doesn't charge a fee. (Though they say you need to buy a development system, which costs money, and that you need to prove to them that you can keep what you get from them confidential.)

May 11, 2016, 05:46:51 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Scalability is huge in scientific computing where most programs are made in FORTRAN or C/C++. Unfortunately, a lot of the algorithms in the field I published in (computational quantum chemistry) are not able to perform efficiently in parallel past 64 or 128 cores, depending on what your definition of "efficient" is. So institutions that do this work typically buy a supercomputer with 1000+ cores and split up the server into multiple jobs across multiple research groups. This is a bit frustrating because it's a much more expensive approach than what would be possible with GPU or even Intel Xeon Phi if the algorithms could work efficiently in parallel. Additionally, calculations can take days or weeks even on a large number of CPU cores.
Fortran would be the go-to language. C and C++ don't offer the the same "guarantees" that FORTRAN offers, so optimizers for C/C++ are hampered in what they can do. (Used to be, anyway. See Why Physicsts Still Use Fortran (2015). Plus, a lot of early work went into FORTRAN. (For example, the Bulldog compiler for VLIW architectures investigated a host of interesting and useful ideas using Fortran.)
« Last Edit: May 13, 2016, 12:50:17 am by jonk »
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me

dougeff

  • Sr. Member
  • ****
  • Posts: 359
    • View Profile
Re: Do Game Developing Companies rely upon Hex Editors?
« Reply #26 on: May 11, 2016, 06:34:40 pm »
Re:Unity

I thought unity games  were programmed in C# and/or JavaScript.

I'm still learning C#, with hopes that one day I can program a game in unity. (C# is very similar to C++).

nesdoug.com -- blog/tutorial on programming for the NES

jonk

  • Sr. Member
  • ****
  • Posts: 273
    • View Profile
Re: Do Game Developing Companies rely upon Hex Editors?
« Reply #27 on: May 11, 2016, 06:44:50 pm »
Re:Unity

I thought unity games  were programmed in C# and/or JavaScript.

I'm still learning C#, with hopes that one day I can program a game in unity. (C# is very similar to C++).
You may be right about that. Unity is new to me. So thanks for the clue! I only looked at a line or two from a screen shot. So I'm sure it's my mistake and I should have looked further.
An equal right to an opinion isn't a right to an equal opinion. -- 1995, me
Saying religion is the source of morality is like saying a squirrel is the source of acorns.  -- 2002, me