Jump to content

  • Log In with Google      Sign In   
  • Create Account

can visual c++ or other c++ do


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 cpp boy   Members   -  Reputation: 116

Like
Likes
Like

Posted 02 March 2002 - 04:01 PM

any kinda console game you know snes playstation dreamcast ect... Kevin

Sponsor:

#2 Null and Void   Moderators   -  Reputation: 1087

Like
Likes
Like

Posted 02 March 2002 - 04:12 PM

There''s no such language as Visual C++. With the correct compiler you can develop for consoles, but that''s traditionally done in assembly (for whatever processor the console has) and/or C.



#3 S1CA   Members   -  Reputation: 1399

Like
Likes
Like

Posted 02 March 2002 - 08:48 PM

The Visual C/C++ compiler/linker combination which comes as standard with Visual Studio (DevStudio) compiles code for PCs running Microsoft Windows and nothing else.

For platforms such as Windows CE and Xbox, Microsoft supply plugin compilers (under special license for the Xbox).

For the other consoles, common choices are:

Metrowerks CodeWarrior (www.codewarrior.com)
SN-Systems Pro-DG (www.snsys.com)

Also most console platforms come with a special custom port of the free GNU GCC. GCC can be plugged into the Visual Studio IDE.

Pro-DG also contains an integration option which allows it to work with the Visual Studio IDE. This is what I use at work to develop PC, GameCube and PS2 code from the same environment.


However having the compiler for a console platform on its own doesn''t mean you can make games on that platform. Realistically to do that you need the official headers, libraries, documentation and physical development hardware etc for the console platform.


--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

#4 Aprosenf   Members   -  Reputation: 372

Like
Likes
Like

Posted 03 March 2002 - 03:35 AM

How would you use plug-ins with MSVC? I''d like to be able to use it for GBA development. I know that you can change which processors it creates the code for, but, as far as I know, it only supports 80386, 80486, Pentium, and Pentium Pro processors, and it also has a "Blend *" option. The GBA uses an ARM processor, and right now, I''m using GNU to compile it.

#5 scaught   Members   -  Reputation: 122

Like
Likes
Like

Posted 03 March 2002 - 06:42 AM

quote:
Original post by S1CA
Pro-DG also contains an integration option which allows it to work with the Visual Studio IDE. This is what I use at work to develop PC, GameCube and PS2 code from the same environment.

How has this worked out for you? I remember someone at the company I work for evaluating it and having a bitch of a time getting everything working; however, I have very little faith in some of the people at the company I work for. And, since we just shipped, now would be the ideal time to move the project over to work with the VSI package. If you have any thoughts, caveats, gotchas, whatever, I''d love to hear them.

-scott

#6 S1CA   Members   -  Reputation: 1399

Like
Likes
Like

Posted 03 March 2002 - 11:20 AM


scaught:


To be honest we''ve only had prettty minor problems with the integration. Any larger problems have been associated with other parts of the toolset. Generally we''re pleased with it, I''d definately recommend it.

IMPORTANT: Some of the problems we''ve seen have probably been fixed by the latest version of the VSI/Pro-DG since we''re using a slightly older version (the latest upgrade requires manual installation/registry fiddling, and we''ve not had the time recently to be able to risk breaking any of the build machines).



General
-------
- I did have to reinstall a couple of times due to the copy protection the system uses. On the first installation of the PS2 version, after the license file had been put in the correct place, the target manager and debugger went from demo to full version as expected, but the compiler seemed to ignore the license. Cleaning the folders, reinstalling and re-instating the license file from the SN email before running any of the tools seemed to work ok.

- If you need to upgrade any components you''ll probably find you''ll have to make friends with the sn.ini file. To be fair that file is documented in the manual - but I''m too impatient to read the manual at times

- The biggest problem we had was with certain MS style extensions to C++ which people seem to have got into the habit of using, things like anonymous structures inside unions (e.g. in matrix class). Luckily the latest/beta version of the compiler now implements these so our code builds just fine.

- The default debugger keymap is totally the opposite to the MSVC debugger (though it can be configured).



VSI
---
- Since of all environments, I''m most used to Visual Studio, it makes my life much more comfortable to be able to trigger all tools from inside the IDE. A minor annoyance is that I''m used to hitting F5 to run/debug, which doesn''t work with the console platforms.

- Console target projects in VS are implemented with custom appwizards. The project created seems to be have two sets of configurations - one for the target, and one which is strangely a Win32 MFC configuration (I usually delete the MFC config to keep things tidy). IMO it''d be better if they''d used the standard multiple target setup which AFAIK would allow the same project with multiple targets rather than a project per target.

- Changing some VSI settings (such as verbose output) for one target seems to affect those of the other target - I can see some places you may want this, but in places its annoying.

- Occasionally when building the project for a console .lib file which has a dependency on another console .lib file, compilation seems to lock up (in Snarl.exe).

- Thankfully the debugger picks up the source files for your project without any pain. It also reads the workspace so you can go in and open other files from the project in there. Unfortunately it doesn''t always pick up breakpoints, and the workspace part ignores any folder/sub folder organisation you have - instead you just get a big list of all the source files in the workspace, which can be tedious if there are a lot of source files.

- Global Watch in the debugger doesn''t always pick up complete info for any structures in a .lib. You get the variable in the watch, but you can''t expand to see the members. I think I''ve only ever seen this with .libs anyway.

- When starting the debugger from VS, the PS2 target manager occasionally changes the host0: serving path to be the same as the debug folder in the VS project rather than what you had previously set - its annoying when you see a load of file errors on the TTY only to discover the host dir has changed.


#7 S1CA   Members   -  Reputation: 1399

Like
Likes
Like

Posted 03 March 2002 - 11:39 AM

I should probably mention the layout of our current code base to indicate to what level we''re using the VSI.

We have the projects for all targets, and projects for engine .lib files which those projects depend on in a single workspace:

  
Game Workspace
|
+- Win32 .exe project - main game, PC code
+- Win32 .lib project - PC graphics
+- Win32 .lib project - PC sound
+- Win32 .lib ...blah...
|
+- NGC .elf project - main game, GC code
+- NGC .lib project - GC graphics
+- NGC .lib project - GC sound
+- NGC .lib ...blah...
|
+- PS2 .elf project - main game, PS2 code
+- PS2 .lib project - PS2 graphics
+- PS2 .lib ...blah...


Many of the projects in the workspace share the same common source files but need to be in multiple projects due to the target thing I mentioned above.

There are dependencies set up so that the .exe/.elf projects are dependent on the .libs so we get automatic rebuilding of affected files. Some of the .libs should be dependent on each other, but that seems to cause the snarl problems mentioned above. (I''ve simplified the above - there are really two levels of engine, the platform specific and the platform independent, each in their own .libs which is why there are dependencies between .libs).

Not all people on the team have access to devkits or only have access to one so those people can simply remove the projects they can''t build from their workspace.


#8 scaught   Members   -  Reputation: 122

Like
Likes
Like

Posted 04 March 2002 - 09:38 AM

S1CA-

Thanks a lot for the reply! I''m going to be making the case for transition this week...

About the license file problem - we''ve had that same problem a couple times - our solution was to make a copy of the license file and dump it in your WinNT/Windows directory - their linker apparently just searches the path for it.

Also, it''s interesting to see another project with the same platform scope as ours - we''re the only ones in this company with a console/PC version anymore (everyone else is console only).

Anyways, thanks again.
-scott

Weird timing - the GC lead just popped his head over - seems he''s been using the VSI stuff for his PC/GC tool work (not for the main project though). He mentioned he had to edit the .dsp''s by hand to get them set up right. Did you guys have to do the same, or is he just missing something obvious?


#9 S1CA   Members   -  Reputation: 1399

Like
Likes
Like

Posted 05 March 2002 - 01:50 AM

quote:

Also, it''s interesting to see another project with the same platform scope as ours - we''re the only ones in this company with a console/PC version anymore (everyone else is console only).



although our PC version won''t actually be publically released - not everyone on the team who needs to play the game regularly has a devkit (e.g. artists etc) so we made a thin layer which uses our PC engine.

quote:

Weird timing - the GC lead just popped his head over - seems he''s been using the VSI stuff for his PC/GC tool work (not for the main project though). He mentioned he had to edit the .dsp''s by hand to get them set up right. Did you guys have to do the same, or is he just missing something obvious?



Eeek! - luckily we''ve not had to do that, adding a few command line switches to get the PS2 to assemble the VU code we have was about it - the GC version has been almost as painless as a PC build!. Do you know why he had to do it? - all I can think of is it was for things like browse info, class view (although there is now a fix on the SN site for browse info).

Or maybe it was so he could get multiple targets into the same project (.dsp) - as I mentioned above, because it uses an appwizard per target we have a different project per target within the same workspace rather than the MSVC style "targets".


A small annoyance I forgot - when you shut down the PC where you have been running DevStudio with VSI + the SN debugger, you''ll get an access violation (IIRC) occuring in MSVC, it doesn''t occur with PC only builds. Its not a nasty one though since it goes away when you OK it.


--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

#10 pyromatic   Members   -  Reputation: 122

Like
Likes
Like

Posted 09 March 2002 - 03:55 PM

How would an amatuer go about developing for a console (I have a GC and PS2). Are there are free compilers/libraries out there, or would I have to be a professional developer with the expensive official developer kit?

Edited by - Pyromatic on March 9, 2002 10:56:06 PM

#11 S1CA   Members   -  Reputation: 1399

Like
Likes
Like

Posted 10 March 2002 - 12:35 PM

The "proper" answer is that you need to be working for a professional developer and pay for expensive devkits.

One of the conditions of becoming an "official" developer is you (your company) sign a contract which prevents you from disclosing specific programming details/information to the general public. What that means is much of the information on how to get the most out of the consoles isn''t available to amateurs. What information is out there tends to have been leaked and is technically illegal to have (copyright infringement etc).

For the PS2, Sony are releasing a Linux based programming environment specifically for amateur developers. You won''t get the full documentation or full access to the machine etc, but it should be enough to learn the essence of PS2 programming. This seems to be similar to what they did with the PSX and Net Yaroze. Sony also released a version of the BASIC programming language called YABASIC for the PS2 in some territories.

AFAIK there isn''t anything similar at the moment for the GameCube.


The "not so proper" answer is that there are enough people interested in knowing how to program these consoles that they''ve been reverse engineering the OS, working out how the hardware works etc. There *are* websites out there which carry information and source code - they don''t always stay active for long though since they''re sometimes on shaky legal ground.

Try something like PS2+development as a search term in your favourite search engine and you''ll likely find some.


--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

#12 Biased turkey   Members   -  Reputation: 122

Like
Likes
Like

Posted 11 March 2002 - 03:21 AM

http://www.boob.co.uk/

That should give you a good start for developing with Dreamcast, and contrary to the Sony owned PS2 development kits, the software is free and OPEN source.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS