Pixel Movement in Feature Requests

Page: 1 2 3 ... 8 9 10
#180 Jun 29 2011, 5:19 pm
We'll investigate pixel movement in tandem with more native big-icon handling, since the issues overlap (eg, collisions and location handling).

The question for me is whether we want to keep everything backwards-compatible, maintaining both tile & pixel systems, or whether it'd be better to just spin this off into a separate system. I'm leaning towards the latter because it's a lot easier (and we're already taking this approach with the Flash project by making those games a limited, specialized subset of BYOND). Really, the roguelike verb/tile model is pretty obsolete for the types of games people are making these days.

As far as a system to generally parallelize BYOND code.. no, that ain't gonna happen. We can and should offload certain existing operations (such as file transfer) to other threads, though. That's a long overdue request.
#181 Jul 18 2011, 11:10 am
See: Software Transactional Memory.

I personally plan on doing much of the heavyweight processing of my own project (so far including map generation and probably eventually including some pathfinding stuff) in a separate library. Map generation is already multithreaded and pathfinding can also be threaded out in a straightforward manner.
#182 Jul 26 2011, 4:15 pm
Tom wrote:
As far as a system to generally parallelize BYOND code.. no, that ain't gonna happen.

Wuss! Yes it took me a month to come up with that :-)

I figured this was the most relevant place to ask this question: If you host a BYOND game with Dream Daemon and connect with Dream Seeker on the same computer, they're separate processes and they'll make use of multi-core CPUs. If you run the game through Dream Seeker and host, is there just one process (dreamseeker.exe) that is both the host and your client (that may not make use of multi-core CPUs)?

I ask because games with higher framerates are more demanding on the CPU for both the client and server (especially if the client isn't using hardware rendering). If everything is single-threaded and there's one process acting as the server and the host's local client, if it doesn't make use of multiple cores the higher client CPU usage (due to the increased framerate) will slow down the server.
#183 Jul 26 2011, 4:19 pm
Yes, the dual DS/DD is single-threaded and as such less efficient on a multi-core machine. In practice, I'm not sure how much difference it makes for a single-player game (you'd have to test to see), but I definitely wouldn't recommend hosting multi-player games from DS because the client usage could interfere with the server.

That said, multithreading this special case of the client-server should be do-able, since the code is essentially two separate pieces already.
#184 Jul 26 2011, 4:24 pm
Tom wrote:
That said, multithreading this special case of the client-server should be do-able, since the code is essentially two separate pieces already.

Is there already a request for this? / Should I make a feature request for this?
#185 Jul 26 2011, 4:30 pm
We'll keep it in mind.

You might want to see if a local DD+DS single-player game outperforms (via "eyeball" test) the DS case though.
#186 Jul 26 2011, 4:37 pm
Based on what Lummox said here, I'd assume that the local DD+DS outperforms the DS-only case for multi-core CPUs.
#187 Jul 27 2011, 2:40 pm
Maybe if BYOND is changed to a fully-pixel-based system, Forum_account can make a shiny new library called "Tile Movement" and everyone will be all over it!
#188 Jul 27 2011, 3:05 pm
Actual laughter was produced
#189 Aug 10 2011, 5:11 pm
Kaiochao wrote:
Maybe if BYOND is changed to a fully-pixel-based system, Forum_account can make a shiny new library called "Tile Movement" and everyone will be all over it!

^Lol'd.
#190 Aug 27 2011, 10:26 pm
If/when this is implemented, will the map editor also be affected?
#191 Aug 27 2011, 10:26 pm
It shouldn't need to be.
#192 Aug 28 2011, 8:12 am
Well, for the map editor, you should have a small change, when placing tiles it should be much like the interface editor with a "snap to grid" and it's automatically set at world.icon_size, however you should be able to take that off so that you can place objects dynamically.
#193 Sep 2 2011, 4:13 pm
#194 Sep 2 2011, 5:25 pm
Did... did Falacy just make a joke? And it was actually amusing? And native pixel movement? Did the world just invert?
Page: 1 2 3 ... 8 9 10