thefox wrote:
65024U wrote:
And seeing the performance hit for C on a NES.....I think it's just too insane. 6K cycles for only a few commands? Ickkk.....and anyone who knows C should be able to pick up assembly IMO.
Now I don't want to come out too defensive, you're entitled to your opinion, but I don't agree with you.
1) You're refering to the figures I posted at NintendoAGE? I don't know where you get "only a few commands" from... The code checks controller state, updates sprites, physics and checks collisions in update_frame(), hardly "only a few commands". Also there is room for (algorithmic) optimization.
2) Even if there IS a performance hit (of course there is compared to assembly, unless the assembly is programmed really poorly), it doesn't matter UNLESS it matters. What I'm trying to say, it doesn't matter how much CPU time it uses if it does the job in time. Premature optimization is the root of all evil.
3) "and anyone who knows C should be able to pick up assembly".. but assembly isn't C. C code is more maintainable, more readable, faster to code etc etc. To put it short, I think you're missing the point.
As someone with many years of experience in both C and asm, I have to agree 99% with thefox's three points. Being able to program in pure asm has a certain "coolness factor" to it. However, pure asm is not always the right answer. There are different tools and different jobs. Sometimes several tools are equally valid choices, and sometimes only one tool will do (and sometimes no tools work).
My only issue is with "pre-mature optimization". Some people (ok, my former boss) are militant about deferring optimization until really late. The problem is that by then the project becomes too difficult to optimize (sometimes). Choosing proper data structures at the beginning will go a long way to ensuring that your project will be optimal enough later. For my personal projects I tend to profile, optimize and refactor my code many times as I develop it. If nothing else, I'll make it crunch a large data set while running inside a profiler so that at least I know where it is spending its time.
That being said, I still have not experimented with using C (or any other high-level language) in a NES project. I liked the idea of NESHLA, but I did not like its implementation or syntax. I write all of my asm in ca65, so throwing in cc65 should not be too difficult.