I am seeking a couple of programmers of C++ and Assembly for a new gaming console. You would be working with a team of ten people. We currently have sound composers, pixel artists, branding, animators/modelers and electronic techs.

Your first project will be coding in a basic start screen and an auto run function for a game.

The second project will be coding for games. The games will be 16-bit format, not PS3 type stuff. This is a retro style system.

PM me on here for more information or email me fayt (at) rodgame (dot) com

Sup,

I can program in C++ and assembly bot x86 , x64 and 16-bit. I can do this PM me.

PM Sent

Hey, I can program in C/C++ to an adequate level, and I'm always up for learning new languages (as I'm not yet familiar with Assembly)
Either way I think I'd be doing everyone a favor by asking for a little bit more detail?

Failing that I may be able to lend a hand with any music you want, (if you want actual music) as I'm a guitarist and I have a band that could probably help me out for this.

Satsuma,

If you could learn some Assembly that would be great. However C/C++ is a great help also.

I have an active team of people who are currently working on developing a new gaming console to be released nationwide. From 3D renders to actually creating the prototype and games. We have a rough draft of the website up. This console is to be a retro style because countless thousands of gamers and developers are reverting to retro games and are missing the classics.

The Specs:

-1 RCA Cable Port
- 1 Power Cord Port
-4 USB Controller Ports
-1 USB Game Slot
-1 USB Flashdrive Memory Slot
-1 Dual Output Port
-16 Bit Graphics

This project is based in Charlottesville, Virginia. I am working on the 3D rendering of the console. Here is an early rough draft of it: [Link Removed] I only want to show it privately.

Taking a look at the assembly language I know that it's going to take me a while to get used to it, also I feel thatI may not be of much use with the C core since it mostly sounds like not want interaction with the chip, peripherals or rendering. And I'm not too handy with graphics APIs yet either.

Or well at least it's nice to know some more info. It may get you some other takers.
If you have an API specification already I could take a look into making a prototype game, or at least a test screen or something.

And I'm still able to have a go at producing some music. If you want I could make a little song demo and send it over when I'm done. I'll just take a guess at a few themes?
Binaural sounding? For casual background music and high tension scenarios (like fortress levels on Mario)?

All of the programming is up to the programmers on the team.

do we have to meet up or can we do it over the internet?

It can be done over the internet.

to what extent do we need to know C++ and Assembly

Enough to program a splash screen and coding to load a file from a flashdrive. The rest would be simply interacting the game with the console.
Plus if you are working on the software side, you'd be programming the actual games. (Such as movements, actions, buttons, etc)

So the first task would be programming a splash screen, which I imagine should be like your company logo, and shows while the console is loading data from the drive?

And also we'd need to know how the data is stored onto the drive, are we for now just going to assume (for now at least) that a drive will be dedicated to a specific game and a specific file type (and extension) will be used to contain most of the games logic.
In which case we'd need to load the filenames/types and find the correct file type that contains all the game data, and load it into the consoles memory?
It is essentially telling the console how to load and run that game, any graphic images and music files will be able to be on the drive separate to the main game file.

In order to program properly some specifics would be advisable.

If the reason you've not provided these details is because you're not yet sure about how you want to save game data onto a drive and how it should be loaded in then this is what should be done before actually trying to program it.

what graphics library will we be using or is it a custom made one?

The flashdrives are programed to auto-run when inserted. No need to have a file library to find a file manually.

I am not a programmer, I do modeling, animating, renders, website and managment. I am relying on the programmers to figure out the best way they want to do it.

Hmm... I have been thinking about the file loading problem and it is quite difficult. Considering that this is a console, there is no underlying OS for you to access the file systems. The problems here is that for creating a console, you effectively have to program your own OS for it, which will take a LONG time.

The flashdrives are programed to auto-run when inserted

How would that have been done? Are they programmed to auto-run on an operating system based off the Linux Kernel? If so, is your console going to be based off the Linux kernel?

Seeing all these problems (and there are many more that I can foresee, such as actually interacting with the graphics on a monitor), I don't think that I can accept something like this, as the time is just far too long.

A 32 bit processor would be much better than a 16 bit one. I mean, keep the retro style graphics and such, but just upgrade to 32 bit.

Consoles like the NES have crappy performance with C and C++ executables.

If it needs to be 32-bit that's no problem. I've learned that you can use windows or linux OS. Which is fine. As for the flashdrives there is a file on them that auto loads whatever file you want.

Nothing is set in stone yet, with a few tweaks this could happen.

It seems like you are saying it's impossible for a console to exist. Because that's funny since over 40 different ones have been released and worked great.

No, the console is perfectly possible. I'm just saying upgrading the processor would stop everything from being written in assembly.

Meaning only C or C++?

Both really. C and C++ get crap performance on NES-like hardware.