OpenGL context (or multi-threadding with thread safe drawing functions)

I was wondering if it was possible to create an OpenGL context within MUSHClient?

I've been developing a plugin(s) for the Discworld MUD specifically an auto-mapping component.

I've got it working very well (yes I know the lack of room IDs makes it very hard but I've developed a heuristics approach which converges on the true position combined with automatic data stitching to correct false assumptions)

The map renders in real-time with smooth animation, allowing the user to drag around and zoom in and out.

I'm a game engine developer normally and I've used every trick I know to improve performance without developing a quad-tree based image caching system - which I believe can be achieved with hidden mini windows as off-screen buffers and the MUSH functions for capturing a mini window as an image - build up data across a number of frames to keep things smooth and use image re-scaling during zooming until the new data is ready.


However such a system will take a while to write and benchmarks suggest I'm not going to get the performance I'd like when zooming out to the kinds of scales I'd like.

It would be fantastic if I could create an OpenGL context and offload expensive raster operations to the GPU, I see that MUSH + Lua supports com objects so perhaps there's a solution there but does anybody have a working solution?

I can use the socket functions of lua to just pipe map/movement data to a program of my own and render things there but ideally I'd like to keep everything inside MUSH.

Any thoughts? ideas?

Also do multiple plugins run in multiple threads? I know of lua co-routines but my understanding is that they don't actually make use of multiple threads and are in fact just managed by a type of scheduler sitting on the Lua VM.

If there's a way I can use multiple threads and render to separate images from each thread then that'll also be fine.

Can I use DLL's in scripts? (not a great help as I don't want to transfer data via files as the delays will be unacceptable and the per-pixel access provided for images isn't going to be fast enough, certainly not when using a script as the go-between between my DLL and MUSH's images)

Is any one scripting language faster for MUSH's rendering functions?

Not at present.



I presume you've seen the auto-mapper done with miniwindows and Lua?



I've found the existing miniwindow mapper works quite smoothly.

Examples: https://vimeo.com/80318832 https://vimeo.com/80305761




A DLL is probably the easiest.



No. Coroutines just let you pause a script while waiting for something to happen (eg. input from the MUD).



Yes, see: http://www.gammon.com.au/forum/?id=4915




The rendering is internal (ie. in C++) but I have found Lua pretty fast.

Thank you for your time Nick and Thank you for an incredibly well written piece of software :)

I wasn't aware that there was an existing mapper, this is for Aardwolf I take it? very nice! lovely and smooth yes.

I'll take a look into using DLL's, I could always inject into Mushclient and render like that instead I suppose.


If anybody is interested I'll post my work when I'm complete, love the mapper but I'm aiming to render regions with dimensions in many thousands of characters so I needed to adopt a more complex caching paradigm, plus the Discworld mud without room ID's and changing room descriptions (so no simple hashing) requires a different approach to maintain a good dataset.

Thanks again Nick!

See this post: http://www.gammon.com.au/forum/?id=10138

Installation details for any MUD:

http://www.gammon.com.au/forum/?id=12635



It's quite fast and works pretty well. I had it going on my own version of Smaug, an adapted version comes with Aardwolf, and they are using it on the IRE MUDs.

Examples:

The ones I did for Aardwolf and Achaea used a SQLite3 database to hold the rooms. It only has to read what it needs (it works outwards from the player location) and caches recent reads in memory anyway. You don't really notice any slowdown when using it.

Ahh! I have studied the mapper and I understand the motivation for the design now, the way your render the rooms by walking out from the current location is actual *genius*

If a MUD has rooms that overlap with no clearly defined region boundary your technique is ideal and even if there are separate regions (an exit being a portal to another city for example) your system *still* works fine, requiring no special knowledge of regions or even the stride length of the region.

Very much a generic mapper!

Plus your walking technique is also strikingly similar to the first step of an A* path finder meaning should path finding be added, some heuristics data can be stored at the rendering phase that'll result in faster path calculation should the user request it.

My technique does not allow for overlapping rooms and requires me to notify of a change in region / building etc

It is a lot faster to render (allowing smooth animation at greater scales) but would not work on many muds it would seem due to the overlapping.

I divide regions into sectors (16x16 chars currently) and 'stamp' the captured map portion into the sectors by calculating which sectors the data falls into by using the players position in the captured data and the character offsets.

I do store the rooms and exits in a similar manner but I did so to allow path finding and for highlighting shops etc on the map.

I opted for this approach to handle outdoor regions in the Discworld MUD which I only store sector data for as it would result in many millions of rooms and sooner or later the SQL queries would take long enough to effect gameplay.

Also because it's not possible to create a UID for all rooms in Discworld (changing descriptions, no ID's etc) I have to track the players relative position from their start point and then link my exits by using X,Y lookups to determine their ID's.

Because players can teleport to places I have to employ a complicated data stitching technique that duplicates sector data and tracks new 'sessions' so that should the new session intersect existing data, it can be stitched in and the players true position/region can then be corrected.

This results in a 'scanning' phase for the map when the player connects to the mud or the room changes without a preceding movement command (indicating some form of teleporting). Currently after 1 to 5 moves (in an already mapped location) the position is locked, otherwise it continues to build as if it were a new region until heuristic queries suggest an intersection with existing data.

So what I'll do is write a plugin using your mapper code and see if I can adopt my tracking+heuristics method to get around the lack of UID's in Discworld (and possibly other LPMuds), I really would prefer your walking method as it superbly gets around micro managing region / building changes and naturally lends itself to path finding.

The walking technique completes in (N^2 + N^2) time where as the sector approach is a lesser N^2 - so my dream of viewing the entire discworld will have to be pre-calculated one (aren't all dreams?)

One advantage of the sector approach is that you don't have to visit all rooms and indeed new room/exit records can often be determined by parsing the map data (at least in the way Discworld interior maps are structured)

I'll let you know how I get on and thanks again Nick, loved your chroma-keying tutorial by the way :) I was up for hours last night playing with blender!

The current mapper only queries for rooms as it needs them, and due to the search depth limitation, you never need to look up millions of rooms, even if they are on the database.



That is indeed your big problem, and no particular mapper will solve that. You still need to work out the uniqueness of a room, somehow.

In fact, teleporting can throw you out (you think you are somewhere, where you are not), and also illogically linked rooms (like a maze, where a room leads to itself).




Good luck with it, and yes, Blender is fun to play with. :)

Yes. I integrated lua-llthreads into the Aardwolf MUSHclient package so that I could do asynchronous socket connections.
See: http://www.mushclient.com/forum/bbshowpost.php?bbsubject_id=12520


Which is potentially bad, depending on your hardware and movement patterns. I think at some point I changed the Aardwolf mapper to prefetch the entire current area on a cache miss in a single batch request. I've also considered loading the entire DB into memory at launch (A session open long enough would get there anyway) and periodically writing changes to disk.

Ah! that's absolutely fantastic, thank you! I may not be able to render to two images simultaneously but certainly I can use that to make a number of optimizations.

I use a caching system for rooms also, the important thing being that while I could query a room as I need it, the more records that are in the table, the slower that query is. After a few weeks in a vast terrain such as the disc, the delay will start to be noticeable.

I store a text 'snapshot' of the map rather than constructing the geometry of the rooms from their links (so I can store terrain areas without creating millions of records) Due to illogical links in rooms and overlapping rooms, this requires me to create a new 'region' for entrances to structures/areas so overlapping doesn't become and issue.

On the disc this is fine as the general design is such that overlaps rarely occur.

For those rare times that they do, I still store rooms and exits which allow me to render in the classic way, I use a special character in my 'sector' data to denote cells that should be rendered in this manner, effectively allowing the best of both worlds.

I really like the work that's been done on the Aardwolf client! it's slick and well coded and I feel that such a graphical interface only serves to improve the experience.

I love the performance I've seen from the server too, 'runto' provides a rapid and smooth output on the map, something I envy as it seems I can move one cell a second on a good day in the disc ;)

I doubt I have done anything that is new to you in my work but I'll be sure to link you up when I'm finished so should there be anything you like you can use it.

You might, but you'd need to parallelize or prefetch the I/O.


That's not obviously true to me if you can only move once per second on a good day. Make sure to wrap bunches of queries in a single transaction.

Whether or not it will be useful I don't know, but it sounds like some of the approaches you're taking are definitely novel to me.

I know it seems a little odd to be worried about query times with the amount of data we're processing but I need the lowest possible latencies as I'm buffering data across frames of animation, so I need operations I can complete in the time left available in each frame. An 8ms query is no good at all if I've already spent 14ms rendering the frame - SQL won't return flow back to my code until after I needed to start rendering the next frame. it'll result in choppy framerates and poor animation.

I'm developing an image based caching system to go along with that so I can scale + blit pre-rendered blocks of data - this will allow me to divide the rendering up across a number of frames and update the main buffer when the data is ready.

This is similar caching system to things such as google maps.

And that's exactly what I'm doing and why I'm fishing for performance, I'm creating a 'continuous scale' map viewer for the Discworld MUD, smooth animation and browsing of the vast world from the top of the tree to the bottom.

It's all working very nicely at the moment, the drawing functions available inside MUSHClient combined with LUA give surprisingly good performance considering all the factors.

Lua, not LUA - it's not an acronym.

I look forwards to seeing a Vimeo video of how it all works.

Oh my apologies, just force of habit. I probably won't be making a video as I'm not the greatest speaker but I'll certainly post the work when it's complete.

I was originally going to create a DW interface to the graphical mapper built into Mudlet but it's pretty locked in and you don't have much freedom to customize.

When I've finished the design I want to move onto a 3D renderer. I've done 3D projection inside MC but the per-pixel access isn't suitable for a rasterized software renderer - only lines and pseudo spheres and I wanted to take it a lot further.

I assume that you won't be adding OpenGL if you've not done so already so I was going to create a dedicated DW client based on MC, strip the interface down and either extend it with GL functionality or write something similar to Mudlets internal mapper if I can devise a design that doesn't suck as bad.

http://postimg.org/image/srz95c497/full/ - A screenshot from a week or two ago, raw rendering, up to 55ms just to render a few thousand rooms! I've got that down to 15ms now (for the visibility of the middle image) but this is just one tiny part of the map I intend to render - hence the need for an additional layer of caching or the power of a dedicated graphics API.

Looks nice.

No I'm not planning to add OpenGL - I looked at adding TinyGL a while back, but really, in a text-based MUD game, adding 3D graphics is a bit of a distraction.