To browser these website, it's necessary to store cookies on your computer.
The cookies contain no personal information, they are required for program control.
  the storage of cookies while browsing this website, on Login and Register.

Author Topic:  Unity 2D client  (Read 123 times)

0 Members and 1 Guest are viewing this topic.


« on: 06, February 2020, 11:42:58 »
Yeah, the new client is still a work in progress. ATM there is no support for lighting (which AFAIK is how the obstructsview works) so it should look roughly the same when it's closer to finished.

Something I've considered is a way of doing smoother/dynamic lighting. At the very least, finding a way to smooth transitions between different light levels so it's not perfectly blocky. IIRC you did something fancy with lighting a long time ago that never made it to release so if you have any tips I'd appreciate it.

Yep, I spent  a while pondering 'smooth' lighting. I couldn't get my head round the math, unsurprisingly, but I think the outline id this:

server sends a 22x22 'light map' as well as the 17x17 object map (22 = 17 + 5 [IIRC the max light source is 9x9 so half of this dismeter])/ The light map includes the central squares and brightness of the actual light sources (we don't send brighttbess per square as now).

Client draws object map (as now but no lighting effects). Then oberlay this with circles of light of appropriate brightness and radius according to light map. Then overlay this with pure black squares where player can't see (as per object map).

I think this should give a nice enough approximation of reality. I don't think SDL (even 2) can do this sort of thing, but Unity?

(It's not so simple as 'overlaying circles of light'. Maybe make a big 22x22 diamond of darkness at the ambient light level, the cut out duitsble circles centered on light sources, then overlay this.

My next thought was multivoloured light...

FoW is  a v cool effect. IIRC the code still exists but is disabled in current client (I hhad FoW in SECoND).

But anyway, lighting is one of my favourite effects and quite undeveloped in Dai.

EDIT: Not 22z22, but 27x27 so 17x17 is centered with a border of 5 on all sides.


« Reply #1 on: 07, February 2020, 10:55:46 »
What's the deal with arches for _people_s client? Are they just bigger?If so there's a pottential problem in that the server/client can't send/receive data above a certain size. This came up with a detailed ship Joe made years ago (I began looking in to a fix but...) So if the image is already in the client's local face pack, BP. But if it must be fetched from the server and has (IIRC) a >32 bit crc then we get garbage.

A solution is maybe chop up such images into multiple packages at send then reassemble them after receipt.


« Reply #2 on: 07, February 2020, 14:50:11 »
Yes I also mentioned this to People and he came up with a work around.  Mainly doing this because a larger resolution is a big step forward, getting away from 800x600 is good.  Also this challenge I've gotten myself into seems so impossible to finish, that I just couldn't resist trying it. ;)


« Reply #3 on: 07, February 2020, 23:32:16 »
So my plan for storing faces is essentially to entirely change how the client retrieves arches. The game server will no longer be involved with faces (and eventually anims). I'd like to have a "data server" which handles this.

Essentially, the client maintains a "facepack version" - just a simple incrementing variable in a text file. The "data server" has a database of every version of the facepack, and every new version will have an xdelta diff from the previous version.

So if you have facepack version 35, and the dataserver has version 40, download the last 5 changes and apply them to your facepack. Then set the client's facepack version to 40.

I plan to do this during initial server connection, so the client will never have to deal with the ugly "LOAD" icons whenever Joe decides to update half our graphics :) I also would like to have at least 2 data servers (one for EU and one for NA) so that clients can pick whichever has lower ping. I think this, combined with the lower overhead on the actual gameserver, warrants having an extra server or 2. I can front the cost of these servers.

There are obviously some nuances here which will need to be resolved - such as players running local servers, or perhaps a dev server with different graphics than the main server. People running local servers might just have to suck it up and use gfx_user whenever they want to change graphics.
-- _people_ :)


« Reply #4 on: 08, February 2020, 10:01:37 »
sounds good, but...

part of the reason (i would think) for "LOAD" is we only fetch updated gfx when they're needed. in theory this means smaller downloads per client and fewer bw bottlenecks for the server.

Example: Joe updates all the raas, lom, vh, and skel dragon faces. Under current scheme these are fetched as needed as each playeer progresses through DT (yes, lots of "LOAD" which I agree is horrid). Under your scheme EVERY client fetches ALL new gfx at connection, eveb, eg, when the player is new and the gfx won't be relevant for many weeks.


« Reply #5 on: 14, February 2020, 20:13:49 »
I've just updated the download for the demo with my progress so far. Significant changes include adding a server select screen (though it doesn't seem to like Main server), line of sight works now (to include Fog of War), lighting, and movement (mouse needs work, keyboard uses arrow keys for now).

Double-height faces (ie walls) are temporarily disabled as I need to rewrite them to be much more performant. As in the previous build, exiting is not yet implemented so use Alt+F4 to close the program.

Download can be found at:

Soon I plan  to add some documentation and put the source on Sourceforge.
-- _people_ :)


« Reply #6 on: 14, February 2020, 21:43:22 »
Happy to see you still working on this, it gives me motivation to keep going with the updated graphics. 

Edit:  Did get some sort of error trying to run it.
« Last Edit: 14, February 2020, 21:55:23 by Joe »


« Reply #7 on: Yesterday at 02:02:49 »
Try the link again. I just removed a lighting plugin I was experimenting with (it's not right for our use case). IDK if that's what's causing the false positive but as we don't need it, it's worth removing. I also built it as a release version rather than development so that might help.

If that doesn't work I'll have to try Avast myself and see what's causing it to flag.
-- _people_ :)


« Reply #8 on: Yesterday at 02:10:03 »
Yup that fixed it, cheers.

Wow I really like this!  Having the directional buttons use arrows is really nice, and holding 2 directions results in an angle is how it should work.  Well done, I would use this instead of mouse any day.
« Last Edit: Yesterday at 09:32:06 by Joe »


« Reply #9 on: Yesterday at 12:46:20 »
Wow I really like this!  Having the directional buttons use arrows is really nice, and holding 2 directions results in an angle is how it should work.  Well done, I would use this instead of mouse any day.

Never thought of this. IIRC SDL can't detect simultaneous keypresses (except for modifierd like ctrl, shift, alt). But can unity (and am i wrong about sdl)?


« Reply #10 on: Yesterday at 16:40:41 »
Yep, Unity handles it fine. IDK about SDL but I'd imagine you could probably hack together a solution for it. Under the hood, Unity converts anything mapped as a "direction input" to a vector, which also means controller support works almost out of the box (on a 64-bit build, it's broken on 32-bit for now). Although playing around with it, analog stick movement doesn't seem to be a very good fit for Daimonin.
-- _people_ :)


Related Topics

  Subject / Started by Replies Last post
0 Replies
Last post 26, July 2005, 05:17:58
by Grahf
5 Replies
Last post 15, July 2006, 18:21:46
by longir
5 Replies
Last post 07, August 2007, 05:41:23
by bugbunny
33 Replies
Last post 31, May 2011, 13:32:25
by clobber
0 Replies
Last post 22, July 2013, 03:34:19
by _people_