ID:2366418
 
(See the best response by Lummox JR.)
Problem description:

First off, I'm completely new to this platform. Correct me if I'm wrong somewhere.

I've been studying BYOND for some time and found myself thinking about performance and rendering. Read through some manuals, code snippets and libraries and never found an answer to my question.

My question is: Is there any way to get access to and override low-level rendering functions or bypass them completely and use different rendering sub-system? I know that BYOND uses directX, so on the paper this idea looks plausible.

I've been thinking about some things I'd always wanted to add to the Space Station 13, which will never work with current rendering system. Even with some godlike optimization sorcery, mostly because of ss13 laggy engine.
Nope. BYOND sacrifices that level of control for ease of use.
Best response
What sorts of things were you looking to add? They might be worth brainstorming as 513 features.
In response to Lummox JR
1) Directional lighting with semi-soft shadows. Been thinking about this feature for a while now.

2) Direct3D particle and shaders systems. Will make any game a lot prettier. Especially shaders.

3) More GPU sided render in general. Will greatly reduce CPU cost of game loop. At least I think so.

And to more general features:

4) A unicode support.

5) If unicode support is not going to be implemented, then maybe a method to encode JSON in different locales.

6) Better external libraries support. Things are not very convinient and easy right now with this feature.

7) Standard HTPP requests. I know that only GET request is supported right now.

At least one of these will be a significant improvement.
And again, if my only option is hooking byond through directX drawcalls, can you please give me some info about what version of directX byond uses and which sub-system? Ddraw, direct2D or direct3D?
In response to Qed
Qed wrote:
1) Directional lighting with semi-soft shadows. Been thinking about this feature for a while now.

The key difficulty in that is that we're working with 2D sprites. Shadows are cast by 3D objects. For solid walls this is obviously a lot easier to tackle, though.

I've actually done some reading on how shadowcasting has been achieved by others, but it's a very difficult procedure and will degrade performance with additional lights in the scene (plus you need to account for lights just out of view).

To tackle something like this my preferred method would be to use the new filter system for it, supplying data somehow that could be used for that purpose.

2) Direct3D particle and shaders systems. Will make any game a lot prettier. Especially shaders.

We're using shaders already. But if you mean custom shaders, I don't think that's feasible at all. The better question is, what kinds of features would you want out of a shader that might be doable with the new filter system or something similar?

3) More GPU sided render in general. Will greatly reduce CPU cost of game loop. At least I think so.

The render itself already puts quite a lot onto the GPU and tries to minimize its own work. Where the CPU comes in is the conversion of atoms to icons and the subsequent positioning/sorting of those icons, which is what I've been optimizing fiendishly lately.

There might be some potential improvements on a few things in the graphics pipeline--in fact I'm convinced there likely are--but I don't think that's currently any kind of serious bottleneck.

And to more general features:

4) A unicode support.

It's on my radar. A big project, but definitely worth looking into.

5) If unicode support is not going to be implemented, then maybe a method to encode JSON in different locales.

You lost me here. JSON is locale-agnostic AFAIK.

6) Better external libraries support. Things are not very convinient and easy right now with this feature.

Not sure what you mean. What needs to be changed, exactly?

7) Standard HTPP requests. I know that only GET request is supported right now.

Indeed. I've looked a little into handling POST, but not nearly enough.

At least one of these will be a significant improvement.
And again, if my only option is hooking byond through directX drawcalls, can you please give me some info about what version of directX byond uses and which sub-system? Ddraw, direct2D or direct3D?

BYOND uses Direct3D 9 and D3DX for a lot of grunt work, but that's all subject to change. Also hooking isn't really an option anyway.
In response to Lummox JR
I should've told more details about JSON locale problems. I've been tinkering with parcing text to JSON to send it into external files and found out that non-english characters are corrupted in process. I suspect it has something to do with how BYOND encodes characters.

About external libraries. Strings only interface narrows down possible options. No callbacks doesn't help either. Can I(and possbily many more coders) hope that things will change in future updates?
The trick is being able to tell what the calling convention for a function is. Without having an indicator of that, there's no way to deviate from the one simple option.

For the JSON, remember BYOND is working with a code page 1252 encoding, not with UTF-8 (yet). Your parsing is likely getting mangled by your library routines not expecting basic ASCII.
In response to Lummox JR
I'm in favor of a better C API.

Lummox JR wrote:
The trick is being able to tell what the calling convention for a function is. Without having an indicator of that, there's no way to deviate from the one simple option.

This isn't entirely true. For example, consider the following C signature:

DmObject *Foo(DmObject *self, DmObject *args);

Where perhaps DmObject is some type defined in, say, byond.h. Every argument (string, object, etc) would be passed as a DmObject pointer and have a generic way of querying it. None of the actual DM objects are DmObject, but pointers of such can be cast to it. See also: Python's C API, with particular emphasis on PyObject, PyListObject, PyLongObject, ...

Note that I stole the signature straight from Python:
PyObject* Foo(PyObject* self, PyObject* args);

The returned pointer could be allocated with some API-defined methods and you could impose the following constraints:
  • Ownership of the returned pointer (and any contained pointers therein) is transferred to BYOND. The user should never modify or free a pointer that they return to BYOND.
  • The argument(s) could be immutable, if there is concern of data-races, thread-safety, etc. (i.e., What if you spawn code that modifies x, and then call a C method that also modifies x?) Making the arguments immutable also alleviates having to track them for changes.
In response to Hiead
You didn't actually address my point, though, which was that the server has no way of knowing the expected arguments or return value of the function. The expectation currently is that it always takes a string and returns a string.

What you're talking about is a way of passing those arguments, but that's moot if the server doesn't know if it's safe to do so.
In response to Lummox JR
Lummox JR wrote:
You didn't actually address my point, though, which was that the server has no way of knowing the expected arguments or return value of the function. The expectation currently is that it always takes a string and returns a string.

The function always takes 2 DmObject * and returns a DmObject *?

It's still a uniform signature, but the data getting passed around is substantially more usable and meaningful. I don't see how it's logistically harder to handle, it just requires more effort in building an SDK including the required types and methods to inspect and create those types.
In response to Hiead
Hiead wrote:
Lummox JR wrote:
You didn't actually address my point, though, which was that the server has no way of knowing the expected arguments or return value of the function. The expectation currently is that it always takes a string and returns a string.

The function always takes 2 DmObject * and returns a DmObject *?

It's still a uniform signature, but the data getting passed around is substantially more usable and meaningful. I don't see how it's logistically harder to handle, it just requires more effort in building an SDK including the required types and methods to inspect and create those types.

Yes, that's an elegant system, but you can't get there from here. We have a system based on string in, string out right now. That can't be changed as it would impact existing games. So the big issue is how we could get to a system that would allow for that, or for more varied signatures, without breaking what we already have.
In response to Lummox JR
Lummox JR wrote:
Yes, that's an elegant system, but you can't get there from here. We have a system based on string in, string out right now. That can't be changed as it would impact existing games. So the big issue is how we could get to a system that would allow for that, or for more varied signatures, without breaking what we already have.

Maybe the internals are way kludgier than I expect, but what about this?
  1. Create SDK as outlined above.
  2. Create call_c proc in DM: call_c(LibName,FuncName)(Arguments) and/or call_c(Object,LibName,FuncName)(Arguments)
  3. Deprecate call(LibName,FuncName)(Arguments) without removing it.
In response to Lummox JR
Btw, can you elaborate on this new filter system? I tried to find what it is and how to use it and found nothing but feature requests.
F1 in Dream Maker, Topic tab, 'Filter effects'.

Might still be beta version only, I'm not sure.