Author Topic: SGDK-XNA ...Cool or not cool...?  (Read 35931 times)

TheLaw

  • Regular
  • **
  • Posts: 96
    • View Profile
Re: SGDK-XNA ...Cool or not cool...?
« Reply #15 on: 2009-09-16, 02:03:52 PM »
Yeah, after about 16 years or so of making insignifigant little toy games/apps, I've decided to strap on a set and try my luck in the big league.
Also, general laborers like myself are out of work around here, so I'd like to use it as a "career launcher" in my portfolio. ...God be willing of course!

Let the good times roll...
I fought the law and TheLaw won...!

Vincent

  • SGDK2 Addict
  • Expert
  • Fanatic
  • *****
  • Posts: 612
  • Legacy of Kain: Revival is completed!!!
    • View Profile
    • Chivalrous Games
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #16 on: 2009-09-16, 02:05:32 PM »
These are hard times, no doubt.
I wish you all the best! :)
Legacy of Kain: Revival completed!
http://lokrevival.webs.com

See also my company website:
http://chivalrousgames.com

TheLaw

  • Regular
  • **
  • Posts: 96
    • View Profile
Re: SGDK-XNA ...Cool or not cool...?
« Reply #17 on: 2009-09-16, 02:26:19 PM »
Very kind of you, sir! Thanks - I really do need it!  :pray:

I fought the law and TheLaw won...!

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #18 on: 2009-09-17, 05:30:18 AM »
Your document suggests that the benefit of tiling is to reduce memory usage, but in my mind, this is not the biggest benefit.  The biggest benefit I got from tiling was simpler, more efficient collision detection.  You should maybe mention the physics engine in that section (at least with a "see below" comment).  Do you see how a tile-based map would simplify collision detection?  I still wonder on a map with a million tiles if an architecture like this can perform comparably to a tile-based map.  Are you going to have some kind of tree structure that quickly eliminates far-away objects from consideration in collision detection and drawing?  (Is that how it's done these days?)  (I would also comment that it's not so much memory I'm concerned about when designing tiles, but rather artwork effort -- I don't have enough time/skill to draw a million tiles' worth of different graphics, never mind how much memory it takes :))

I haven't had time to read all the way through the document yet, but that's the first question that springs to my mind -- managing collision detection optimization... maybe that's the responsibility of the physics engine?  What are the limitations of the physics engine?

TheLaw

  • Regular
  • **
  • Posts: 96
    • View Profile
Re: SGDK-XNA ...Cool or not cool...?
« Reply #19 on: 2009-09-17, 07:04:40 AM »
Thanks, bluemonk, this is what I need!

First:
Quote
Your document suggests that the benefit of tiling is to reduce memory usage
Haha, yeah, my document probably makes many silly/bold/false claims! It's (currently) not so well thought out!

Quote
Do you see how a tile-based map would simplify collision detection?
Well, with tileless, you still are in a sense making tiles, but they do not have to be square or of any particular size. Your "pallette" of artwork to design your level becomes a big collection of any pictures you can find.
Have a look at this video: http://vimeo.com/2769377   to see what Ii mean. ...I can't explain it to well!

Quote
Are you going to have some kind of tree structure that quickly eliminates far-away objects from consideration in collision detection and drawing?  (Is that how it's done these days?)
Yup, it's all in the algorithm! It's every bit as fast as tiles, perhaps faster, since you're (probably) not making millions of calls to draw little square images. ...Bigger artwork in the level equals less calls to the bitmap blaster. *(There's many variables involved really. So it's not safe to claim that a tileless system is faster, or slower, but they do have their moments. Suffice to say, they can get the job done. I have never heard one complaint about their speed, and I've been around them for a while now too.)

Quote
managing collision detection optimization... maybe that's the responsibility of the physics engine?
Yeah, as I mentioned in the doc, you draw out your collision polygons, then I just sorta "upload" those polygons to the physics engine, along with any physical properties (bounciness, etc). Then every crank of the main loop, I just query the physics engine about any collisions that have happened since last time. If there's a collision that requires a reaction (bounce), the physics engine (which would do all the math based on their weight, etc) will tell me what direction and what speed I should change them to. So for simple platforms, you draw poly's around your artwork, and just set it to a simple "you can't go there" type collision. Or perhaps it's a big rock, that would require a run to move the weight.
So yes, the physics engine is the boss of all the polygons in the game and it will tell us when collisions happen and how to respond.
...Sorry I'm just no dang good at explaining things!

Quote
I don't have enough time/skill to draw a million tiles' worth of different graphics, never mind how much memory it takes
Don't worry, it's still very tile friendly and aware. You can add tiles to the palette and set up a grid with snap - then it's business as usual.

Quote
What are the limitations of the physics engine
Not many! Did you catch the video? http://www.youtube.com/watch?v=Oecv7Cg9lCc

For anyone who still can't get their head around this tileless idea, try downloading this editor:
http://www.gleed2d.de/#download
It's nice and small with no install program. You can be working with it in seconds. There's video tuts for it (http://www.gleed2d.de/#media ) that can bring you up to speed in about 15-20 mins (just long enough to eat a bag of popcorn!). Then have a go at making a little pretend level and see if you like it (It's not the best, but it's easy to try out). This editor is actually written in XNA, so test it for speed too. I think you'll find the map rather zippy!

Thanks, again BlueMonk. Keep those questions and suggestions coming!
« Last Edit: 2009-09-18, 07:10:38 AM by TheLaw »
I fought the law and TheLaw won...!

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #20 on: 2009-09-18, 05:06:59 PM »
The 2D physics demo is pretty cool, but it only shows about one screen's worth of objects at a time, and no background.  My concern is what do you do if you want to have a map that's a hundred thousand times the size of the screen?  Are there any details about how it handles large numbers of objects or culling invisible objects from consideration or excluding certain objects from interacting from each other?  For example, if you think about a world map in an RPG, maybe you have 100,000 patches of background (presumably you're not going to draw the background as one giant image) throughout the world (the background might be 1000 screens wide and 100 screens high, and each patch of background covers a whole screen).  It might be odd to have physics on a world map, but assume this is a space game where you're flying a ship through the universe and the background is made of stars, and there are 1000 planets in the universe.  And maybe there are about 20 other ships flying through the universe at any given time.  Now in the case of a tiled map, the drawing is as simple as one screen full of tiles (plus the number of sprites) no matter how big the universe is.  And the collision testing is only as complex as the number of solid tiles that a particular sprite is touching (assuming you make the planets out of tiles and not sprites).  So the complexity of drawing the background is O(N), where N is the number of sprites in the universe (20) because the number of tiles being drawn is constant and the complexity of locating the tiles to draw doesn't depend on how large the universe is, and the complexity of collision detection is O(N*N) where N is the number of sprites in the universe (20*20 = 400, although SGDK2 optimizes this significantly with sprite categories so you only have to enumerate the sprites that care about collisions).

But if you are using a physics engine where everything that gets drawn and everything that can interact with other objects needs to be represented as an object, doesn't the complexity increase?  It seems to to me that the complexity of the drawing would be O(N) where N is the number of objects in the universe (20 + 1000 + 100000 = 101020 objects to check for visibility).  And the collision detection would be O(N*N) where N is the number of objects (101020 * 101020 = 10,205,040,400 -- more than 10 billion checks for objects in the vicinity of each other without some sort of optimization).  Do you know how 2D physics engines deal with this or if they don't?

Cool that it's optimized for C#, BTW!

Jam0864

  • Contributor
  • Fanatic
  • **
  • Posts: 744
    • MSN Messenger - marmalade0864@hotmail.com
    • View Profile
    • Jam0864's Content Dump
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #21 on: 2009-09-18, 08:02:58 PM »
The 2D physics demo is pretty cool, but it only shows about one screen's worth of objects at a time, and no background.  My concern is what do you do if you want to have a map that's a hundred thousand times the size of the screen?  Are there any details about how it handles large numbers of objects or culling invisible objects from consideration or excluding certain objects from interacting from each other?  For example, if you think about a world map in an RPG, maybe you have 100,000 patches of background (presumably you're not going to draw the background as one giant image) throughout the world (the background might be 1000 screens wide and 100 screens high, and each patch of background covers a whole screen).  It might be odd to have physics on a world map, but assume this is a space game where you're flying a ship through the universe and the background is made of stars, and there are 1000 planets in the universe.  And maybe there are about 20 other ships flying through the universe at any given time.  Now in the case of a tiled map, the drawing is as simple as one screen full of tiles (plus the number of sprites) no matter how big the universe is.  And the collision testing is only as complex as the number of solid tiles that a particular sprite is touching (assuming you make the planets out of tiles and not sprites).  So the complexity of drawing the background is O(N), where N is the number of sprites in the universe (20) because the number of tiles being drawn is constant and the complexity of locating the tiles to draw doesn't depend on how large the universe is, and the complexity of collision detection is O(N*N) where N is the number of sprites in the universe (20*20 = 400, although SGDK2 optimizes this significantly with sprite categories so you only have to enumerate the sprites that care about collisions).

But if you are using a physics engine where everything that gets drawn and everything that can interact with other objects needs to be represented as an object, doesn't the complexity increase?  It seems to to me that the complexity of the drawing would be O(N) where N is the number of objects in the universe (20 + 1000 + 100000 = 101020 objects to check for visibility).  And the collision detection would be O(N*N) where N is the number of objects (101020 * 101020 = 10,205,040,400 -- more than 10 billion checks for objects in the vicinity of each other without some sort of optimization).  Do you know how 2D physics engines deal with this or if they don't?

Cool that it's optimized for C#, BTW!
Generally physics engines won't detect physics every frame if the framerate is low either.

You could easily lose nine tenths of your framerate in any sgdk2 game I've seen and the game would still run fine anyway, I'm usually getting 500fps or more.



There's a game called Cortex Command that showcases 2d physics very nicely. Very, very complex physics in that game though, it does get hectic at times causing framerate drops. Whole sprites can break into smaller pieces, calculated dynamically through the physics engine. A very nice game. It's not free, but the demo gives a fair amount of content.

Rocket Crash:
 
Digging for Gold:
 

That's all ingame, many similar physics calculations can be taking place at the same time and it runs fairly well for the most part.


TheLaw

  • Regular
  • **
  • Posts: 96
    • View Profile
Re: SGDK-XNA ...Cool or not cool...?
« Reply #22 on: 2009-09-18, 09:58:41 PM »
Haha, the hard question is easy to ask isn't it BlueMonk! LOL! Thank you for taking the time to post such a great question! In fact you made me doubt myself, so I had to get Seth Robinson evolved (creator of NovaShell, and so many other things (http://www.rtsoft.com/) ). He's already been doing most of what I want. Here's what he had to say after I made him read your post!

Quote
Hey Lawrence,

Well, he's right, it's tricky.  But doable.  Just a lot of individual tricks to keep things fast.

Here are some ways Novashell deals with it:

1.  Grid partitioning or some other partitioning scheme allows objects to quickly check only those near them for collisions
2.  When things stop moving, put them to 'sleep' to stop eating cycles
3.  If something IS moving offscreen, it "wakes up" those around it so the  physics will work right, and they in turn wake up more, etc, before the real physics math starts for that update cycle.  This only time totally breaks down is if you had many screens totally filled with objects that use physics all touching eachother. (design around that happening)
4.  Moving objects that never stop (like platforms) can be made to freeze when they go out of scope in most cases
5.  NPC movement that happens off screen can be partially faked as long as the door connections/paths can be computed in advance.  They don't need physics.  So, for offscreen action, "Light AI" is used.   I assume this is what Fallout 3, etc does
6.  One trick that novashell uses is "Keep running entity for X amount of seconds after it leaves the screen", works good for like, barrels falling or NPC's running around and sort of shutting down when you leave.  (Novashell calls it a "Watch list")
7.  Because of the spatial optimization, Novashell doesn't need to use the traditional concept of tiles at all, and uses 'patches' for everything.  (Sprites/tiles are just floating out in space with an X/Y position and not part of a grid)

The Top down RPG example in Novashell uses physics (you just push around things since there is no gravity, it's not even needed really) and has a pretty large map.  You can cut and paste the map a few times and after zooming back in, you should see speed hasn't changed.

I think Box2D is great.  One consideration is it does have a max area size which is pretty large but waaay less than something like 100*100 screens.

If you're going to do be doing multiplayer netplay this can introduce further complications which need more work arounds and tricks.

Anyway, feel free to post any of this in the thread.
***"Box2D is a c++ physics engine that he uses in his game engine. ...Same idea as the one I've been looking at, just I had to find one for c#

...So there you have it! There's tremendous "Trickery" involved!   Take from it what you will. Myself - haha I've got some head scratching to do!

Thank you so much Ben and Seth!
And thanks Jam for your post too. There's a way to make this happen.

I fought the law and TheLaw won...!

Jam0864

  • Contributor
  • Fanatic
  • **
  • Posts: 744
    • MSN Messenger - marmalade0864@hotmail.com
    • View Profile
    • Jam0864's Content Dump
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #23 on: 2009-09-18, 10:38:37 PM »
I'd just like to add that multithreading is an important part of physics. If the whole game ran on one core it probably wouldn't go too well.

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #24 on: 2009-09-19, 07:06:50 AM »
If I recall correctly, the 2D physics engine you posted the video about has some advantages over Box2D.  And it was for C#.  So is that what you are going to use?  I'm a little confused on how NovaShell, Box2D, Physics2D and SGDKX all (would) relate.  My guess is:
NovaShell is an editor like SGDKX.  It doesn't rely on a physics engine, but can generate data in a format usable by a particular physics engine.
Box2D is one physics engine.  It works with NovaShell, but is C++ only and has some limitations.
Physics2D is another physics engine.  We want SGDKX to work with it.  It uses a clean C# design and overcomes some limitations of Box2D (http://groups.google.com/group/physics2ddotnet/browse_thread/thread/87e60ddff9d8f46f).
SGDKX will be our version of NovaShell with integrated game development features.

Am I close?  I assume Seth's reply was in regard to Box2D, but hopefully it applies to Physics2D as well.  I'm excited about using a game development IDE that integrates with Physics2D let alone being involved in creating it! :)

TheLaw

  • Regular
  • **
  • Posts: 96
    • View Profile
Re: SGDK-XNA ...Cool or not cool...?
« Reply #25 on: 2009-09-19, 08:08:38 AM »
Yeah, sorry it was never my intent to ever mention NovaShell or Box2D.  It's just an example of a completley different project that happens to be accomplishing much of what I'd like to do. So to be clear yeah, NovaShell is a C++ project, we're c#, Box2D is for c++ only (but they may have some sorta .NET wrapper - not interested!), and we need a good equivalent for c#/.net which looks to be Physics2D. Finally NovaShell is ClanLib, we're dealing with XNA.

Quote
NovaShell is an editor like SGDKX.  It doesn't rely on a physics engine, but can generate data in a format usable by a particular physics engine.
I would say that it fully relies on Box2D. But, again Seth's from Mars and we're from Venus! But his project does accomplish what we want. His source code is available, so if it comes down to it I may have to go learn some tricks from the master!

Quote
SGDKX will be our version of NovaShell with integrated game development features.
Precisely! We're gonna one-up him here! Haha, well maybe not, but we're gonna do it our way and make some xbox games! (fingers crossed. I still haven't heard any good news about MSBuilding xbox games. It hurts my head to think about that right now, but here's a link to a post I embarassed myself with over at XNA http://forums.xna.com/forums/p/38710/225169.aspx#225169) --If anyone want's to head-up the xbox/zune building/deploying dept. I'd love not to have to deal with that. (because of the way XNA works, I believe we can persue windows only for a while and let the xbox/zune falll into place. - Our plans (c# code) shouldn't have to change.)

Quote
'm excited about using a game development IDE that integrates with Physics2D let alone being involved in creating it!
Yeah, there's plenty to be excited about, but we have many important vegetables to eat before we can have our SGDK-XNA turkey! Open wide! Here comes the Choo-Choo!  ...sorry I'm over tired.

Anyway, is everyone comfortable with the tileless editor idea?  Have I been able to paint a picture of what we're up to here? Perhaps giving NovaShell a little try would clear things up more. ...but don't get hooked!!! ;)


I fought the law and TheLaw won...!

tprime

  • Fanatic
  • ***
  • Posts: 395
    • View Profile
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #26 on: 2009-09-19, 11:44:46 AM »
Wow. A lot of promising posts in here...  :)

TheLaw

  • Regular
  • **
  • Posts: 96
    • View Profile
Re: SGDK-XNA ...Cool or not cool...?
« Reply #27 on: 2009-09-22, 04:53:00 AM »
Yeah... promising to be a LOT of work ;).  I just hope I can get it done before Dec 23/12/2012...! ???
I fought the law and TheLaw won...!

tprime

  • Fanatic
  • ***
  • Posts: 395
    • View Profile
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #28 on: 2009-09-22, 10:04:17 PM »
Out of curiosity... why that date?

Jam0864

  • Contributor
  • Fanatic
  • **
  • Posts: 744
    • MSN Messenger - marmalade0864@hotmail.com
    • View Profile
    • Jam0864's Content Dump
    • Email
Re: SGDK-XNA ...Cool or not cool...?
« Reply #29 on: 2009-09-23, 12:38:14 AM »
Out of curiosity... why that date?
I'm assuming he meant December 21st 2012, which is supposed to be another Doomsday, predicted by the Mayas centuries ago.