It is currently Thu Jun 21, 2018 5:13 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sun Nov 01, 2015 4:48 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6347
Location: Canada
I was trying to answer the question as if it wasn't hostile, for its own benefit. I don't really care if he was sincerely asking or not.


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 4:50 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
tokumaru wrote:
Could Espozo have meant that DRW shouldn't be using C if he's concerned about the cycle count?

I think that's what he meant. (jokingly)

And I believe rainwarrior's point is that C isn't as efficient so he has to be more conscious of his cycle counts.

The ultimate question is whether or not the specific game design sought will function in C. If it's not demanding enough to require assembly optimization, and produces the same end product, and it's easier/faster to make the game in C, then it's a win-win.

Perhaps, if he wants to avoid as much assembly coding as possible, checking cycle counts for routines would give him an idea of where he needs to optimize in ASM.


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 6:51 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3338
Location: Nacogdoches, Texas
darryl.revok wrote:
I think that's what he meant. (jokingly)

That's what I meant.

lidnariq wrote:
Espozo's also made it clear in the past that he doesn't understand the point of using any higher-level language, so it's not clear that his point is useful.

How does that make my point any less useful? Is it that I've never programed in a higher level language so I don't know how slow it really is compared to assembly? I've said this before and I'll say it again: If a dumb kid like me can do a somewhat decent job programming in assembly, I don't see why people find it that difficult. That is, unless it isn't that this is difficult, it's just that C is about 50x easier, which I doubt. (I imagine the core concept is the same) I just hate all the naysayers that say it would be "virtually impossible" to make a modern game in assembly. It would be a hell of a challenge, but impossible? Granted, most of the people I know who have made claims like this have never even programmed in assembly or know how to, so...

darryl.revok wrote:
Perhaps, if he wants to avoid as much assembly coding as possible, checking cycle counts for routines would give him an idea of where he needs to optimize in ASM.

I think I remember hearing that trying to fix converted C code for the NES is just about as difficult as writing in assembly from scratch.

rainwarrior wrote:
I was trying to answer the question as if it wasn't hostile, for its own benefit.

I can handle myself. :wink: If I were that concerned about what people thought of stupid comments like that, I wouldn't have posted them in the first place. :lol:


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 7:22 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6347
Location: Canada
Espozo wrote:
How does that make my point any less useful? Is it that I've never programed in a higher level language so I don't know how slow it really is compared to assembly? I've said this before and I'll say it again: If a dumb kid like me can do a somewhat decent job programming in assembly, I don't see why people find it that difficult. That is, unless it isn't that this is difficult, it's just that C is about 50x easier, which I doubt. (I imagine the core concept is the same) I just hate all the naysayers that say it would be "virtually impossible" to make a modern game in assembly. It would be a hell of a challenge, but impossible? Granted, most of the people I know who have made claims like this have never even programmed in assembly or know how to, so...


Arguing about what is possible is pointless. It's possible to write a modern game with a hex editor if you really want to (or in commercial development terms: how much it would cost). The question is why you'd want to. On the NES the reasons for using assembly are very clear (you need more performance and/or smaller code than the available compilers can provide). On a modern platform there would really be no advantage to an all-assembly approach. There is often an advantage to writing some parts of your program in assembly, and lots of modern games do.

On the NES, the largest project I've written in C was a musical project that took me about one day to write. I would estimate that the same task would have taken me at least a week in assembly.

A very simple example of why C is quicker to both read and write:
Code:
// C
tx = tx + vx;
if (tx < -500) tx = -500;

; 6502 assembly
lda tx+0
clc
adc vx+0
sta tx+0
lda tx+1
adc vx+1
sta tx+1
lda tx+0
cmp #>-500
lda tx+1
sbc #<-500
bvc :+
eor #$80
:
bpl :+
lda #>500
sta tx+0
lda #<500
sta tx+1
:

Which of these two pieces of code do you think took more time to write? Which one of these is more likely to have an error in it? Which one of these would be easier to make a minor change to? If there was an error in one of these, which ones would be easier to spot and fix?

Consider also that a scope of a whole program is thousands or tens of thousands times the size of this example. This is also a very small example, a lot of tasks you would need to do are much more complex.


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 8:54 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3338
Location: Nacogdoches, Texas
rainwarrior wrote:
A very simple example of why C is quicker to both read and write:

Most of the problem in this comes from the fact that you're using 16 bit numbers, but it still wasn't the hardest to figure out. 90% of my problems come with trying to think of a solution to something, not thinking of how to write it out, and C won't help there.

rainwarrior wrote:
If there was an error in one of these, which ones would be easier to spot and fix?

I'd think it would be easier to fix the one where you knew exactly what you were doing, because you made it from scratch. :/ I just always see these weird glitches in games and wonder how a human could have created any code that would cause some sort of weird side effect like that. I just don't like to try to give the computer too much to do with my code, because of... The WLA incident... (shudders)

Just saying though, if the code truly does convert that well, than what's with all this talk about how C generates inefficient code?


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 9:06 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2092
Location: DIGDUG
@DRW, Re:OP

I like to (in assembly) write to an unused bit of RAM just before and just after the action in question, and then run it in FCEUX with the debugger set to look for reads to that RAM address. It tells you how many cycles have passed between breaks.

In assembly:
Code:
inc $ff


In C:
Code:
++*((unsigned char*)0xff)


The debugger also tells you what scanline and pixel you are currently on.

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


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 9:15 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2092
Location: DIGDUG
Quote:
C generates horribly slow code


Probably obvious to everyone here, since we talk about this alot...but if you follow all the "optimization" C tips listed on Shiru's website*, the C code is only slightly less efficient (not counting the human inefficiency of the programmer having to type extra stuff to generate that more efficient code :wink: ).

* https://shiru.untergrund.net/articles/p ... s_in_c.htm

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


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 9:51 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3076
Location: Tampere, Finland
Espozo wrote:
rainwarrior wrote:
A very simple example of why C is quicker to both read and write:

Most of the problem in this comes from the fact that you're using 16 bit numbers, but it still wasn't the hardest to figure out. 90% of my problems come with trying to think of a solution to something, not thinking of how to write it out, and C won't help there.

Try to write (to completion) a couple of moderately sized programs, and you're likely to change your opinion. High level programming languages didn't appear by coincidence.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 10:04 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3338
Location: Nacogdoches, Texas
Ehh, maybe I would, but I just always feel like I write code in about the same amount of time it takes me to come up with complex solutions to problems that I am coding as I am thinking of them. (that's a mouthful) It's the same way in how I don't see why people freak out so bad about being able to type fast, because when I'm writing an essay or something, I take just as much time to think of words as I do to write them. Now, on the other hand, if I'm just copying writing down (and I'm not copying and pasting), it would be faster if I could just type faster, but that usually never happens. I just don't feel that the actual coding aspect of coding has ever really been a problem outside of tedious stuff similar to that. It's mostly been about like how can I dynamically allocate sprites in vram, using as little tile space, bandwidth, and processing as possible, and I don't think that C will automatically help me there.

Of course, I've never even coded in C, so I wouldn't know.


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 10:25 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
Espozo wrote:
I don't see why people freak out so bad about being able to type fast, because when I'm writing an essay or something, I take just as much time to think of words as I do to write them.


Not so much for composition, but for data entry and dictation work. Back when I was in school we were still using computers to copy text from written paper! :shock:

Secretarial work requires a minimum of 70 WPM, right?

I was hunting and pecking until I actually learned to type in high school, and I used computers a lot, so no telling how much time I wasted. I feel like kids now probably learn to do this in elementary school.

Quote:
I just don't feel that the actual coding aspect of coding has ever really been a problem outside of tedious stuff similar to that.


I'm sure there are better examples for SNES, but take NES for example. Doing multiplication or division would much much longer to think about, to type, to implement, in assembly versus C. Coding in C may produce a less efficient method of multiplication than you could make in assembly, but if you didn't need a complex program, you could type out multiplication in a single line of code.

I'm saying this, but I also plan to develop my game entirely in assembly. However, I would like to learn C someday if for no reason other than building game development tools.


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 10:41 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3338
Location: Nacogdoches, Texas
darryl.revok wrote:
Secretarial work requires a minimum of 70 WPM, right?

minimum of 70? I average around 45... :lol: Some kid at my school actually typed a paragraph at over 120 WPM before. :shock: (I saw it.)

darryl.revok wrote:
I feel like kids now probably learn to do this in elementary school.

Nope, still high school, or at least for me. I knew how to use a bulk Microsoft Office when I was about 6 though. (I went to a different elementary school than high school)

darryl.revok wrote:
I would like to learn C someday if for no reason other than building game development tools.

I just imagine actually writing something to conform with Windows would be a pain. (I assume that there's already been C stuff made for this before.)


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 11:04 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6347
Location: Canada
Typing speed is hardly the issue. More code requires more reading, more thinking.

This is not really that much of an issue when you're first writing a new piece of code. Usually at that moment you know what you want to do and how you're trying to do it. It's a huge issue when you need to go back and make a change somewhere in the middle, or when you made a mistake somewhere and you're not sure where, or you need to remember how 10 other pieces of code in other parts of the program have consequences entangled with how it works.

At this point, you need to remember exactly what that code is supposed to do, how it does it, and figure out what it is actually doing, and whether that's different than what you expect. All of these things are difficult to evaluate, and it's why skilled programmers are generally in high demand. If you wrote the code last week, last month, five years ago, or someone else wrote it entirely, you've got your work cut out for you.

The example I gave is just a small scale. To understand the real problem you have to imagine a whole program that looks like. Evaluating and understanding 1000 lines of C is much easier than doing the same with 10000 lines of assembly. This is just a plain fact.

You can't just look at a small example and say "well, I understand all those bits, that's easy". Of course it's easy to understand a small example. That's why it's a small example. That's precisely why I kept the example small. I wanted you to understand the code. The point wasn't whether you understood what a 16 bit comparison looked like. The point was YOU HAD TO SPEND SLIGHTLY MORE TIME READING IT TO KNOW THIS.


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 11:34 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1334
Espozo wrote:
Some kid at my school actually typed a paragraph at over 120 WPM before. :shock: (I saw it.)

Some guy near my house actually drove on the road at over 60 MPH before. :shock: (I saw it.)

I would like to point out that C's inefficiency, as perceived here, is strongly tied to the CPU in question, the 6502. It's been discussed before why it's a poor target choice for a C compiler. For many later CPUs with registers more appropriately sized for holding pointers that can cover the address space, the gap is narrowed strongly, and much more so when good optimization comes into play, which is another thing existing 6502 C compilers will have trouble doing effectively.

A big, nearly unavoidable disadvantage of writing anything in assembly is that it is locked to the instruction set for which it's written. You simply can not quickly bring a program written for the Z80 and bring it to the 6502 without substantial reworking. That's an easier example. What if you had to port from an IBM System/360 to a PDP-8? FORTRAN, COBOL, C, and all their friends before and after were developed partially to solve that problem. That doesn't mean assembly is without use today, but you'll find it more running (some) drivers on a modern computer, (some) embedded platforms, and (some) inner loops in game engines. With multiple decades of research in optimization on modern platforms, and innovations like LLVM, C is used for many of these things and in many cases will beat an assembly implementation of the same work.

I have a feeling this has strayed a bit off topic


Top
 Profile  
 
PostPosted: Mon Nov 02, 2015 7:19 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20164
Location: NE Indiana, USA (NTSC)
dougeff wrote:
I like to (in assembly) write to an unused bit of RAM just before and just after the action in question, and then run it in FCEUX with the debugger set to look for reads to that RAM address. It tells you how many cycles have passed between breaks.

So if the subroutine that you're trying to measure is run once or more per frame, how do you feed controller input to the emulated program between breaks?


Top
 Profile  
 
PostPosted: Mon Nov 02, 2015 10:18 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1334
tepples wrote:
dougeff wrote:
I like to (in assembly) write to an unused bit of RAM just before and just after the action in question, and then run it in FCEUX with the debugger set to look for reads to that RAM address. It tells you how many cycles have passed between breaks.

So if the subroutine that you're trying to measure is run once or more per frame, how do you feed controller input to the emulated program between breaks?

Perhaps in this case subroutines are run in a test case, and profiled outside of a gameplay context. Some scripting with an emulator and this specific memory write could result in a usable unit test suite.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group