(Picture) I Am a Software Engineer

Mighty proud of it too...

No$gba GBA/Nintendo DS Emulator, Version 2.3d released

No$GBA differentiates itself from other Nintendo DS emulators by providing specific tools to aid professional developers in creating software for the Nintendo DS, especially in the homebrew scene. While the emulator is free the programming tools requires a paid registration.

It has relatively good compatibility as you can see from the video's,





Download the emulator here
Visit the website here

I am not going to discuss how you can play your Nintendo DS games on it, to find out how visit the Emu Talk forums DS emulation board and specifically read the No$GBA FAQ.


Release Notes for No$GBA 2.3D

23 February 2007 - version 2.3d
- nds/video/help: added note on unknown tvoutcnt register (nds9 port 4000070h)
- nds/sio/help: added chapter on (absent) link port (with new bits like ckup)
- nds/aux/help: added full gba and gba-sp cpu/lcd/chipset pinouts (from no$gmb)
- nds/aux/help: added SG and SW pins (gba-sp/nds headphone socket) (from no$gmb)
- nds/3d/help: added projection/rotation/scaling/translation matrix examples
- nds/3d/help: added edge marking notes, alpha_test_ref notes, and fog notes
- nds/3d/help: added new shadow polygon chapter, and added toon table notes
- nds/3d: skips vtx's of (still unsupported) shadow polygons (avoid eragon dirt)
- nds/3d: speedup: re-creates textures only if teximage_param/pltt_base changed
- nds/3d: speedup: mtx_mul_4x3/3x3/trans/scale skips fixed values (ie. 0 and 1)
- nds/sound: init [sb_pos_in_buf_in_clk_cycles]=0 (avoids fatal 'e-2' on reset)
- nds/3d: supports packed-texture-mode3 (mul3+mul5=div8) (eragon/mariokart demo)
- nds/microphone: emulates mircophone gain level (powerman reg3 = x1 x2 x4 x8)
- nds/microphone: wave_in-dma activated only if/as long as enabled in powerman
- nds/microphone: forwards PC mic-in/line-in to nds-microphone (player 1 only)
- nds/microphone: emulates muted mic-level (for mic-powerman off=000h, on=800h)
- dos/nds: supports nds-video (256x192) (dual-screen) (forced 640x480 onepix)
- dos: dpmi redirects dos32_int10 to dpmi_interrupt_10h (fixes win98 xgra-crash)
- dos: uses int2fh/1680h under dpmi (not actually supported by cwsdpmi/win98)
- dos: prevents hlt-opcode under dpmi (hlt crashed cwsdpmi, ignored by win98)
- initialize: corrected @@zero_fill_vals length (caused crash in dos version)

C#, C++ Simple Benchmark

Just for fun I decided to pit a C# application against its exact opposite C++ counter part.

Heres the code for the C++ application:

#include

int main()
{
float x = 999999;
float y[999999];
float d;

for (float i = 0; i <><<"\n"; } return 0; }

And here is the code for the C# application:

using System;

namespace dude
{
class run
{
static void Main(String[] args)
{
float x = 999999;
float[] y = new float[999999];
float d;

for (float i = 0; i <>

Please note I haven't implemented proper indentation here because I don't have the time to figure out how to do it and do it, also the #include is missing the header file it is trying to include which is the iostream.h header file.


As you can see they are virtually alike and take a minimalistic approach to how they work. My theory is the one that reaches the end first has the better iterator and for loop algorithm.

Of course this is just for my amusement, I don't claim this 'speed run' means or implies anything.

FYI both were compiled in Visual Studio Express, C++ in Visual C++ Express and C# in Visual C# Express.

After building both files I put them on the desktop and checked their file sizes. Not surprisingly the C# version was 16 kilobytes however the C++ version was far larger coming in at 132 kilobytes, it would have to be given I included the iostream header file which is pretty big.

I highlighted both and pressed the enter key, the first one to finish would be the first to terminate the window, my result was kind of unexpected. The C# compiled code was significantly faster than its C++ counterpart,

Using a stopwatch I found the C# version completed its loop after 01:42:86 (MM:SS:MS) while the C++ was still going, finishing after 05:14:60. Yeah it is an extremely crude way of doing it, I'm not exactly trying to prove anything here, it is purely for my own amusement.

So what can I conclude from this? Well one thing is for certain, unless you're willing to dig in deep into the mysterious world of STD header files you'll be coming up with code quite a bit larger in C++ than in C# where all extra code is removed during the compilation process.

Another thing is, perhaps because of C#'s more user friendly compilation where it does all the dirty work C++ programs, at least simple ones like the one provided here will run less efficiently in C++ than C#.

Then again, I don't claim to be an expert on this matter, however I am reporting valid and true results from my little experience, take what you want from it.

C# As a Game Development Tool

My university course does not teach C#, I know I’ll have to learn it by myself if I want to gain any sort of foothold in the gaming industry, particularly since the Xbox 360 development Kit (XNA) uses the simplicity of C# as a means to increase productivity and reduce overhead costs.

Microsoft is pushing C# as more or less a direct competitor against Java, it shares virtually all the same principles, such as pulling the programmer by the ear telling him what to do and how to do it.

Why would Microsoft want to push C# as a pseudo standard language for games development? No matter how hard they press C# it will never substitute the power C++ gives programmers, it simply isn’t designed in anyway to compare to C++ when it comes to doing what C++ does best, blowing peoples legs off.

Developers will definitely buy into the XNA and C# because it can reduce overhead development costs significantly, C# is easier to use, easier to debug. Sure it can’t squeeze more out of the hardware it’s running on but that never was the point of C#.

Gameplay code, development tools, these things don’t need to be optimized so much, they don’t need to be mapped out onto the hardware in some inane way to get the most out of it.

Think of it this way, when programming a game engine you want to have direct access to as many parts of the hardware as possible, even API’s won’t let you run your software the way you would want to, as such C++ is a necessity, you’ll put up with the complexity because of the performance pay off.

But what if performance was not a factor? Would you want to bother about managing memory first hand? Would you want to go around looking for memory leaks or optimizing the garbage collection process? Well obviously not, which is exactly why C# excels in applications where performance is not the biggest factor. It handles pointers automatically as such you can avoid memory leaks, it runs high level so there won’t be any hardcore debugging happening, it just works.

Lets take a game like Gears of War for instance, based on Unreal Engine 3 which was written in C++. All the gameplay code is in C#, the game itself is built right on top of the XNA, the engine of course is C++ based. My assumption is that the gameplay programmers (whatever their titles are) can directly interact with the engine via the XNA through C#, they won’t need to look any further than that, save for bugs that might be present in the game engine itself. So they won’t be spending precious hours hunting down memory leaks but being productive.

Which is why XNA with the simplicity of C# is a great tool for developer, it not only gives developers an option to reduce workload but also encourages it. This also gives the edge to Xbox 360 developers over Playstation 3 developers. While the Playstation 3 requires C++ compiled programs it can technically support C# too, providing the software is written for it via C++ for it to support C#.

Naturally this won’t happen, the XNA concept is Xbox 360 exclusive, Sony isn’t simplifying game development on their console anytime soon, it really will be giving Xbox 360 developers an edge in terms of overall productivity.