refactoring delgate binding code to use templates

So I finally gotten around to refactoring the message delegation system’s binding methods as template functions. Now the code is very simple and clean. One simply call a function by passing one’s self to this function and one will be registered to any event in the event delegation system. It is even possible to have owner objects completely manage this for children objects (provided they have the right methods). Although without “annotations” and “reflection” it is not that elegant.

Anyways, after finally getting the messaging system the way I want it–clean and stuff–I will FINALLY make some progress. I will try to be as much a duct tape programmer and not so much the spaced-out astronaut dude. Hmmm… We need to get things done.

…

So Uber sleep? It’s only the first day, but so far I’m feeling great. Like I said, I’m a night owl, so it takes awhile for sleep deprivation to really become a problem. My guess is I will probably start feeling it tomorrow around this time. As of now, I awake from half an hour of sleep pretty refreshed. I feel a little bit groggy but that’s about it. Still very functional. Been solving matrices left and right. Coding! Exercising! Whoa, feels great.

My hope is after adjustment, I will feel completely refreshed after waking up, and without slight bit of nastiness.

Finally figure out what I will do and multicast

I wasn’t using FD:func() function, which returns a Delegate object. So the event injection code was a bit convoluted. It works much better now.

My idea now is to have the state/controller responsible for injecting events to their children. My argument the state is the thing that keeps state and control of the current state! (States know the type of objects in it’s state, thus I can do

someRegisterDelegate = ServiceRegister("SomeServiceRegister","IamMiniMe") //IamMiniMe is the current object, so ServiceRegister can do filtering base legality of service usage.
observerDelegate = FD:func(FooInState::bar,foo).
someRegisterDelegate(observerDelegate)


Another thing is having the states being controllers themselves. This way, the state –being responsible for the state– can intercept messages destined to the objects in it’s state. So no more attaching observers to some global event subject–the owner state shall be responsible.

Hmm…scratch that. I don’t think I need to intercept anything…

But I do think it is better this way having the state control it’s objects. They do not need register at some global level.

But I can do multicasting, and this makes having the state also being controllers themselves a piece of cake.

So:

someRegisterDelegate = ServiceRegister("SomeServiceRegister","IamMiniMe") //IamMiniMe is the current object, so ServiceRegister can do filtering base legality of service usage.
observerDelegate = FD:func(ThisFooState::bar,thisFoo).
someRegisterDelegate(observerDelegate)
barToken = fooMultiCastDelegateFD.add(FD::func(FooInState::bar,foo))

...some times later...

ThisFooSta0te::barEvent(someBarBarEvt)
{
fooMultiCastDelegateFD(someBarBarEvt)
}


event delegates & interfaces DRY is not an issue.

What I was thinking? I really don’t see problems with DRY in so far as both delegate and interface event system will have classes interested in an event that will have to “implement” events in order to handle them–there is a one to many relationship from consumer of an event to producers. So if you change the signature of an interface you will have to change classes that implement them. And with delegates most cases you simply register for a new event (say you added another argument) and forget about it.

Besides, like I said, as long as they are not many types of objects then it is not a problem (the same situation applies to interfaces). No one is going to write control code for EVERY INSTANCE of an object, only the type of an object (say A.I type).

What I need is to pretty up the system a bit. Implement a system where it is simple to dynamically register for ANY event by looking up their register delegates (either through an hash structure, or enum mappings).

client and server states for project zombie and plus some thoughts on network dead reckonoing

I’m back to working on the project. SO as you know I did some initial hacking of raknet awhile back, and now I need some refactoring–keeping in mind my original ideas for the frame work. The plan is to implement server and client as stateful states, keeping the current EngineController structure intact. (I may want to refactor out the Ogre rendering so the server does not have to start Ogre). Anyway, EngineController still works the same way but start client or server states as stateful states;that is, both will be persistent. The server can even be stateless, it does not matter since it will be the only state running. On the other hand, for client state, some other part of the game can request the engine to start networking as a “service” and the engine will then create the client state. The client state will then do it’s thing (initializing network components; contact server, handle message pumping).

And this brings me back to my original idea on using delegates –as much as possible–instead of interfaces, for the event system. It may seem like this would be a bad idea because it violates DRY (don’t repeat yourself) principal. I somehow (make this is a mistake I would deeply be regretful of) argued myself around this fact, because I argue that if someone changes the function signature all you have to do is define that function for the object that needs this new function signature. Since I never intended to have many types of objects I argued that I won’t have the problem of having to add a new function to MANY objects. I was just trying something new.

Oh yeah, the network dead reckoning thing. I probably will need to use the physics engine on the client side for dead reckoning. We’ll see when we get there.

another short song over a premade sequence sample and project zombie

check it out. It’s “E C#min F#min B E” over a sequence.

I have to work a little bit tonight from home . Anyway, making these songs is fun to me, but that’s it. I’m not trying to go anywhere with this. I got spent more time on doing game development. I tried to do it yesterday, but what happened was I came home around 5am friday so I just didn’t have any energy to sit in front of the computer to work on code when that’s what I have been doing ALL WEEK at work. Just sitting there and coding. *SIGH*

wiki upload

Compresssive sensing for high frequency lighting reconstruction?

You know I’ve been working on Spherical harmonics (I have the thing coded in blender, but that’s about as far as I got) which is a way to reconstruct low frequency lighting. Anyway, I remember reading about compressive sensing (on Terrence Tao’s blog!!! If you want to feel stupid go read his blog, lol. http://terrytao.wordpress.com/2009/05/25/reflections-on-compressed-sensing/; http://terrytao.wordpress.com/2007/04/13/compressed-sensing-and-single-pixel-cameras/#more-25; http://terrytao.wordpress.com/tag/compressed-sensing/), so I’m wondering whether one can apply the method of compressive sensing to the problem of reconstructing high frequency lighting (and whether one can do this efficiently on current hardware).

Well, first of all, I mostly skimmed (if you can even call it that) a few resources regarding compressive sensing, and I recall seeing a paper (didn’t read it) on wavelets reconstruction of HIGH frequency lighting. A note of warning: the point about using spherical harmonics is because one can reconstruct LOW frequency lighting (without ambient occlusion) using only a few terms, allowing for fast reconstruction (it’s just a few dot products) not sure how many terms one needs for wavelets reconstruction (note: I never studied wavelets, but I assume it is some sort of series out of basis functions). Which brings me to the point of this post is that I saw something in compressive sensing regarding wavelets (or a certain ‘family’ of functions) which…I don’t know what the point is. It is just I THINK that these areas are related. SO ALL I”M PONDERING is whether one can apply compressive sensing to the problem of reconstructing high frequency lighting, because it seems that these subjects are RELATED.

Anyway, definitely something to look into. Also, I know for wavelet “type of problems” is !!!definitely!!! (not sure) related to compressive sensing. I remember skimming a paper on reconstruction of fluid dynamic simulations using wavelets. So one can simulate a MASSIVE explosion and then play it back efficiently, or something like that. LOL!

Whatever. I shall tag this post as BULLSHYT.

I’m going to try working on Project Zombie a little bit. I’m currently getting some preliminary networking coding done–in order to generate some interest in the project amongst “the group.”

Spherical harmonics lighting dymstyfied: the prelude

The prelude??? Haha. Anyway, I’m going to talk about spherical harmonics lighting in the next couple of posts. For the engine, I want to use spherical harmonics, along with a sky-model, to have arbitrary BRDF-based shading on surfaces and combine it with http://en.wikipedia.org/wiki/Screen_Space_Ambient_Occlusion http://www.vistax64.com/gaming/203581-crysis-warhead-ambient-occlusion.html for global illumnation. I’m don’t understand all the parts yet, so I can’t tell you about the efficiency. I do know that it will be enough for the look that I want, for now. Just throwing in some stuff which I think will look cool (fast BRDF with dynamic low frequency lighting and ambient occlusion for global illumination).

My goal is to explain each and every part of this in great detail. I will start with the mathematics behind spherical harmonics, where it comes from, etc. I will try my best to get into some details. I have some confidence that I can do this fairly well, because I took courses in differential equations and PDE’s, both of which supplies me with a lot of background. I don’t know how detailed I’m going to get, but I will try to break down all the terms, at least. I don’t know how well this will work out, because I don’t know whether one can explain it without prerequisites. We shall see.

isometric “independent” views?

I mentioned in a previous post about per-pixel displacement map impostors in an isometric setting and how I thought it may be possible to have independent viewpoints–by storing all displacement information using two displacement textures–in the cone (???) of rotation in the isometric perspective (hmm, I don’t know whether stating it this way is correct). Well, I’m not sure if it is possible to do this when doing animation, because the object can be in arbitrary orientations (such that, there may be a surface hidden in both displacement maps). However, it is possible to find a minimal set of displacement textures that will capture the object in full 3d (see …can’t remember the name). I won’t consider any further on the matter of “true imposters,” for I think the memory constraints for that technique is prohibitive (for some quick figures on napkins).

That brings me to… what is the point? Even if I can get something reasonably well…say in the range of 3 to 10 per-animation frame, and I did some quick calculation with this, and taken into account compression (8:1), will require a lot of memory. It may be worth it. But for now, I will just bite the bullet, and go with restricting the view to a single isometric view(old-school). From the engine point of view, I will make it so it won’t matter. Everything else will still be completely 3D, so for scenarios other than the “zombie game,” we can still go full 3D (all the other tech. beside “zombies” will work the same). This is a good decision, I think! I can concentrate on other stuff for now (and maybe come back later, when the time is right^tm)! The other advantage of doing this is ease of implementation! I don’t have to do any stupid imposter things anymore! Hurray!

Why keep imposters at all then? Well, I still want to run the “zombie” stuff on the GPU. And I feel that this is the quickest way for me to get things done at this point.

ProjectZombies and networking

I’m back to talk about thoughts on whether we can get project zombie (i.e.: that stupid game with lots stuff running around– that one!) over the network.

Well… the latest game play I’m imagining (or scenario, depending on whether you are conversing about the MMO) is some sort of Tower Defense game, where you are controlling a space ship (that you, the avatar, will have the ability to get inside and control) to battle –insert evil guys to fight–. Latest storyline I’m toying with, is that you are

type of character flying around doing nothing, until you hit this planet with –near-future equivalent tech– and they are battling the GHOST army… a unspeakbly evil magic entity with an army of GHOST…that out of nowhere (actually, in the middle of a city) begins their un-speakbly evil plan to kill kill kill! They must be stopped! (Can you imagine the opening scene; the camera pans to the city center; ominous fog begin to creep-out; shinny lights emanating from it; then undead GHOST army begin rushing out; WTF to do???!!!)

So it’s a mixture of chaos between GHOST (magic), near-future tech, and insane high-tech. Shit blowing up everywhere!

Or if not that…just have simple little RED versu BLUE and you fly around blasting the shit out of everyone.

…

So is it possible to do this as a multiplayer game? I think it is! We do the crowd simulation on the client. We generate the cellular automata map on the server, update the this map occsionally (every second?)…The map controls the behavior of the crowd! To sync the clients crowds we simply have to make sure the seed is the same, and assuming they are then they should be synced! We can also occassionally sync using the server too.

For entities that are not crowd based, we simply track their location on the server, and update each client at a fast rate, to sync. And have the client interpolate the orientation and position. Like a traditional shooter game, for example.

Server/Client using RakNet

I started some preliminary server/client work. I’m using the RakNet library. I don’t have much to comment on except it seems like a really nicely-developed engine, with lots of cool-features very useful for a online UDP based game.

It’s a simple client/server. So simple right now all it does is connect the server to the client. This gives me a good excuse to present my desktop, however(note the console’s connection msgs):

Although “we” have been brain-storming on a massive multiplayer game (oh, the dreaded MMORPG as a first project). Frankly, I think we are just trying to do too much. Well, I promised that we’d build this thing as modules with the eventual hope of getting our utlimate dream game–and that’s fine with me–but I have some doubts on whether we can realize such an ambitous project as a MMO, without careful planning. We have some planning, it’s just I really don’t think just making a list and just going over details while sitting around consistue a good plan. What I mean by planning is setting out and really charting the entire system, with proper tools. Sure, I could do that, but I don’t think I have the time right now to fully chart such an ambitious system.

What I want to do, is to take the stuff I have right now, and expand on that, to make a fun, cool-looking, small little multiplayer project. Along the way we will gain the experience in building a more ambitious project, and a project that we can actually get it done! We can then build on top of that experience, whether it is reusebly software code, or models, or other things.

Though I admit, maybe this is exactly what we mean we are talking about building it up a little by little…but I feel that we sometimes tend to go over-board and chart some really crazy shit, that not even some of the most advanced MMO out there is doing now. But dreaming is good.