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.
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.
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.
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.
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?
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.
Based on what Lummox said here, I'd assume that the local DD+DS outperforms the DS-only case for multi-core CPUs.
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!
Actual laughter was produced
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.
If/when this is implemented, will the map editor also be affected?
It shouldn't need to be.
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.
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