Users browsing this thread: 1 Guest(s)
Enribeaver
#16
my set up is an entitiy / component,
IGameObject (Position, isActive, isOnScreen, isSavable, Update, Draw, GUIdraw, onCreate, onDestroy, Save, Load, CreateInstance, CreateInstance(Position))
IGameObjectComponent (Owner, isActive, canUpdate, canDraw, canGUI, Update, Draw, GUI, Save, Load)
with 2 helper classes which flesh out stuff like isActive to have an event onActiveChange and to fill in CreateInstance (which is used in the level editor),
GameObject<T> : IGameObject where T : GameObject<T>, new()
GameObjectComponent<T> : IGameObjectComponent where T : GameObjectComponent<T>, new()
Objects are kept in a dictionary of lists of game objects, organised by type (this is for the sake of making the saving and loading flexible and efficient)
On saving the dictionary is passed through a foreach loop,
foreach type in dictionary, if type count > 0 save fully qualified name, foreach gameobject of type if isSavable, Save.
and in the loading the typename is loaded, the type is retrieved from Type.GetType, an object creator is created using DynamicMethod and MethodInvoker which pumps out empty instances to load.
My physics is run by PhysicsManager which keeps a list of all active PhysicsComponenet's, it handles the collision detection and response as well as applying air resistence and gravity, per the norm.
and for the sake of efficiency I also have a SpatialHashTable handling what gets updated / drawn and what doesn't.

I would have everything be component based but I didn't like the idea of saving components where in a lot of cases they'll start up the same every time (without need to load anything)
Thanked by:
#17
I re-read my post and it seemed like i said that datas, although separate from the component, still belong to them? I meant that i would have something like this:

Component:
-TalkableComponent
Data:
-DialogData

Any component can access and alter the data. I could add some kind of security thing, but i don't need it right now.

-----
reply to your post:

For my components, i also have a acquire/release data along with an update or render method. The acquire/release methods get called whenever the component gets added to an entity, or data is added or removed from the entity. The methods simply notify the component to get any data it needs, instead of asking for it every frame. Components don't need to have an input/physics/renderer/collision components. They're searched for and taken from the entity if found.

For you're saving and loading, why don't you just serialize/deserialize the data. Nvm... i remembered that the IntermediateSerializer is for the full Xna Profile only. I can't remember if the binarySerializer or xmlSerializer are also, but you should would check em out. Oh yeah, i don't have any kind of saving yet. I think i'd just serialize the data that's needed to load them except for the graphics data.

I didn't have any collision optimization things added in before. It was just brute force with a few conditions of what can/can't collide with what. Recently i added in a quadtree.....and it didn't help at all. I think ima remove it and add in a broad phase collision detection in instead. Maybe sweep and prune. Theres no harm in whats being drawn right now, so i didn't optimize it yet.
Animations - MFGG TKO (scrapped) - tFR
[Image: QUmE6.gif]
"It feels that time is better spent on original creations" - Konjak
Focus on the performance, the idea, not the technical bits or details - Milt Kahl
Thanked by:
#18
I'd be against serializing, it doesn't really gain you anything, in fact it inflates file size in XML's Case,
Just use BinaryReader and BinaryWriter (System.IO)
there simple as can be so long as you dont get lost between your saving and loading loops (which I did at one point, it leads to the loading desynchronising with the file and reading stuff wrong, but it'll only happen in complex loops, in my case I was saving Tilesets from a SpatialHashTable)

the original reason I wasn't using serializers is because their not supported on xbox and windows phone, I THINK but not sure, I think its not available on the reach profile, which if you dont use the reach profile your game wont run on DX9 systems only DX10+, I realised this a while ago when I gave a game to my friend with a really crappy laptop.

EDIT:
look up Spatial Hash Table its much nicer than a quadtree for non-cluttered collisions (quadtrees are meant for masses of colliders, the overhead isn't worth it in this case)
I just made a fer helper methods to handle the SpatialHashMap with Rectangles as well as Vector2's this meant I could just pass the objects area and add it into each grid piece, or get all the objects in a grid within an area (excluding duplicates ofc) it takes a bit of cleaning up but its really fast and really simple.
my trick was to each frame get a list of the objects within the cells which intersected with the view, and only pay attention to those object, things outside of that list wouldn't even get a check against them, no need, already have a list of all the relevant items.
Thanked by:
#19
Yeh thats a pretty good reason for avoiding it. I guess it would be smarter to save the data manually so its more compact and wouldn't require a higher profile. Not to mention its much faster to load/save. I've had a bit of experience with binary files from my ssbb hacking days so it won't be too hard to make my own. It might be a bit time consuming though...I'd rather not depend on the api to do things for me as that turns out horrible if you want to change api's.

I'll check it out. Im sure Sweep and Prune will be good enough though. I simply check the left/right bounds of each object bounds and get pairs of those who intersect. Then just do normal collision checks on the pairs afterwards. In a 2d platformer, i just gotta check the X axis since chances are they aren't intersecting in that axis. Its minor, but i might also change the SAT collision detection test to check against the Y axis first for AABB's in this situation. I already made sure they're intersecting in the X axis, so that should improve it a tiny bit.
Animations - MFGG TKO (scrapped) - tFR
[Image: QUmE6.gif]
"It feels that time is better spent on original creations" - Konjak
Focus on the performance, the idea, not the technical bits or details - Milt Kahl
Thanked by:
#20
(02-12-2013, 08:20 AM)TheShyGuy Wrote: I've had a bit of experience with binary files from my ssbb hacking days and it won't be too hard to make my own. It might be a bit time consuming though...

So long as the files have a pattern and you stick to it, it should be fine.
Thanked by: Bombshell93
#21
Im still working on making the binary file format. Still thinking about how i want it to be and how i'll load/save the data. Atm, im just thinking about going with a header, relocationTable, rawData, and then a string table as the basic layout. I can just write the data out as is, left to right, but it just doesn't seem right.

I just implemented a veeerry simply Sweep and prune and its pretty amazing. Before, the collisions between objects were the main cause the slow framerate. Now its between the objects and the level ( i didn't SAP with the level since im unsure how i wnna go about it right now) thats causing the slow fps which is great. You guys should check it out.
Animations - MFGG TKO (scrapped) - tFR
[Image: QUmE6.gif]
"It feels that time is better spent on original creations" - Konjak
Focus on the performance, the idea, not the technical bits or details - Milt Kahl
Thanked by:
#22
in terms of save / load format I approach it (and will likely continue approaching it this way as its efficient and simple)
  • Header data
    for each object type
    • Identifier for object (anythings fine so long as you can tell what it is while loading)
      for each instance of object
      • a true bool
        object data
      a false bool (to tell the load loop to stop loading this type of object)
    Footer data
its about as easy, flexible and compact as you can get pre-compression, a testament to "Simplicity is Supremacy"
and you could apply this to just about any engine.

EDIT: I'd like to apologize for the almost back-seat deving, these are just things I've forgot early in projects and payed the price for later, I figured I could save you the trouble before it hits you.
Thanked by:
#23
Its cool, i like to exchange ideas too when it comes to programming.

I was thinking of making the file format like this:

I've been playing with bit shifting and unsafe pointers in the past few days. But i can't figure out how to create the binary structures (header/reloctable/etc). I would explain more but i can't describe it =/.

========================

The next update will include a hub, damage(getting hit), and saving/loading (useless right now but im working on it obviously)
Animations - MFGG TKO (scrapped) - tFR
[Image: QUmE6.gif]
"It feels that time is better spent on original creations" - Konjak
Focus on the performance, the idea, not the technical bits or details - Milt Kahl
Thanked by:
#24
binary reader / writer doesn't deal in bits, you should never need to play with them for a modern game unless your doing very low level work. (or your using flags or doing some specialised math)
C# dont use unsafe pointers, reference types (class / array) do the job of pointers and unsafe code as the name suggests is not a common practice in C#.

size of file you dont need, so long as your save and load loops aren't all over the place your load loop should never even have the option of reading past the end of file.
relocation table? I'm not familiar with the concept, if it offsets loaded positions then forget it, single floating point values will suffice, just save the original positions.

all in all it really should be as simple as
What am I loading? Load it! Is there any more to load? if not Finish loading.
Thanked by:
#25
Quote:binary reader / writer doesn't deal in bits, you should never need to play with them for a modern game unless your doing very low level work. (or your using flags or doing some specialised math)
C# dont use unsafe pointers, reference types (class / array) do the job of pointers and unsafe code as the name suggests is not a common practice in C#.

Oh i know about binary reader/writer. Bitshifting and pointers are actaully much faster and just as easy as using those classes. Its mostly just preference for me.

BinaryWriter Wrote:int num = 5;
BinaryWriter.Write(num)
Quote:int index = 0;
byte[] buffer = new byte[4]
BinaryDataHelper.Write(buffer,ref index, num);

' Wrote:size of file you dont need, so long as your save and load loops aren't all over the place your load loop should never even have the option of reading past the end of file.
relocation table? I'm not familiar with the concept, if it offsets loaded positions then forget it, single floating point values will suffice, just save the original positions.

You're right, im just stuck in the mindset of ssbb =/. I actually did just that the first time but it was a bit messy and i didn't like it. Oh yeah, i did move the bit shifting and pointer stuff to a helper class, so it looks and works just like a binary reader/writer. Using the helper classes, i can make custom methods to easily read/write out other types like vectors, rectangles, etc, with a single call (although you can just write extension methods for the binary reader/writer also...sooo its still preference lol)
Animations - MFGG TKO (scrapped) - tFR
[Image: QUmE6.gif]
"It feels that time is better spent on original creations" - Konjak
Focus on the performance, the idea, not the technical bits or details - Milt Kahl
Thanked by:
#26
I suppose you can use unsafe code purely out of preference, but for future reference its typically a frowned upon practice because such code would be faster in unmanaged languages, though still faster than basic C# it also drops some of the safties of using a managed language (hence the term unsafe)
Its typically only used in either massive memory operations (like image processing) or intense arithmetic (typically things like matrices)
so long as your not working with other programmers this should not be a problem though though.

on the subject of extension classes I dont think their all that popular, on occasions extending a class past its original functionality is helpful, but in other cases it can change the classes function itself where it may be cleaner to start anew, this isn't one of those cases, I just like talking programming.
Thanked by:
#27
It turns out i was really over thinking the problem. I decided to just write it out as is, along with a tag and version. I also decided to just use the binary reader/writer with extensions because really there's no real point in doing bit shifting and pointers and reinventing the wheel. Time to go work on the hub and damage stuff now ,thnx.


Edit: I'm going to start working on that 2d editor i talked about in the other thread. This time, i'm gonna plan it out better. I think i might just use the game engine too instead of trying to make it generic. It just seems like a big hassle making it generic and it makes the dev time for the editor longer.

Edit: I know i said there would be more frequent updates, but baseball season has started. That means that im going to be devoting just about all my time to baseball. Im not gonna lie, this is when i just about forget about programming. However, i don't want to let recolornerd down so i'll do my best to work hard when i have the time. Given that its still cold outside, i'll still have the weekend to work on it alot. I'm just about done with what i said was going to be the next update, but theres still a few things that im doing.
Animations - MFGG TKO (scrapped) - tFR
[Image: QUmE6.gif]
"It feels that time is better spent on original creations" - Konjak
Focus on the performance, the idea, not the technical bits or details - Milt Kahl
Thanked by:


Forum Jump: