can visual c++ or other c++ do
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.
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
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
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.
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
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.
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:
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.
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.
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?
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?
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
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
Edited by - Pyromatic on March 9, 2002 10:56:06 PM
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement