 |
 |
|
 |
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> For example, both JBuilder and VS put the opening bracket of a function on
> the same line as the function declaration, rather than on the next line
> where it belongs.
In VS Express (the free one):
Options -> Text Editor -> (Language) -> Formatting -> New Lines -> "Place
open brace on new line for xxxx" where (xxx) is a number of different
options. Feel free to tick all these (actually they seem to all be ticked
by default, it's the style I prefer too).
> They also indent everything by 8 spaces rather than the usual 2. And so
> on. (I'm not even sure *what* formatting rule they apply to
> if-statements...)
Options -> Text Editor -> (Language) -> Tabs -> "Tab Size" or "Indent size"
Why don't you just spend 5 minutes setting the options to your preference?
> Maybe it's because I've never written any of these things, but I can't
> imagine what (for example) two games would have in common. (And hence,
> what you'd put into a template.)
Err, the headers and namespaces for graphics, audio and input libraries,
build processors set up for graphics files, meshes, sound files etc, a game
loop with empty functions for you to add your game logic and graphics code,
pre-existing code for initialising the graphics API and painting the updates
into the window each frame, a framework for adding "components" to your game
that can be easily enabled/disabled and automatically called/rendered, etc.
Just download VC# and XNA and ask it to make a new "Game" project - there's
a lot of useful common stuff in there that makes your job way easier.
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
>> For example, both JBuilder and VS put the opening bracket of a
>> function on the same line as the function declaration, rather than on
>> the next line where it belongs.
>
> In VS Express (the free one):
>
> Options -> Text Editor -> (Language) -> Formatting -> New Lines ->
> "Place open brace on new line for xxxx" where (xxx) is a number of
> different options. Feel free to tick all these (actually they seem to
> all be ticked by default, it's the style I prefer too).
When I looked at this stuff, there were 3 different options you could
select. I tried all three, and none of them did what I want. (Curiosly,
there didn't seem to be an option for "disable all autoformatting and
just let me do it by hand".)
> Why don't you just spend 5 minutes setting the options to your preference?
As I say, when I tried it there wasn't much you could adjust.
>> Maybe it's because I've never written any of these things, but I can't
>> imagine what (for example) two games would have in common. (And hence,
>> what you'd put into a template.)
>
> Err, the headers and namespaces for graphics, audio and input libraries,
> build processors set up for graphics files, meshes, sound files etc, a
> game loop with empty functions for you to add your game logic and
> graphics code, pre-existing code for initialising the graphics API and
> painting the updates into the window each frame, a framework for adding
> "components" to your game that can be easily enabled/disabled and
> automatically called/rendered, etc.
Now, to me, that sounds like it's just going to build a bunch of
boilerplate code for how the designers invesage a game would be
structured, and if you want your game structured a different way you're
going to have to waste time deleting the template stuff and rewritting
it the way you want it.
Similarly, I obviously haven't written many games (currently at zero and
counting), but I would have hoped that "initialising the system" would
already be a fairly painless task. (Isn't this what we have libraries for?)
I'm not quite sure what "build processors set up for graphics files,
mashes, sound files etc" is supposed to mean.
> Just download VC# and XNA and ask it to make a new "Game" project -
> there's a lot of useful common stuff in there that makes your job way
> easier.
Well, yeah, there is always that. (Although not understanding C#,
presumably none of it will make sense anyway...)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
> Now, to me, that sounds like it's just going to build a bunch of
> boilerplate code for how the designers invesage a game would be
> structured, and if you want your game structured a different way you're
> going to have to waste time deleting the template stuff and rewritting it
> the way you want it.
Sorry but I never heard of anyone making a game that didn't have a "game
loop" and methods for rendering and methods for the game logic. Obviously
you are free to delete those and make your own, or just start from scratch.
They are just providing the most common structure, as most people will want
that anyway.
> Similarly, I obviously haven't written many games (currently at zero and
> counting), but I would have hoped that "initialising the system" would
> already be a fairly painless task. (Isn't this what we have libraries
> for?)
Sure, it's just the odd line here and there for creating a
GraphicsDeviceManager, a content loader object, a sprite/texture manager
object, method calls to clear and redraw the frame, that sort of thing. No
more than a handful of lines of code, but it's easier to have it done for
you in a nice structure than to have to start from scratch each time.
> I'm not quite sure what "build processors set up for graphics files,
> mashes, sound files etc" is supposed to mean.
So that you can go "Add to project..." and include a JPEG, PNG, WAV, MP3,
BMP, X (3D mesh) or whatever and at the build stage it will convert your
file into a format suitable/optimised for the game (eg mipmaps for the
textures). It saves you have to export all your data files in some specific
format just to get them to work with your API, the build processor just does
it seemlessly (obviously it detects if there has been an update or not).
> Well, yeah, there is always that. (Although not understanding C#,
> presumably none of it will make sense anyway...)
FYI here's the raw template code it gives you when you create a new game (it
looks better in the IDE than in plain text): Now maybe it's just me, but I
quite like it doing that automatically for me rather than having to
remember/type that all each time I want to mess about quickly with a little
graphics demo or whatever.
using System;
using System.Collections.Generic;
using System.Linq;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Audio;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.GamerServices;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Microsoft.Xna.Framework.Media;
using Microsoft.Xna.Framework.Net;
using Microsoft.Xna.Framework.Storage;
namespace WindowsGame3
{
/// <summary>
/// This is the main type for your game
/// </summary>
public class Game1 : Microsoft.Xna.Framework.Game
{
GraphicsDeviceManager graphics;
SpriteBatch spriteBatch;
public Game1()
{
graphics = new GraphicsDeviceManager(this);
Content.RootDirectory = "Content";
}
/// <summary>
/// Allows the game to perform any initialization it needs to before
starting to run.
/// This is where it can query for any required services and load
any non-graphic
/// related content. Calling base.Initialize will enumerate through
any components
/// and initialize them as well.
/// </summary>
protected override void Initialize()
{
// TODO: Add your initialization logic here
base.Initialize();
}
/// <summary>
/// LoadContent will be called once per game and is the place to
load
/// all of your content.
/// </summary>
protected override void LoadContent()
{
// Create a new SpriteBatch, which can be used to draw textures.
spriteBatch = new SpriteBatch(GraphicsDevice);
// TODO: use this.Content to load your game content here
}
/// <summary>
/// UnloadContent will be called once per game and is the place to
unload
/// all content.
/// </summary>
protected override void UnloadContent()
{
// TODO: Unload any non ContentManager content here
}
/// <summary>
/// Allows the game to run logic such as updating the world,
/// checking for collisions, gathering input, and playing audio.
/// </summary>
/// <param name="gameTime">Provides a snapshot of timing
values.</param>
protected override void Update(GameTime gameTime)
{
// Allows the game to exit
if (GamePad.GetState(PlayerIndex.One).Buttons.Back ==
ButtonState.Pressed)
this.Exit();
// TODO: Add your update logic here
base.Update(gameTime);
}
/// <summary>
/// This is called when the game should draw itself.
/// </summary>
/// <param name="gameTime">Provides a snapshot of timing
values.</param>
protected override void Draw(GameTime gameTime)
{
GraphicsDevice.Clear(Color.CornflowerBlue);
// TODO: Add your drawing code here
base.Draw(gameTime);
}
}
}
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
>> I'm not quite sure what "build processors set up for graphics files,
>> mashes, sound files etc" is supposed to mean.
>
> So that you can go "Add to project..." and include a JPEG, PNG, WAV,
> MP3, BMP, X (3D mesh) or whatever and at the build stage it will convert
> your file into a format suitable/optimised for the game (eg mipmaps for
> the textures).
Oh, OK. I didn't realise there was a conversion step there.
>> Well, yeah, there is always that. (Although not understanding C#,
>> presumably none of it will make sense anyway...)
>
> FYI here's the raw template code it gives you when you create a new game
> (it looks better in the IDE than in plain text):
That's actually not too bad...
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> Surely it's just 1 line of code? (Unless you want to do something
> special to determine where to find the XML file...)
That. Each of the 20 different things you want to do is a line or two of
code. And that's the boilerplate.
Zll the stuff that the XML references has to be included in the program. If
you define a new type of widget and you want to reference that code in the
XML, you need at least some line somewhere saying where to get that widget.
>>> Now, see, to me these kinds of tasks all belong to the set of things
>>> which are "impossible" in the first place, so I guess I don't tend to
>>> think about it. You can't write web browser plugins unless you're a C
>>> programmer, unfortunately.
>>
>> Of course you can.
>
> Oh, yeah, I forgot. You could be a C++ programmer. ;-)
Uh, no. There are lots of languages for writing web browser plugins,
including javascript, C#, and probably others I don't know of offhand. I
wouldn't be surprised if anything capable of doing COM could act as a web
browser plug-in on Windows. That's kind of the point of COM.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Darren New wrote:
> Uh, no. There are lots of languages for writing web browser plugins,
> including javascript, C#, and probably others I don't know of offhand. I
> wouldn't be surprised if anything capable of doing COM could act as a
> web browser plug-in on Windows. That's kind of the point of COM.
JavaScript is the only language I know which might conceivably be able
to do COM stuff. (If it can, I don't know how yet.)
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> Or rather, it applies the default formatting rules, whatever they happen
> to be for the IDE in question.
Unless you adjust the defaults.
> For example, both JBuilder and VS put the opening bracket of a function
> on the same line as the function declaration, rather than on the next
> line where it belongs. They also indent everything by 8 spaces rather
> than the usual 2. And so on. (I'm not even sure *what* formatting rule
> they apply to if-statements...)
So you go into the properties sheet for the formatter and change the indents
and where the braces go. It's pretty straightforward.
> Large numbers of people apparently think that it's just infeasible to
> write any code of any kind unless you have an IDE specifically targetted
> at the programming language you're using.
That's because they're bad programmers.
> But to me, it looks like an
> IDE is only really beneficial if you're actually doing something
> complex.
Yes, or if the IDE is really good, or if the language is designed primarily
for use with an IDE. (For example, you *can* edit by hand all the XML files
that drive the compilation and linking in .NET. But why would you, when the
IDE that puts a nice graphical interface on the front is free?)
> (And, further more, it looks to me that the tipping point is
> when you start writing something more complex than any program I've ever
> attempted in my entire life - so an IDE is probably of little to no use
> to me...)
Well, you also use a powerful high-level language, which makes an IDE less
useful. You also use a DE that isn't I, and you can go a long way before you
actually get noticeably slowed down by that.
Ask yourself how easy it would be to build guis without Glade.
> Sure. But "Windows app" template? What could possibly be in it?
http://msdn.microsoft.com/en-us/library/0fyc0azh.aspx
Try "I'm feeling lucky" on "Windows Application Template".
Sheesh.
> A document. Because, let's face it, what would a template for "a
> document" actually contain?
Fonts. Header styles. Information that titles are centered. Code for
formatting the table of contents if you add one. Information about what
spell checker to use.
> Similarly, "a Windows application" could be absolutely anything. How do
> you template that?
You don't.
> Maybe it's because I've never written any of these things, but I can't
> imagine what (for example) two games would have in common. (And hence,
> what you'd put into a template.)
Well, for example, you have the code that instantiates and starts the game.
Each game inherits from the "Game" class. The constructor, by default, grabs
you references to the graphics device manager and instantiates a couple of
tools you almost always use that take up resources on the card so you don't
want to instantiate them in loops, like the object you use to draw text on
the screen. It also creates a ComponentManager, which you can put all the
bits of your game into to control them in the loop (i.e., the same way you'd
have all the buttons inside a window refresh when the window refreshes). It
also creates a service manager, which lets any components get to any data
they need without making explicit links; e.g., every component that draws on
the screen needs to know where the camera is, so you make the cameraand the
screen services so anyone who needs them to draw can find them.
The methods it creates include "Initialize" which gets called once before
the window opens so you can set up the window; "LoadContent" that gets
called once each time the window changes properties like size or color
depth; "UnloadContent" which gets called before you exit or before you call
LoadContent again; "Update" that gets called regularly based on clock ticks,
and "Draw" that gets called each time you get a vertical sync.
You don't think all games are going to have these kinds of things in common?
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
> all be ticked by default, it's the style I prefer too).
I don't like that style, but they're all ticked by default and people are
pretty insane about such trivial things, so I leave them how they are. :-)
> build processors set up for graphics files, meshes, sound files etc,
Yeah, I didn't even touch what was in the project besides the direct game code.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
scott wrote:
> Sorry but I never heard of anyone making a game that didn't have a "game
> loop" and methods for rendering and methods for the game logic.
Indeed, almost every game has input, and draws on the screen. Most even have
sound output. Whodathunk?? ;-)
> the textures). It saves you have to export all your data files in some
> specific format just to get them to work with your API, the build
> processor just does it seemlessly (obviously it detects if there has
> been an update or not).
Plus, you can add your own processors so if you want to (say) import POV SDL
code into your game project, you can just write a parser and use it like any
other model. (Note: Easier said than done, in this case.)
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|  |
|
 |
Invisible wrote:
> JavaScript is the only language I know which might conceivably be able
> to do COM stuff. (If it can, I don't know how yet.)
Out of curiousity, what languages *do* you know? I thought you'd worked in
Tcl before.
--
Darren New, San Diego CA, USA (PST)
The question in today's corporate environment is not
so much "what color is your parachute?" as it is
"what color is your nose?"
Post a reply to this message
|
 |
|  |
|  |
|
 |
|
 |
|  |
|
 |