ID:2708338
 
What a week!

Okay, maybe that was a bit too dramatic. It's been a good week, but as you may have noticed 514 is not in the stable channel yet. That's coming very soon and I expect it to be next week, but I've made some late progress on bugs and want to see if I can squeeze in any more before we get there. Next week is my target. I certainly wasn't going to release today. The Friday curse is real, but can you imagine the added factor of moving to stable on Friday the 13th? Hard pass.

I think I finally solved the issue where high-precision timers cause Dream Seeker to choke if it bogs down, and I solved it thusly: there's a fallback on a regular old Windows timer. The method I was trying to use to fall back before apparently didn't work as expected, but the new one is working great.

Meanwhile I'm already looking at 515 stuff and I've decided to try something ambitious for the language. I think the time has come where it's possible to create a limited form of pointers: references to vars or to list elements. The only thing really missing is a means of interacting with a proc's local vars; but we already have something for the arguments list, so I don't think that's going to be a deal-breaker.

I do need to return to figuring out how to upgrade the renderer, and that's gonna need some serious thought. But it'll be easier coming back to that after I've been out of the weeds for a while, I think.

If you have any language features you want to throw on the table for consideration in 515, go right ahead and pitch them. This is the time!

Also over the weekend I did a little work on the website, that I think has solved our https issues—at least mostly. A lot of users were getting kicked into secure mode by their browsers and it was causing all sorts of problems, but that should work fine now in theory, if you're on the www subdomain and not the secure one. The secure subdomain is still just for account stuff, hub editing, etc., as it was always intended. The software is still gonna need to stick with http for now, especially for download links for hub entries, but at least most of the issues with browsers getting aggressive about https should be handled.

Thanks everyone who's contributed to BYOND recently through Membership and other donation platforms. Your support is greatly appreciated.

I finally achieved victory over the mosquito swarm, or else they just went away on their own. Maybe the soap down the basement drain finished them off; at least I never saw any in the zapper, although we did get a bunch of drain flies and a housefly. Hopefully that little war is behind us, until I become a supervillain and can finish off the rest of the mosquitoes for good. Until then, we're in the last gasps of summer so make the most of it.
The mosquitoes are just assembling for their final push, don't celebrate yet.

Feature request side of things, would be great to see https handling as part of a potential 515 wishlist.
Native libnoise integration.
Instantiatable random number generators.
Primitive typing. "as int" "as long". "as byte" "as short"
Static procs.
Inline procs.
Native map saving and loading.
Some reflection ideas:

ID:2189056 (dereference proc call to proc typepath for use in callbacks (proc(blah) = /datum/proc/blah))

runtime access to variable typing. (var/datum/blah/datumblah;typeofvar(datumblah))

null/special safe type access (type(anything) = null|typepath)
In response to MrStonedOne
Runtime access to var typing isn't possible because vars don't store type info in the .dmb, but I think it'd be possible to do something like that at compile-time.
In response to NSBR
NSBR wrote:
Secondary maps w atoms, above main map, glitch the game if they're not cleaned properly on deletion

No test case was ever posted for that issue.

animate() bugs when there is another animation taking place

The description of this issue needs clarification.

ImportText doesn't work directly referencing a source by name

Might not be a bug.

client.fps gliding flicker

Needs a fresh test case. Gliding timing has changed a lot since then and it's likely this is no longer an issue.

On-focus and On lose focus for the map element

I'm not sure there's a use case for this.

input as num|null doesn't allow to send null as a value

At this point I'm not sure what's actually being requested there; it needs a new thread for a feature request.

Icon Editor: New frames appear as copies of the last

The current behavior is intended. Clearing the new frames is trivial, and it's more often more useful for them to be copies of the previous frames.
In response to Lummox JR
Lummox JR wrote:
NSBR wrote:
Secondary maps w atoms, above main map, glitch the game if they're not cleaned properly on deletion

No test case was ever posted for that issue.

It was sent to you on the Pager DMs a while ago. I don't have it on my computer anymore but if you follow the steps it is 100% reproduceable.

animate() bugs when there is another animation taking place

The description of this issue needs clarification.

Clarified it better on the thread.

ImportText doesn't work directly referencing a source by name

Might not be a bug.

It is. Replied to you on the thread.

client.fps gliding flicker

Needs a fresh test case. Gliding timing has changed a lot since then and it's likely this is no longer an issue.

I played around with the test case again and it indeed got fixed. This can be closed as resolved.

On-focus and On lose focus for the map element

I'm not sure there's a use case for this.

It would make my life easier because I would know if the client hopped off of the chat input to the map instead of to another window, etc. I can only check this with winget. On focus on the map would help me avoid that.

input as num|null doesn't allow to send null as a value

At this point I'm not sure what's actually being requested there; it needs a new thread for a feature request.

Done.

In response to Lummox JR
Lummox JR wrote:
The current behavior is intended. Clearing the new frames is trivial, and it's more often more useful for them to be copies of the previous frames.

just to chime in on this, i agree it should be turned back to blank frames. if someone wanted to copy a frame it's just as trivial to add it to a blank frame, but to have the behavior pushed on you by default when you've never had a use for it gets annoying over time
For the renderer, I say start with the DirectX 11 API. That way, you can move up gradually from Direct3D 9 (which is supported by the DirectX 11 API) to Direct3D 10 (Shader Model 4.0) or even Direct3D 11 (Shader Model 5.0).

From personal experience, that API is actually more pleasant than DirectX 9's. Be aware that would mean eschewing Windows XP and early service packs of Windows Vista.

Edit: This could be a great way to maintain legacy support with Direct3D 9 hardware too (similar to World of Warcraft Classic's Direct3D 11 Legacy API feature, which I believe targets earlier devices). ;)
In response to Bandock
I like this one a lot.
In response to RootAbyss
The most convenient solution is to put this and many other things into a documented .cfg file, instead of them being hardcoded.
In response to Bandock
Bandock wrote:
For the renderer, I say start with the DirectX 11 API. That way, you can move up gradually from Direct3D 9 (which is supported by the DirectX 11 API) to Direct3D 10 (Shader Model 4.0) or even Direct3D 11 (Shader Model 5.0).

From personal experience, that API is actually more pleasant than DirectX 9's. Be aware that would mean eschewing Windows XP and early service packs of Windows Vista.

Edit: This could be a great way to maintain legacy support with Direct3D 9 hardware too (similar to World of Warcraft Classic's Direct3D 11 Legacy API feature, which I believe targets earlier devices). ;)

If we're going to move to a programmable pipeline, it should be OpenGL.
In response to Ter13
Ter13 wrote:
Bandock wrote:
For the renderer, I say start with the DirectX 11 API. That way, you can move up gradually from Direct3D 9 (which is supported by the DirectX 11 API) to Direct3D 10 (Shader Model 4.0) or even Direct3D 11 (Shader Model 5.0).

From personal experience, that API is actually more pleasant than DirectX 9's. Be aware that would mean eschewing Windows XP and early service packs of Windows Vista.

Edit: This could be a great way to maintain legacy support with Direct3D 9 hardware too (similar to World of Warcraft Classic's Direct3D 11 Legacy API feature, which I believe targets earlier devices). ;)

If we're going to move to a programmable pipeline, it should be OpenGL.

Yeah, OpenGL is a good option too. In fact, having both renderers is a good option; though OpenGL is finicky on AMD/ATI hardware while fine on nVidia hardware (at least on Windows; heard the opposite on Linux). Not very difficult either since I was able to put together an OpenGL 3.3 renderer months after I put together a DirectX 11 (Direct3D 10 compatible) renderer.
I'd say go for SDL or some other High Level API that provides the "portability wins" without the extra work and headache, put the extra work on things that matter more. Or why not Vulkan then? It's 2021.

What are the "use cases" for the programmable renderer? What will it let a designer do then than now?
async procs which return a /task or /awaitable or /future, await keyword

A lot of things in game programming are inherently asynchronous. For example, imagine a menu system using a browser window popup. Architecturally, this would include a lot of wiring around Topic() and other things, would have to be implemented over several procs, and it is hard to scale if something needs multiple selections. With the above in place, usage logic could be reduced to something like:
mob/proc/async/Kill(players, weapons)
var/player = await Select(players)
var/weapon = await Select(weapons)
world << "[src.name] killed [player.name] with [weapon]"


And the implementation would just assign the player a /task object and then call task_obj.Complete(selection) in Topic()

Some existing procs could also benefit from such a thing; e.g. think await flick(/*...*/) (blocking) vs just flick(/*...*/) (non-blocking)
Would asking for Inline C++ be too much ;)
Anonymous functions. A way to define procs as variables so that they can be passed and or called as an argument or within the scope, without having to be defined on the datum level.

var/proc/add_one = (counter)
world.log << counter + 1

add_one(0) // 1


https://www.javascripttutorial.net/ javascript-anonymous-functions/
^^ This but with a better syntax
In response to Hiead
Hiead wrote:
async procs which return a /task or /awaitable or /future, await keyword

already exists (kinda), but is undocumented

/proc/blah()
set waitfor = FALSE


you can also wrap it in a task status framework with your own datums, as it will return . once something blocks:

#define TASK_STARTED 1
#define TASK_FINISHED 2
/datum/task
var/status = TASK_STARTED
var/return = null
/datum/task/proc/waitforfinish()
while (status != TASK_FINISHED)
sleep()

/proc/doblah()
set waitfor = FALSE
var/datum/task/task = new()
. = task
task.result = blah()
task.status = TASK_FINISHED


You can even get really fancy and make something that takes a list of tasks and returns once they all finished:

/proc/wait_for_tasks(var/list/tasks)
for (var/datum/task/task in tasks)
task.waitforfinish()


Its handy if you want to do a bunch of blocking things at once, like close all doors in a room and wait until they are all closed.
Page: 1 2