Sign in to follow this  

nintendo ds programming question

This topic is 3847 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm a win32 systems programmer and most of my life I've done mainly c++ and assembly code. I just got a job to help with a 3d renderer on a nds and lo and behold I'm the main programmer. I've done lots of stuff like this before with c++ but for the nds every tutorial and demo code I see is in c. As I look at the specs of the hardware I'm really worried that c++ wont be able to cut it. I've also heard the arm processors dont do well with lots of virtual calls and general OOP bloat(which is not a problem on desktops). I really dont want to write a whole engine and then find it's too slow, do you think I should just write this whole engine in c from the very beginning? Experienced console programmers, i look forward to hearing your opinions. Also the reason to my reluctance is because I am an oop whore.

Share this post


Link to post
Share on other sites
Most of what you need to be careful about is memory usage; I think you've got 4 MB of RAM to work with, so vanilla C++ is right out. However...

C++ written in a certain way, and with an appropriate runtime or compiler, is perfectly acceptable. C is used because there is an appropriate runtime and compiler written already; there is none such for C++.

If you feel you must use C++, then look for a runtime for it. Mostly, that means a memory allocator and a CRT to bootstrap into your C++/ASM code, or if you're lucky there's a complete library for even the hardware access through C++.

Either way, I'd suggest you learn C. It is far more likely a C library and bootstrap exists for the DS than a C++ one, and you don't want to write a cross-compiler (from C++ to C, not x86 to ARM) yourself.

The C++ fanatics on this forum (and only the fanatics, not the advocates) often push the idea that writing good, readable, maintainable, OO-like code in C is harder than it is. It is not; you just have to use different paradigms when coding, because the compiler does less footwork for you. Writing a good general-purpose string library is trivial; it just takes a different mindset than blindly reaching for std::string.

Writing in C will make you a more cautious, more fastidious, and more conscienscious programmer, but it won't make you a faster one. Writing in C will make you more aware of domain-specific differences and problems which could be covered up nicely by layers of OO in languages like (and by no means restricted to) C++. Writing in C will force you to use different naming schemes, because there is no language-defined or even language-proscribed way of doing things.

In short, writing in C can make you a better programmer, but it can also make you a paranoid one.

As far as being an OOP whore... being an OOP whore is like wrapping yourself head to toe in thick mattresses; a safe idea so long as you're walking on the open plains, but you should re-think your strategy if you're climbing a cliff... you might want to trade down to a very light rope harness, and learn to climb.


[Edit] Oh, and before I forget; go get some documentation on the GLIDE 3D rendering API, from the days of 3Dfx. Nintendo uses very similar paradigms for the hardware polygon APIs, and it'll show you what a good C-targetted 3D API looks like without COM getting in the way, in case you're not familiar with OpenGL (which is also a good C-targetted 3D API, but it was originally shaped for engineers, not game programmers).

Share this post


Link to post
Share on other sites
Quote:
Original post by Wyrframe
Most of what you need to be careful about is memory usage; I think you've got 4 MB of RAM to work with, so vanilla C++ is right out. However...

C++ written in a certain way, and with an appropriate runtime or compiler, is perfectly acceptable. C is used because there is an appropriate runtime and compiler written already; there is none such for C++.

If you feel you must use C++, then look for a runtime for it. Mostly, that means a memory allocator and a CRT to bootstrap into your C++/ASM code, or if you're lucky there's a complete library for even the hardware access through C++.

Either way, I'd suggest you learn C. It is far more likely a C library and bootstrap exists for the DS than a C++ one, and you don't want to write a cross-compiler (from C++ to C, not x86 to ARM) yourself.

The C++ fanatics on this forum (and only the fanatics, not the advocates) often push the idea that writing good, readable, maintainable, OO-like code in C is harder than it is. It is not; you just have to use different paradigms when coding, because the compiler does less footwork for you. Writing a good general-purpose string library is trivial; it just takes a different mindset than blindly reaching for std::string.

Writing in C will make you a more cautious, more fastidious, and more conscienscious programmer, but it won't make you a faster one. Writing in C will make you more aware of domain-specific differences and problems which could be covered up nicely by layers of OO in languages like (and by no means restricted to) C++. Writing in C will force you to use different naming schemes, because there is no language-defined or even language-proscribed way of doing things.

In short, writing in C can make you a better programmer, but it can also make you a paranoid one.

As far as being an OOP whore... being an OOP whore is like wrapping yourself head to toe in thick mattresses; a safe idea so long as you're walking on the open plains, but you should re-think your strategy if you're climbing a cliff... you might want to trade down to a very light rope harness, and learn to climb.


[Edit] Oh, and before I forget; go get some documentation on the GLIDE 3D rendering API, from the days of 3Dfx. Nintendo uses very similar paradigms for the hardware polygon APIs, and it'll show you what a good C-targetted 3D API looks like without COM getting in the way, in case you're not familiar with OpenGL (which is also a good C-targetted 3D API, but it was originally shaped for engineers, not game programmers).


What a great post Wyrframe, thank you very much. I really appreciate the time you put into that. I'll check out the glide docs, anything that can help better integrate me into this system. Thanks again.

Share this post


Link to post
Share on other sites
You have a few options

1. Keep your engine in C and game code in C++. I'd seen this before and it works out quite well.
2. Going out all C++ OOP, but keep it light weight. The engine that we're using for our game now is all in C++ as well as game code, well it's ported from net-gen console engine. It's work fine, as we only use feature of C++ that are comparable to C and inheritance sparingly.
3. Going out all C, I done this before. However certain features of C++ just help solve problems easier.

The point is don't worry about C++ performance, use C++ and leave out the expensive features.

Share this post


Link to post
Share on other sites
To further Wyrframe's point, Any C++ programmer worth his salt ought to be able to write nice, clean C code. I would go as far as to argue that a C++ programmer who can't write nice clean C code is not only deficient as a C programmer, but as a C++ programmer as well.

C has every feature you need to build an object-orientation framework, all C++ has really done is standardize such a framework and provide convenient syntax to those facilities. All C++ programmers should be familiar with how C++ features like polymorphism are actually implimented, and how it could be implimented in a language like C (on a conceptual level at the very least). Knowing these details will absolutely make you a better programmer. For instance, if you know the details about how polymorphism is implimented, did you know that you can actually change the type of a class perminantly (I'm not talking about reinterpret_cast here) within some constraints?

What this all means is that, in addition to standard C code, you can really pick what OO concepts you need a-la-carte. Need polymorphism for your Entity class? study up on function pointers and how C++ does it, then impliment it yourself.

C is great in the way that it can actually free you from some of the constraints one tends to run up against in C++. I find that developing in C is usually a much more fluid process than C++, where more time must be spent designing -- which is not to say that you can get away *without* designing in C, only that refactoring things typically takes less effort. C often lets you focus on the problem, rather than the framework around the problem.

Before you think I'm some C zeleot, I actually do 95% of my programming in C++, both professionally and in my personal projects; I've simply observed some paterns I find common when I do use C. For example, I wrote a disassembler for a microcontroller in vanilla C not too long ago. I guarantee that most C++ programmers, myself included, probably would have written more classes than I wrote functions in the C version. Its literally fewer than 10 functions spread across 2 or 3 files.

Share this post


Link to post
Share on other sites

This topic is 3847 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this