This project is read-only.

splitscreen games

Jul 17, 2009 at 11:10 PM
Edited Jul 18, 2009 at 9:44 AM

hi there.  i admit i've only gone thru the first 12 tutorials so far.

if i'm asking questions that later tutorials will answer, then please ignore those questions so you can save some time for yourself.  8)

if you wanna skip the part where i ramble about my game for too many paragraphs, look for the "*****" sections please.   8)

i'm working on a music game & a 3d shooter that is so far based off of the JigLibX sample.  both of them need particles at this point (i have crappy 2D particles in the music game that i want to replace with proper 3D particles).  neither one has much work done on the graphics/eye-candy side of things.  so i thought Xen's unique architecture might work well if i can adapt to it before i add too much further graphic work

i practically finished my weapons system for the shooter (and virtually nothing else, other than loading up the architecture (just the shape) of BUILD engine (duke nukem 3d) maps about %85 correctly :) ),

so now its time to use particles so i can show the weapon system in a video.  the weapons are procedural, spells composed of rune combinations that dictate their different attributes, its almost like allowing people to build their own weapons/spells from scratch except they can't plugin in absolutely any number, i predefine increments of varying power levels of the different aspects....alot more difficult to explain than a video could make obvious quickly,  there will be literally thousands of spells available when you have all the runes.

soooo thats where Xen comes in.  i hope.  8)  i've never wanted to focus much work into the eye candy side of things and i like the way that Xen seems to be pretty much just a graphics engine of sorts without alot of other stuff since i'm happy to take care of everything else myself (or plug in cohesive subsystems such as Jig).

to start with, the game will just be multiplayer deathmatching, and in order to delay my networking code for later, i had implemented splitscreen in the JigLibX sample.  which i had no problem with.



but the Xen architecture/scheme is all different (of course).   what i tried to do (for rendering a splitscreen) was this: 


            GraphicsDevice graphDev = state.BeginGetGraphicsDevice(StateFlag.None);

            Viewport vp = graphDev.Viewport;

            vp.Height = 640;

            vp.Width = 480;

            graphDev.Viewport = vp;



vertices.Draw(state, null, PrimitiveType.TriangleFan);

that last line was already a part of the Advanced Particles Tutorial 23, i just included it to show that i put MY code right before the vertices.Draw().
it behaves strangely.  as i spin the mouse around the viewport keeps resizing itself seemingly totally unpredictably.  sometimes it even goes outside the bounds of the window.   sometimes its almost as small as a postage stamp.  but it corresponds somehow to my mouselooking.
another thing i was wondering about is, in the first tutorial it says "Update() is called 60 times per second".
i know how to change that to uncapped FPS in standard XNA, but not sure if/how Xen supports this.
*********** (maybe shouldn't ask this, hehe) 
i will also need to figure out how to make it so i don't have to choose a Tutorial from a GUI dialog box, so i can just go right to my game when i press f5,
altho i guess that shouldn't be too hard.  8).  
should i avoid using anything other than a new project made from scratch?
is it crazy to start my game from the Tutorial 23 sample (using it as a base)?
i've started almost every project building onto a sample.  :)
thanks alot!



            GraphicsDevice graphDev = state.BeginGetGraphicsDevice(StateFlag.None);
            Viewport vp = graphDev.Viewport;
            vp.Height = 640;
            vp.Width = 480;
            graphDev.Viewport = vp;
vertices.Draw(state, null, PrimitiveType.TriangleFan);



Jul 21, 2009 at 2:03 AM

For viewports, you are on the right track. However I have no idea why that is happening to you.
There is 'Xen.Graphics.Modifier.ViewportModifier'. This is a 'Begin/End' object, so calling Begin will setup the viewport, End will reset it. It can also be added to a DrawTarget as a modifier, which will apply the viewport to everything drawn to the DrawTarget (however this doesn't sound like the option you want).

Thinking about it.. There are potentially problems with 2D elements and viewports, as 2D elements use the size of the current DrawTarget when aligning themselves.


If you need Update to be called once per frame, you can have an object implement IUpdate and return UpdateFrequency.OncePerFrame. However by default vsync is enabled, so this will likely not exceed 60 times per second anyway. You can disable vsync in the SetupGraphicsDeviceManager method, however I wouldn't recommend it. Vsync tearing is ugly after all :-)

All Application objects have a 'Run' method, just like XNA Game objects. So if you create an Application object, just call Run() and it'll work. This is what the tutorials gui does, it selects an Application object and then just calls Run.

A lot of people seem to start with a tutorial. I guess it comes down to your own code style.
I personally just create a XNA project, delete the Game.cs and add a class that implements Application as my starting point, as it's just three methods and is quite a clean starting point.

Good luck :-)