Code center > Darwinbots3

About Darwinbots3

<< < (7/10) > >>

Numsgil:
On the issue of the SVG getting quite large quite fast, I think it supports compression.  See SVG#Compression.  So the server could spit out a compressed stream of SVG files.  Even if we do a complete SVG file once a frame, that might be fine bandwidth-wise for the local host.

Peter:
A uncompressed stream on localhost would be as good as compression, it would only compress it send it to the browser which decompresses it.

With the league topic in mind, it would be nice to be capable to store matches on the server and play them like a video in the browser. Apart from storage space, it would be best if the whole SVG can be properly loaded as a file at once.

A lot of the current growing SVG is due to slow moving particles(slipstream TestBed). With 1000 particles it can climb up quite a bit. A way to decrease is to keep track of particles and for example state that it moved one to the left between the 9th and the 10th second instead of each frame a small update. I'll try playing with it when I can properly can reproduce the same animation as DX9 gets.

It's actually not that far from sending out a complete SVG every frame currently. :P

Numsgil:
Yeah I don't think storing a complete match would be that hard.  The positional data frame-to-frame has a lot of spatial coherence, so it's possible to compress it.  Either with some standard compression algorithm like gzip or with something that understands what the data is, like fitting splines to it.  It'd be nice if whatever the full match "movie" format is, a browser could load it up without any extra help.  But even if we have to write a small app to "uncompress" the stream and send that to a browser, I'm fine with that.

I guess there's two use cases to consider: a realtime viewer of what the DB3 simulation is currently doing, and an "offline" movie format that can playback a recorded stream.  For the realtime viewer you might not be able to do much better than sending a fresh SVG every frame.  At the very least I'd be interested in what sort of framerate you can get from that.  Graphics doesn't block the sim from running, so even if you can only manage 20 FPS the sim can run unhindered at 100s of cycles/sec, so that's probably good enough.  It would be a good excuse to look in to only drawing things the current viewport can see certainly.

For the offline movie format, it's a bit trickier, especially because objects can get created and destroyed over time.  But in principle I'd start with a big array and set the calcMode to discrete, and then later on we can apply some type of compression to remove elements that the different SVG calcModes could handle.  eg: if something is well modeled as a series of splines we can chuck all the intermediate values that aren't necessary to specify the splines and set the SVG calcMode to spline.

Botsareus:
As this project is maturing it begins to make more and more sence to me. Some of the rendering ideas sound incredible. Also the descriptions of the collision engine and the shapes/corpse mobile shapes sounds cool.

I am mostly concerned about backwards compatibility. To the point where I am scoping out my own port of DB2 based on the Revelations Book. :P (Can not give more detail then that)

Maybe one day we can do a hybrid and keep the best of both systems.

Numsgil:
It might be possible to hook in some of the DB3 modules to DB2.  It's a bit tricky because you'd have to go through COM, but it's possible in principle.  Sunweaver, for instance, could pretty much drop right in without much effort.  Blacklight would be more effort but still not too hard (the hardest part would be figuring out how to build up the data hierarchy for what to draw.  Either XML or manipulating instances of classes.  Probably XML (or something like it.  Lua code isn't a terrible data format, actually, and a bit more compact than XML)).

Not a task I ever really want to do myself, but something I'd support.

Going the other way, pulling in DB2 code to DB3, is a different story.  DB2 code is not really modular, and trying to extract out individual components from it would be self flagellation at best.  It could be made modular, but that's a massive refactor, and I don't think it could be done without introducing numerous new bugs.

Navigation

[0] Message Index

[#] Next page

[*] Previous page