It is currently Wed Oct 18, 2017 10:47 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 100 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next
Author Message
PostPosted: Wed Nov 09, 2016 5:21 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2962
Location: Tampere, Finland
rainwarrior wrote:
thefox wrote:
What video? If you're talking about https://www.youtube.com/watch?v=CdJOSfK1ja0, cc65 produced close to optimal code (when optimizations were enabled) for the simple "hello world" of setting the border color on C64.

The first example in that video gets optimized by CC65 fine, but there's a second example near the end that doesn't and I think is actually a good demonstration of one kind of thing it can't do that GCC can.

Yeah, that one is valid.

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


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 5:30 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 555
rant:

WTF is with the current kids making videos for everything that would be better as text. No, I'm not wasting 13 minutes watching that.

end rant


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 5:47 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1401
rainwarrior wrote:
The first example in that video gets optimized by CC65 fine, but there's a second example near the end that doesn't and I think is actually a good demonstration of one kind of thing it can't do that GCC can.

Wasn't that just the fact that the compiler was able to inline the function?
(I'm talking about the 13 minute video. Not about that video from the original post that's over an hour long.)

If my functionality in an NES game only consists of one line where a variable is assigned, then I wouldn't use this as a function and rely on the optimization abilities of the compiler anyway. This simple assigment, when needed more than once, would be a macro since I avoid functions that need parameters as much as possible when doing a game for the NES.

As I said: All this is neat and I'm actually for these kind of features. If anybody can make a usable version of the gcc or a converter that can produce worakble 6502 code that has the quality of professional optimized code, then this is good. I would use this compiler if it was in a workable state.

But if anybody who wants to do an NES game rejects the idea because of this video or because he doesn't want to use pure C instead of C++, then this is really exaggerated. The example wasn't that convincing and C++ either has features over C that you cannot really effectively use anyway (object orientation), or it's pure syntax sugar that you can easily do without (inline functions, const expressions).

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 6:17 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
DRW wrote:
Wasn't that just the fact that the compiler was able to inline the function?

The specific example is an inlined function (and all the static analysis and optimization around it), but it's just an example. If he were to throw hundreds of lines of code at it, it would still make many valid optimizations, and it would take hours to explain everything that it's doing. That wouldn't be the point of the video, he's just trying to illustrate that it can do useful things.

DRW wrote:
As I said: All this is neat and I'm actually for these kind of features. If anybody can make a usable version of the gcc or a converter that can produce worakble 6502 code that has the quality of professional optimized code, then this is good. I would use this compiler if it was in a workable state.

It's right here if you want to try it: https://github.com/lefticus/x86-to-6502

I do plan to give it a shake when I'm finished my current project. I don't know how good it is yet, but I like what I've seen a lot.

DRW wrote:
The example wasn't that convincing and C++ either has features over C that you cannot really effectively use anyway (object orientation), or it's pure syntax sugar that you can easily do without (inline functions, const expressions).

There's a problem with examples that they have to be simple and small to be understood and explained during a 5 minute or 1 hour lecture. He wrote Pong with it, and demonstrated a bunch of interesting C++ features in that lecture linked in OP.

Demonstrating the actual utility of a language like C++ takes big, practical examples, and a lot of time and experience. Quite frankly I don't see why FaTony or anyone else in this thread needs to justify to you why C++ is worthwhile. Some of us have already started from the premise that it is worthwhile, and would like to discuss this new development from that standpoint. (Or at least, I would, and I said so.)

If I could give you a one paragraph explanation of why I think C++ features are very useful and practical and a worthwhile advantage over C, I would, but it's a complicated subject and you seem hostile to the idea anyway, so why would I want to? Normally if you wanted to learn this stuff you might take a class or an internship and have a professional to teach you these things over many months. I can't really imagine doing this in a forum post for you.

DRW wrote:
But if anybody who wants to do an NES game rejects the idea because of this video or because he doesn't want to use pure C instead of C++, then this is really exaggerated.

The reason I mocked you in my earlier post is because I don't think anybody but you really wants to argue about this. It's not an informative or interesting argument to have. You made your point about that in post 3, I don't really get why you keep bringing it up. I responded to your claim about the efficiency of classes not to argue with you, but for the benefit of anyone else reading because I think you're spreading misinformation.

If you're someone who has been using C++ for years and has seen its utility, the ability to use it with such a limited processor like the 6502 might be a really interesting prospect. Do you really think I owe you a lesson on why C++ is useful? Can't you just let others talk about it even if you don't understand why they're interested? It's quite exhausting to have you belligerently demand that we justify our interest in it.


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 6:26 am 
Offline

Joined: Fri Jul 22, 2016 9:58 am
Posts: 11
DRW, you seem to be willing to discount the fact that it is easier to write and develop modern C++ than old C (which is the type of C you necessarily have to write using cc65).

IDE support is way better. You get true namespaces, you get templating (which can make for writing more readable code). If your goals for a project are long term, you often spend time building tooling to help you write aspects of the project more quickly and easily. The tooling around C++ is incredibly mature and makes writing it not only less painful but occasionally joyful. You gain access to Static Analysis as well as better linting - tools that profession game developers rely on to create fast and correct code.

I have not completed a full NES game, so my opinion is one of a professional software developer, rather than a hobby game developer. I do believe my points stand, though.


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 7:49 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1401
I'll give the converter a try.

rainwarrior wrote:
I responded to your claim about the efficiency of classes not to argue with you, but for the benefit of anyone else reading because I think you're spreading misinformation.

But your example wasn't something that you would find in real object orientation. It was just an example of using classes for the sake of using classes.

A real object oriented approach would be something like this (written in pseudo code):
Code:
class Character
{
    int X;
    int Y;
    bool IsActive;

    virtual void Move();
}

class Player : Character
{
    int Energy;

    override void Move();
}

class WalkingOpponent : Character
{
    Direction CurrentWalkingDirection;

    override void Move();
}

class WalkingOpponent : Character
{
    int JumpVelocity;

    override void Move();
}


// Somewhere else:

Player Player;

Character *Opponents[5] = { null, ... };


This is how you use object orientation.

Your example wasn't even valid as a simple example since it wasn't object orientation at all. As your member variables, you basically used a bunch of global variables (encapsulated into the class, but nevertheless a bunch of glorified global variables) and the only thing that your class objects actually included was an index to reference these global arrays. That's not what object orientation is about.

Why did you even declare a member in the class to begin with? If the class has only one member (and will only ever have this one member since the actual data is supposed to be in the static arrays) and this member is nothing but the index/ID/slot for all the arrays, then why don't you declare each index that you need as a simple global integer to begin with? Just so that you can call myObject.DoStuff() instead of DoStuff(myIndex)?

Sorry, your code is not clean object orientation. That's a bunch of static arrays and a bunch of indices to use the static arrays. The class is basically nothing but a glorified namespace here.


rainwarrior wrote:
If you're someone who has been using C++ for years and has seen its utility, the ability to use it with such a limited processor like the 6502 might be a really interesting prospect. Do you really think I owe you a lesson on why C++ is useful? Can't you just let others talk about it even if you don't understand why they're interested? It's quite exhausting to have you belligerently demand that we justify our interest in it.

You seem to be under the impression that I haven't used it myself. I'm not a hobby programmer, I do programming for a living. While I haven't used C++ itself for a few years now (after working with it for three years), I work with C# which has a similar object oriented approach, so I know what I'm talking about.

And I can tell you this:

If you use a clean object oriented approach as my example above, my argument still stands: With this approach you have indirect access for everything, meaning it is unsuitable for an NES game. And nobody has tried to question this until now.

If you use the approach from your example, then this has nothing to do with object orientation anymore. The class as a container for static arrays with the only non-static member being an index for said static arrays is still pure functional C-like programming with the only difference being that the class serves as a namespace for the arrays and the index doesn't need to be passed to the function (instead, you have to precede the object name in front of every function call).

So, no, your example is not a description how C++ can still be useful for the NES without any overhead. Your example just shows that you can put a bunch of global stuff into a class just for the sake of using a class.


pstalcup wrote:
DRW, you seem to be willing to discount the fact that it is easier to write and develop modern C++ than old C (which is the type of C you necessarily have to write using cc65).

That's total nonsense. I never said that.
In fact, the contrary is true: It is much, much easier and cleaner to develop stuff with a good object oriented model, occasional templates, a good standard framework and variables as local and as temporary as necessary.
And this is what I have been doing almost every workday in the past nine years or so.

What I want to say regarding the NES is: All the neat things that make your programming life easier in a modern environment just cannot be used on the NES without a huge performance hit. If you want to write a game for the NES, you need to do a bunch of dirty stuff like:
- using macros
- declaring a struct with a bunch of arrays instead of an array of a struct
- functions whose "parameters" are global variables that are set before each function call (with macros, so you don't forget to set any variable) instead of actual parameters.

And keeping this in mind, a clean object oriented character and level model will be totally unfitting for an NES game.
The only way you could efficiently use classes on the NES is by filling it with a bunch of static variables which defeats to purpose of using classes in the first place.

Yes, C++ has some features that don't produce any overhead: Inline functions, const expressions, reference variables, local variables that can be put anywhere into a function instead of just the start of a block.

But firstly, these little things are barely enough to demand a full C++ compiler since it's basically just syntax sugar.
And secondly, the usefulness of these things is mundane anyway. There's nothing to "talk" or "discuss" about it. Yes, inline functions are better than macros. Period.

But what is worthy of discussion: Is it worth creating a full C++ compiler for the NES in the first place? Or will the things that really define C++ over C be the stuff that cannot be used in an NES game efficiently anyway, so we should rather spend time improving the existing C compiler instead?

And I think: The really strong, defining features of C++, which are object orientation, templates and the C++ standard library, are all things that you couldn't (or shouldn't) really use in an NES game anyway.

(If we're talking about a tool that converts x86 Assembly to 6502 Assembly, so that you can use a professional compiler that already exists: Now, that's a totally different topic of course since the C++ features are not an issue here because GCC already has them while the conversion tools only needs to convert raw Assembly into another form of raw Assembly. But a new C++ compiler for the NES: Waste of time.)

That's my standpoint. My standpoint is not "I discount the fact that it is easier to write and develop modern C++ than old C."

pstalcup wrote:
I have not completed a full NES game, so my opinion is one of a professional software developer, rather than a hobby game developer. I do believe my points stand, though.

Well, my opinion is that of a professional software developer who also has completed a full NES game as a hobby project. And I must say: All your statements about modern programming are of course true, but you misunderstood what I wanted to say.

Rainwarrior's example doesn't justify object orientation to begin with since he just uses the class as a simple container for static variables.

And my above object oriented example would be unfitting for an NES game since the compiler would have no choice but to use indirect access every time a member is referenced. Do you disagree with this?

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 1:13 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
DRW wrote:
Why did you even declare a member in the class to begin with? If the class has only one member (and will only ever have this one member since the actual data is supposed to be in the static arrays) and this member is nothing but the index/ID/slot for all the arrays, then why don't you declare each index that you need as a simple global integer to begin with? Just so that you can call myObject.DoStuff() instead of DoStuff(myIndex)?

I was demonstrating that by reorganizing your data into static arrays, you can reduce or eliminate the overhead of indirection. Any member function now requires only a single index lookup, and the rest of the data can be accessed with absolute indexed instructions (e.g. LDA abs, X). You can access the static arrays 30 or 50 times in a function call, but you only need the indirection once. (Possibly shared over multiple subsequent member function calls automatically too, if inlining and static analysis works well.)

It removes that one specific overhead, and it retains all the other features of a class. You can still use inheritance, and everything that goes along with it. It acts the same as any other class, it just stores its data externally.

Inheritance is the defining feature of a class, and it has nothing to do with where or how the data that class uses is stored. Inheritance is about where your code goes and how it is reused.

And I'll try not to beat this dead horse much further, but you don't have to dynamically allocate classes for them to be useful as classes.

DRW wrote:
Rainwarrior's example doesn't justify object orientation to begin with since he just uses the class as a simple container for static variables.

It's an example of how to reduce the overhead of indirection, and nothing more.

If you want a justification for why classes are useful, I dunno, go read a book or something? I'm not interested in that debate. Do you think anyone else here is?

DRW wrote:
You seem to be under the impression that I haven't used it myself. ... I know what I'm talking about.

I'm merely under the impression that you have a very narrow opinion of what C++ is useful for. I was trying to honestly explain why I think otherwise, the reasons for which have to do with my own personal experiences with it. I don't know how to convince you otherwise, because what convinced me did take years. I also have no desire to convince you of my opinion. What I do desire is to be able to discuss this new development with people who share that opinion, without you interjecting aggressive and uninformative rants about why you think it's useless. That seems to be impossible though.


Last edited by rainwarrior on Wed Nov 09, 2016 1:38 pm, edited 4 times in total.

Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 1:31 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19099
Location: NE Indiana, USA (NTSC)
I think part of the problem is a memory layout quirk that C++ inherits from C: even if objects are part of a statically allocated pool, all data members of a class/struct must be contiguous in memory except for alignment padding. As far as I'm aware, the C++ language has no built-in facility for the sort of striped arrays that the 6502 can access efficiently. The same is true for variable allocation, as the language offers no way to prove statically that a particular set of functions with automatic variables lack recursion.

I use polymorphism in my assembly programs. The Curse of Possum Hollow has at last count 47 different actor classes, each with its own override for the move method, though they all use the same draw implementation.


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 1:54 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1401
rainwarrior wrote:
I was demonstrating that by reorganizing your data into static arrays, you can reduce or eliminate the overhead of indirection.

Yeah, fine, but by doing this, you're not using object orientation anymore. You're using the equivalent of an index variable in combination with global array, i.e. you're using what C is capable of as well. Your only difference is that you put it into two brackets with the word "class" at the top.

You don't need to explain me the technical backgrounds. I know fully well what your code does. The only thing I'm saying is: This is not object oriented programming. It's pure functional C-like programming, with some globally valid arrays, some indices for access and all the stuff that you know from typical C programs. Only that you build a class around it.

Whoever dislikes C because he wants object orientation would dislike this attempt as well.
And whoever is o.k. with this construct can just as well use global arrays and doesn't need this class.

Whatever your code is, it is not an overhead-less version of object orientation. It is a functional programming method, put into a class that serves no real purpose other than serve as a namespace.

rainwarrior wrote:
You can still use inheritance, and everything that goes along with it.

How do you want to use inheritance if your only member ever is just the index? You do realize that static variables and functions are basically independent from inheritance, i.e. it makes absolutely no difference if you write:
Code:
class A
{
    static int B;
}

class C
{
    static int D;
}

or if you simply write:
Code:
class A
{
    static int B;
    static int D;
}

B and D, at heart, are global anyway, so it makes no difference which of the two classes-as-namespaces you use to store these otherwise global variables.
O.k., with the private/public/protected keywords, you may be able to hide them from each other in the same way separate source files can hide variables from each other, so that class A cannot accidentally access anything from class C. But that's about it.

As I said: A glorified namespace.
The static members don't really belong to the object that uses it.

If you have only one object, you still have 16 slots for every piece of data.
And if you create the 17th object, your game would go boom.
And nothing prevents object 1 from accessing array item 2.

There's no built-in correlation between the index and the array. It's all hand-made, just like in a purely functional programming language.

Your example might use a class without much indirect access, but:

Your. Example. Is. Not. Object. Orientation.

rainwarrior wrote:
If you want a justification for why classes are useful, I dunno, go read a book or something? I'm not interested in that debate.

:shock: Are you kidding me? Are you FUCKING kidding me?

After all those texts where I layed out my stance in details, you still believe that my message is: "Classes are not useful"? That's what you think my argumentation boils down to?

Especially after the stuff I said to pstalcup, you have the nerve to summarize my statements as if I thought classes aren't useful and I'd have to read a book about what classes are?

You know what? Screw you!

Seriously, I have no problem with people disagreeing with me. But if you're not even willing to grasp my arguments on a purely informational level, i.e. the things that you disagree with are not even what I fucking said or believe, then screw you!

Damn!

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 2:23 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
I don't really feel like playing a game of "define object oriented" with you.

You seem to have two main points here:
  • 1. Some C++ features have overhead.
  • 2. Features of C++ that have overhead aren't worth using.

Do you think this is an unfair summary?

My summarized counter-argument is:
  • 1. Causes of overhead are manageable. It can be reduced, or even eliminated.
  • 2. The features can be useful, and sometimes overhead is a desirable trade.

I think that's about as direct as I can make it.


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 3:22 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1401
rainwarrior wrote:
You seem to have two main points here:
  • 1. Some C++ features have overhead.
  • 2. Features of C++ that have overhead aren't worth using.

Do you think this is an unfair summary?

Yes because I'm only talking about NES games, dammit! I was never talking about programs in general, i.e. stuff that you write for modern PCs or even for an 80s DOS computer.
So, your whole argument about reading a book about classes is total bullshit, unless you're actually thinking of a book about object oriented programming in C++ for the NES. Which you probably did not, did you?

You know that, when working with CC65 for the NES, it is good practice to do some things that otherwise would be considered bad style?
Like when you use an item of an array a few times: It's better to save the item to a temporary variable and to use this variable, then save it back at the end.
Remember this tip? I guess you do.

Now think about it: How much more would this count for indirect access?
An array is already bad enough as it is with its LDA array, X. The version LDA (pointer), Y is even worse. And that's the way member variables are always used with classes (since the function cannot know from which object it's called), making a clean object oriented approach basically unusable for a productive NES game.

rainwarrior wrote:
My summarized counter-argument is:
  • 1. Causes of overhead are manageable. It can be reduced, or even eliminated.

That's true. But by doing this, your code is not object oriented anymore. You're just encapsuling a bunch of global variables and functions into a class.
If you're not using the paradigms of object orientation and simply use the class as a container for otherwise global functions, it's not object orientation anymore.
But if it's not object orientation, there's no real need to have a C++ compiler. Because static arrays with a fixed size and a bunch of index variables can be used in basically the same way without a class at all. The class brings you no other advantage except for some encapsulating name, but you don't use it the way a class is intended.

rainwarrior wrote:
  • 2. The features can be useful, and sometimes overhead is a desirable trade.

Yes, sometimes. But not in the case where every single member variable of every single object would always be accessed by indirect access.
I saved a ton of ROM space by storing into temp variables whenever something like valueArray[index] was used more often. How much worse is it if you use objectArray[index].value and not storing this into temp variables?
You cannot tell me that this is an acceptable overhead if even something like arrays of a struct are too bad for an NES game and you should use a struct with a bunch of arrays instead where only one instance of the struct is ever created.

And don't give me that inlining functions bullshit for this case. In a clean object oriented approach, your class would probably have a good bunch of functions. Copying all these functions for all the 16 objects that you delcare, so that you can use them with direct variable access is just as bad because now you need 16 times as much ROM space as before.


So, this is my summary:

If you do object orientation in C++ in a clean way, in the way it is intended, where each object actually has only the members that belong to it, you will get large and slow code.

If you circumvent these problems by using static arrays in the class, then you defeat the purpose of using classes in the first place. The static arrays would have no correlation to class objects. Consistency would only be guaranteed because you made sure that each object only accesses the part of the array that it is supposed to. Now, your code is not object oriented, it is function-based. And for this, a C++ compiler isn't necessary. You can simply use regular functional C code right away.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Last edited by DRW on Wed Nov 09, 2016 3:37 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 3:32 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5718
Location: Canada
NES has been a context for everything I have said in this thread, but yes I do think things people write or say about C++ in other contexts still apply to NES.

That's kind of the whole point of the x86 to 6502 converter, actually. It applies something that was appropriate for the 386 to the 6502.


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 3:42 pm 
Offline

Joined: Fri May 13, 2011 7:36 pm
Posts: 143
At some point it becomes less effort to try it and see how well it can be made to work than argue it to death.


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 3:56 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1401
rainwarrior wrote:
NES has been a context for everything I have said in this thread, but yes I do think things people write or say about C++ in other contexts still apply to NES.

If that was true then this would also count for C: "What people write about C in other contexts still applies for the NES."
But if that was true, then why do lists exist that explain which features of C you should not use specifically when writing NES games?
http://shiru.untergrund.net/articles/programming_nes_games_in_c.htm wrote:
Avoid local variables as much as possible, make them static at least

Is this true or false? If it's true, why do you think generic C++ talk automatically applies to the NES if that's obviously not the case for C?

rainwarrior wrote:
That's kind of the whole point of the x86 to 6502 converter, actually. It applies something that was appropriate for the 386 to the 6502.

The x86 to 6502 converter is something completely different yet again. As far as I understand it, doesn't care at all if you write code in C oder C++ or Pascal or Cobol. It only converts x86 Assembly to 6502 Assembly. So, this converter is neither a positive, nor a negative example for our discussion:

If you write C++ with a lot of classes, you would still have x86 Assembly code with a lot of indirect access. A PC doesn't care, but if you try to convert this Assembly to the NES's Assembly, you would run into all the problems I listed.
If you write C or C++ without classes and without local variables, you will get pretty fast x86 Assembly code, which doesn't matter since a PC is fast enough either way, and if you convert it to 6502 Assembly for the NES, it will work as well.

So, this converter is totally out of the scope of this discussion since no C++ compiler was written for it anyway.
The thing I'm talking about is: Does it make sense to write a C++ compiler for the NES or would this be a waste of time since you already have a C compiler and you shouldn't use most of the C++-specific features anyway?

That an x86 to 6502 converter always makes sense because it can convert code from any x86 programming language from any x86 compiler, so you can let your code even be optimized by Visual Studio and turn the Assembly output into an NES game, that's of course something we don't need to argue about. Of course that makes sense. But this has nothing to do with "Should you use C++ classes for NES games" or "Should you take the time to write a C++ compiler for the NES?"

snarfblam wrote:
At some point it becomes less effort to try it and see how well it can be made to work than argue it to death.

Well, yes, of course. This is a forum after all. This is about talking. If you want to try it, you wouldn't do this in a forum anyway, but in your IDE. So, talking about it here prevents no-one from trying it out on his computer.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Wed Nov 09, 2016 4:28 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1305
It would be nice for this thread to not get bogged down by combative posts arguing in extremes.
DRW's strawman wrote:
"What people write about C in other contexts still applies for the NES."

General tips for best-practice C absolutely still apply, including those about program organization. There may be additional architecture-specific notes, like what Shiru wrote. What exactly is there to be misunderstood here? The same argument applies to C++, and as usual there would be notes on which features would be better used or not used, and how. Even when writing C targeting 68000, I know the compiler is going to push every argument to the stack, so in some cases I will pass a reference to struct(s) instead of many properties. A good example could be collision detection between two objects.

DRW wrote:
Does it make sense to write a C++ compiler for the NES or would this be a waste of time since you already have a C compiler and you shouldn't use most of the C++-specific features anyway?

It's not a waste of time - it would be educational, and if nothing else, you could at least have first-class support for basic polymorphism, instead of typecasting from generic object_t * structs to more specific object classes. Type safety never hurt anybody.*

While I have many reservations about the feasibility of creating a reasonably efficient C++ compiler that supports the features a "modern C++ user" would expect, it would be interesting, and I don't see why at least the most basic class features couldn't be done.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 100 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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