Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Zouflain

Member Since 12 Jan 2007
Offline Last Active Jan 09 2015 09:45 AM

Posts I've Made

In Topic: MMO Terminology

08 January 2015 - 01:58 PM

Shards are isolated sets of data. When I create my character DudeGuy19192 on Shard 1 and then and you create your character DudeGuy19192 on Shard 2, nobody gets a "name already used" message because each Shard is basically the entire game in isolation.

 

Blades are allocations of hardware resources, typically on games with single sharded architectures. If 100,000 players are in one zone, the work of computing that zone will be shared by multiple blades (processors). The rest of the zones might all be shunted to one blade, with all of the others working tirelessly to support that one mega-zone. Jita comes to mind when talking about Eve...

 

Zones are collections of data within a shard. Typically this data is just "there is a monster here with n hitpoints at (x,y) coordinates." They rarely if ever hold account data (that's what Shards do). Instances are typically implemented as zones.

 

Rooms and scenes are the same thing, even smaller collections of data if they are used at all. When you enter a door, but don't have to load into it, it means you're probably still in the same zone but possibly a different room. It can be useful for grouping objects (no need to collision check things in room 1 with things in room 2), but I rarely see them used any more. It's easy to just teleport you to some unreachable spot in the zone and not deal with this layer.

 

Worlds are equivalent to Shards. So are "Servers."


In Topic: [C++] Can't find error with Delaunay Triangulation

31 December 2014 - 09:48 AM

rolleyes.gif Sorry about the missing attachment.

 

So I tried simplifying the problem by reducing the number of input points and watching it build systematically. I've spotted the first step where a problem occurs (see example2). I'm still stumped as to why this is the case, but at least I know where it's happening.

 

 

 


In Topic: oop fundamentology question

19 February 2014 - 12:39 PM

Not sure how experienced in the language you are, so if this is obvious forgive me, but are you familiar with the difference between a pointer (Sometype* name) and a reference (Sometype& name) in C++? It's fairly significant. I could be wrong, but I have never used or seen references used that way. I suppose it's legal, but you'll have to initialize those references with Object::Object(SomeObject some_value) : some_reference(some_value){}. Is that really what you wanted? Can it never reference nothing (as in nullptr/NULL)?

 

Also, referencing objects is only necessary for objects that the base object does not own. Ownership is not clear from your post, but say a Box owns 6 Sides, it would probably look more like

class Box{
    Side top,front,back,bottom,left,right;
};
rather than a bunch of pointers to Sides (Side*) or worse references.

 

If a Train runs on a Railroad, which is presumably shared between many railroads, it might look more like

class Train{
    Railroad* railroad;
};

 

Of course, this has its own problems. Raw pointers are easy to get wrong, but c++11 has introduced smart pointers to the stl (and boost has had them for ages)... but that might be a topic for another day. Coupling an object with a hard reference (SomeType&) makes it very hard to check if SomeType is even still around. Scoping also seems like it would become a real pain - and if you're dynamically allocating the memory, why go through the hastle of storing it's location as a reference instead of a pointer?

 

Then again, I'm no expert. Just chipping in.


In Topic: [Lua] Seeking advice for multiple OS Threads, handling lua_State

09 February 2014 - 02:21 AM

 

Can't you initialize your Lua states before hand and store them in an array, one for each thread?

 
You're absolutely right. I realized this on the way to work after posting. All persistant values (sans the function definitions) were stored in an SQL database, so there's no reason not to just pre-load the virtual machines with the LUA code.

Initializatio might be slow, but it only has to happen once (even though the threads might dynamically open and close, they can simply re-use the already-initialized lua states). Thanks for pointing this out.

In Topic: What algorithm would minimize repeat loading of every member of nxn grid+neig...

06 February 2014 - 09:37 PM

Sorry if I wasn't clear, I'll clarify:

There is an nxn grid, say:

A1 B1 C1 D1 E1
A2 B2 C2 D2 E2
A3 B3 C3 D3 E3
A4 B4 C4 D4 E4
A5 B5 C5 D5 E5

The current brute force algorithm loads A1, B1, A2 and B2 then processes A1. Next, it loads C1 and C2, and processes B1. Next it loads D1,E1,D2, and E2 while unloading A1 and A2, then processes C1. And so fourth.

In short, iterate over every member of the grid - load any unloaded neighbors, unload any loaded non-neighbors.

My current algorithm takes about 27,000 ms to cover a 512x512 grid. I'd like to get this down. Several orders of magnitude if possible...

edit: WHY does this forum delete newlines?!?!?!?!?!?

PARTNERS