Mapper! (Hehehehe.)

http://faux.servebeer.com/t/n.png

Edit: Non-no-ip url, if anyone else has problems. Try the other one first, though: http://fana.ssxh.net/t/n.png

100% Lua (with two extensions, LuaCOM and wxLua), reading Zugg's format.

More info when I've done more work on it :)

I'm jealous :( Any chance that we will see the source/help/whatever? I'm starting to like Lua...

Server timed out for me... couldn't see the picture. :)

BTW Poromenos, it's not in the language, it's in what you do with it. :P

------------------------
EDIT:
Ah, ok, I can see the picture now. That's pretty cool. You're not actually auto-mapping, though, are you? You're displaying a ZMUD map?

My sentences were actually separate, I meant I like lua because it's small and powerful :P

That it is indeed. Although it should be noted that to do what he did, it took two fairly large extensions; additionally, the core Lua library is missing a lot of things such as easy array manipulation (e.g. give me a copy of the array, without element x) etc.

That being said, I recently used Lua for implementing algorithms for class homework, and I'm very impressed indeed. It certainly does remove the amount of extraneous details and lets you just focus on the algorithm's internals, as opposed to the language's internals.

I agree. I haven't had time to learn it yet, but it looks great. Sure, Python can do all that too, but Python's not 100 kb, and Lua is more integrated in MC... I will have to learn it...

Nice...

Just one minor comment though. At some point it might be nice to use an OGL library or the like to create and iso-metric style map. One where going 'up' takes you to a room literally above the one you where just in. At least as an alternate display method. Even when showing non-iso, having a faded version of rooms 'under' the ones you are in would be useful, though how you deal with rooms where you climb up, wander around, then end up below again gets a bit more complicated. Maybe something that fades the last room that reconnects to 1/2 the fade of the one on the other level or something. Anyway, the point is that there are two solutions to 'levels', one is to throw out the level you just left and draw only what is on the new one, which leaves you almost as lost as before, the other is to find some way to show multiple levels at once. Possibly, with the isometric version, letting you pan and shift the camera in and out of the map (with simple zbuffer removal for part too close to the camera).

Though, just getting a mapper to work in a client that doesn't more directly support it is a feat itself anyway.

Sorry for the random ordering of replies. Hope I get everyone.

For those of you who can't be bothered to read all this..
Thanks, no source yet, almost definitely open/free source in the future.


This is contained enough to be a plugin, (excluding the sandbox and the dlls required, and their dependencies..) but things like zone selection are still being done via some (relatively nice..) aliases. I'm a newbie at wx, this is my first play, so I'm going to look into tree/list/tabstrip controls, but I won't promise anything yet.
In short: It needs some serious cleaning up, and probably an actual installer to get it going (as apposed to a plugin). I'm working on it.

---

If anyone's had any luck getting the wxLua dll to build, I'd be interested. I've managed to get the VC6 package to build, but that fails to give you a dll.
At the moment it has two major limitations, being;

• It's using outdated wx code (2.4.2)
• You can't destroy windows, meaning MUSH hangs when you update the script file.

I still can't vouch for the functional branch of programming.. or even oo, but I am starting to like languages like php above c, simply due to the raw power and stability (and common syntax).

---

A note on the extensions:
wxLua: I'd be pretty impressed if there's a better way to get dialogs going from a scripting language, excluding having a standalone executable.
LuaCOM: This is used for the DB access _alone_. No other features from it are used. If there was a MUSH way to open dbs, run queries and get their results as lua tables, LuaCOM would be obsolete.


By automapping, you mean drawing and saving to the db? No. But the infrastructure is there to captures n,s,e,w, etc. and move the map around, it's just not fully written yet.
If anyone's interested, I've stolen Tubbeh's (http://clik.to/Tubby) Map (http://users.tpg.com.au/tubbeh/Maps/DiscworldMapsv5.zip) and I'm working off that. :)


That's probably the cruddy no-ip stuff. Sorry. If it was the actual server (pretty costy dedicated.. etc.) then I'll be really.. off :p


I used to think Lua was horrid, because trying to do thigns `the php way` simply doesn't work. There are, however, most of the things there, you just have to search through the documentation (google) until you find it. eg.

• unset() becomes =nil
• =array() becomes ={}
• foreach ($a as $b => $c) becomes for b,c in pairs(a)
• etc..

Anything less syntatical I'm trying to duplicate... Here: http://www.gammon.com.au/forum/bbshowpost.php?bbsubject_id=5152


You do not want to see my code for this and how much it gets used :p


LuaOGL exists, I believe, at least under wx. I've already tried and failed to do this in flash (writing the 3d code in actionscript isn't pretty, believe me). I'm definitely going to go for this once the code becomes more smooth. I'm pretty proficient with OpenGL, but there may be someone out there who is more so.
This, however, is _not_ a priority atm.

Thanks again :)

Omg, women who program. Email me at ILoveWomenWhoProgram@poromenos.org.

Just kidding. The address is real though. And do email me.

Sorry about that, I just married two friends of mine on the MUD I play, and the silliness is still there. I'll post the URL to the log later. Or not.

Ah- sorry. :) I've known a few people who go by the name 'Faux' and all of them have been men, so that's why I assumed it was the same with you.The problem with all of these is that die-harders on every side will claim that their language is "the best". The real truth of the matter (IMHO) is that it's like a toolbox: every tool has a special purpose, and you use it when it's adequate.

You could, technically, use a screwdriver to hammer in nails (as I have done when I was sans hammer :P) but it won't work very well. Similarly, you could use OOP to write a recursive descent parser, but that'd be somewhat silly. It'd probably be just as silly to write a logic-manipulation application in C.Hehe... Indeed, it wouldn't. :P But rest assured, Lua people who go to PHP probably get frustrated by not being able to do it "the Lua way", too. :)I'm fairly handy with OpenGL; handy enough to tell you that you're better off not writing your own library, and looking for an open source one instead. Writing a 3d engine (even if it only appears as 2d) isn't a quick'n'easy thing to do. I would agree with you; this should not be a priority any time soon.I solved the problem by writing the functions with index into the array + length of the array, but my application didn't need to remove from the middle; I was just cutting the array in half recursively so it worked fairly well.


Anyhow I think you did a pretty fine job. Lua and wxLua are opening up all kinds of possibilities for MUSHclient, namely the ability to have all kinds of useful things like automapping that Nick (rightly IMHO) hasn't included in the core. :)


Edit:
Ah, yes, sometime soon I'll try building wxLua and I'll let you know how that goes.

<flame>Functional languages have no point.. etc.. etc..</flame>

And I gave up on using arrays as mappings (php arrays/whatever they're called in other languages.. perl?) and went back to the C way. Watch the functionists wince :p

I remember now.. my comments about the dll were.. inaccurate. The version I tried to build without bothering to fully read the website (http://www.luascript.thersgb.net/) I tried to build the 2.3.5 version that doesn't actually come with a require dll. I may have a go at porting at some point..

And on the OpenGL thing.. I don't know :/

Functional languages are incredibly useful in many AI applications, or to solve problems that are inherently and fundamentally recursive in nature, among other things. Of course, if you're not solving a problem for which FP is a good tool, don't expect it to be too useful. :-) A simple example - solve the Farmer-Goat-Wolf-Cabbage problem in C. Have fun... :-) A LISP solution will be simpler and shorter - mainly because you can concentrate on the functional aspects of the program, and not all these low-level details. (This is, I suppose, more of an argument for high-level languages than for FP in particular.)

PHP uses associative arrays, as far as I know. Perl has both; it has both numerical arrays and associative arrays (hash tables.) You can't really do C arrays in Lua, for the simple reason that C arrays are in fact pointers to blocks of memory that are assumed to be of a given length. In fact, few languages implement C arrays, except for those that let you do low-level manipulation as C does.

By c arrays I mean things like.. adding elements to an array by doing:

I haven't reached a stage where I've had to do anything that abstract.. yet.

I have other personal arguments against functional programming, but I refuse to post them here.

Oh, yeah, that really irritates me about Lua. Would it kill them to add things like ++ (increment) and ..= (append)? The argument is probably for more readable code, but.. isn't more readable, imho.

Hmm.. another thought on the OpenGL.. Isometric doesn't work. If isometric is what I think it is, anyway..

Terms like north (being towards the top of the screen) break down. I wouldn't write anything with north being north-east, it'd make my brain explode.

I think the best soloution would probably be to have a 60 or 30degree view, looking north, with a squished perspective. As that made no sense, I'll do a concept demo (in c (maybe with some inline asm), of course, as any other languages are far too slow to render in, properly) or a "screenshot" at some point if I feel like it and I can get it looking good.

Oh... err.. isn't that how you're supposed to do it in Lua? Except for the arr_c++, of course, which Lua doesn't have; but Lua definitely supports that kind of notation. In Lua, arrays are simply associative arrays where the key is the index into the array.I would be very interested to know what you think. If you have the time and don't mind, I'd greatly appreciate to hear your reasons - my email is myfirstname at the-haleys.com where myfirstname is david.The FAQ covers this albeit quite poorly IMHO. http://lua-users.org/wiki/LuaFaq - search for "Why does Lua lack the += operator, etc.?" Apparently it can be implemented via extensions, and I'll probably do that at some point; just haven't gotten around to it yet.You wouldn't (or shouldn't) have to do anything like that; the graphics engine would let you handle that transparently.Sounds pretty good. The advantage to the isometric view is that it lets you see more, but it does require additional mental gymnastics. Oh, and by C, do you include C++ as languages suitable for rendering? :) If not, you should check out the OGRE3d project: www.ogre3d.org or .net, can't remember - 3d engine written in C++ that has absolutely beautiful performance.

I don't think so, but nowhere does it tell you what's right and what's wrong, so..
I think `the lua way` to do it is to repeatedly call , so you have absolutely no idea at what position you are in the array, and then, if you need to itterate the array, use the `foreach` syntax:


Afaict, Lua Cheia doesn't implement them, so I'm guessing it's not trivial to do?


Just picking a random image off of google to check I know what isometric rendering is...:
http://www.northants.police.uk/museum_new/images/isometric.jpg
In this case, if we're going to assume that muds have square instead of diamond rooms, north is either going to have to be the 7,8,9 wall (ne) or the 11,12,13 wall (nw).
Ignore me if I've missed the definition of isometric, btw =p


I'd actually have to draw it to agree with you, but you seem pretty certain so I'll at least have a go. =)


I normally find that engines provide too many features (bloated) but not, say, just one out of however many, that I actually need. Then I get.. irate. :p</flame, again..> Although this is probably my fault for not wanting to do it the way the implementor of the engine (/language) wanted me to do things.

This part of the Lua book talks about arrays and how they think you should use them: http://www.lua.org/pil/11.1.html - You can use table.getn(array) to get the length of the array, which will either count the elements, or, if you've cached the size (using setn, or insert which updates it automatically) will retrieve that instead of counting.I think you're right, it'd have to be written as a fairly major extension, but they claim it's doable. I do really like the feature, so at some point or another I'm going to look into it.I think the convention is that up-left is 'north' so up-right is 'east', but in any case that is indeed exactly what isometric rendering is. The reason why you see more is just that the view is slightly tilted; therefore, with a camera at the same altitude, you have a larger view on the world.Well, it's definitely true that almost no matter which package you choose, there'll be stuff in it that you don't need, and it'll be missing stuff that you do need. Generally, though, it's worth it, as you can add the stuff yourself (if you really need it and have no alternative solution) without having to write a 3d engine from scratch. In the case of things like Ogre3D, writing that from scratch would be quite an amazing feat. 3d engines are... hard to write. :-) (especially if they have advanced features and the like.) Not only are the mathematics non-trivial, but even then, it's fairly easy to get the darn thing running in general, but to get it running fast... that's quite challenging. And then, to be able to have a usable engine from an API perspective... *shudder* :P

Things like.. say..

or



I found a page somewhere where someone had written source patches to allow things like, say, 0x000000 for numbers.

Oh, there it is: http://lua-users.org/wiki/PeterShook

Eeew, source patches.


Exactly what makes my brain ache. =/


Not quite, but then I suppose you count engines I've written myself as cheating. :p

Hmm.. saying that it's quite possible that Strike2 could work for this. *thinks*

Definitely not the first... why not just:
Yes, I agree, I'd rather stick away from source patches as well... but, well, sometimes you have to do what you have to do. :-)Yes, I meant packages you download off the net. :)Never heard of it... what kind of engine is it? You don't need a 3d engine per se, there are lots of engines specifically meant for isometric display. Those would be better, I think, but they're also much harder to find these days. :/

Crystal Space has a isometric engine I believe. Erm, actually, looks like they got rid of it.

Theres some other open source solutions (Irrlicht has a tutorial for isometrics, for instance http://www.saigumi.net/archives/000067.html).

None of which are in Lua though, but thats not too terribly important.

I don't believe you could write a sufficiently rapid 2d/3d engine in Lua, anyhow. Besides, it would have to talk to C/C++ anyway, because how else will you interface with the underlying graphics library?

It's a game engine on which some other projects are based upon. And no, you won't find it. But it's my work, so if I want to use it for this.. :)


It wasn't an actual example, but it shows why (what I see as) the native lua way isn't necessarily (<-- important word) the best.


(Yes, I know that's a self quote :p)
Hmmmmmmm.
It's just occoured to me that `rex` isn't a part of Lua. Do all of the rest of the Luacheaieaieaie features exist? I've heard vauge mention of sockets somewhere, and some variables like `bit` exist.
I'm aware that it could be a loadlib extension, but I don't see the dll, and I'm too lazy to browse a disassembly of Mush. As we're speaking in Mush, what would there be to stop there being an even more customised version?
Apart from the fact that the idea is silly, and that it's Wrong not to contribute to the community (should any of us be good enough to do it, that is).


Soo.. who wants to port the entire x lines of c++ code in Crystalspace/[name of other engine] to Lua?


Possible solution: Display lists.
If you aren't familiar with display lists, note that in a typed language (c) mmatrix is a (float *), map is an (int), and that player is a Lua array of integers/floats.
This is possibly oversimplified, but.. don't think so.

Ah- I was wondering why I hadn't found it on Google. :)
Thing is, I don't think that's the "native Lua way" for handling arrays. It's more the way for handling bags (sets if you prefer), not arrays.I didn't think you needed any special DLLs except fo rthe exception you're aiming to load.You wouldn't have to port the whole thing, just enough to make a Lua bridge to it and load it as an extension.AFAIK, it would not be possible to store the entire map in a display list, for a variety of reasons; for starters, it's far too big. Second, every time you changed the map you would have to recompute the display list. Display lists are meant for smaller objects that change infrequently, not large objects, or objects that change frequently.

I suppose that, come to think of it, for the purposes of what we're doing, we don't need a terribly fast engine. We won't, after all, be doing much computation (as is required for animation, all kinds of texture/lighting effects, etc.) All we need to do is display squares, exits and the like. The fanciest effect, AFAICS, will be translucent textures to represent altitude. So, the Lua speed issue is actually somewhat of a non-issue, for these particular purposes.

Yeah, we'd merely need a go between between a program that does what we need and lua.

However, I think I've found a better way. Googling either Isometric or Orthogonal (and Lua, obviously) turns up some interesting things.

LuaMat.
http://www.op-fx.com/luamat/

Or... well, this really isnt too relevent at the moment... but it does offer some interesting complete frontends...
http://h-world.simugraph.com/

You can look for more, I will be doing the same. This is just the first few things that came up relevantly. The latter one is a bit over the top. But would accomplish the task. Well, it looks like it. I haven't actually looked at the interface or anything like that.
The former does look promising, again, I haven't checked out interface or anything like that either. But it does appear to be an engine of some relevance.

Hmm, I thought putting big models in a display list was the point. I've put, say, 2 million triangles (1kx1k grid) in one before, how it affects the performance, from c, I'm not sure.


When would we be changing the map? (changing as in modifying, not as in switching to a different map).





It still ain't going to be me porting it :)


Exception.. extension?
True. I was assuming LuaCheia was an extension, although that seems unlikely.


Type the right thing in and, not only do you find it, you get a googlewhack ;p

Yes and no. Display lists are meant to save expensive calculations, such as a series of matrix manipulations or other mathematics. They also save (to some extent, and depending on the implementation) having to move the information to the graphics card. That being said, read this from the OpenGL 'Red Book':http://fly.cc.fer.hr/~unreal/theredbook/chapter04.htmlWell, if you're automapping, you would be updating the map every time you entered a new room.It's not quite that simple. :-) You have to only reveal certain parts of the map, so you can't just plop the whole display list in. (Another reason incidentally why you don't want the whole "floor" as a display list.)A Googlewhack? :) I'm curious, then, what is the 'right' thing? :P

It is if I don't have to show anyone the code. (Hehehehe.) :P


(Hehehehe.) :P


Like array processing in Lua?


Push it to a list every 5/10/20/50/ rooms?

---

---

Flannel, I'm liking the look of: http://doris.sourceforge.net/

Also, sometimes it may be necessary to manually edit the map or move rooms around. A lot of muds intentionally make mapping complicated and even if your mapper comes 'close' to working, some adjustment may be needed to tell it (Room 3 and Room 53 are the same room) and adjust the entire maps layout to account for it.

Come to think of it, I wouldn't want to be editing in 3d anyway.

What do you mean? What I meant is that display lists save having to do e.g. trigonometric calculations every single time (see the example in the OpenGL Red Book.But if you do that, what good will a display list be? Because then you'll have a display list for all the map but the rooms you haven't put onto the list. And then you'll have all sorts of interesting problems, like the order in which to render your objects - what if your display list draws a room, then another room in front of that room, but then your non-listed room has to be between those? You've made yourself an unsolvable problem. :)Isometric engines don't really need a full 3d engine, it's overkill. All you need is to be able to draw squares (or hexagons/octagons/whatever) at an angle, and to be able to blur out (render translucent, actually) certain portions of the map as you draw.

OpenGL provides a z buffer for a reason, y'know.
Plus this is no different from the non-display-list method. Zugg's format is a.. erm.. linked mesh. Z-sorting of it still wouldn't be trivial.


Sorry, I still can't see an isometric engine working for something where north is #8 on my keypad. =)


I intend to save doing any calculation at all.

Well, yes, you can use the depth buffer, but that's just that many more operations for each pixel drawn. Unless you have a really good reason for it (and I suppose simplicity is a good reason as long as you know you're sacrificing speed), it's better to simply render in order of distance.Things get a little complicated when you start rendering multiple floors, but other than that I'm not sure why it would be non-trivial.I guess that's just a matter of preference, then. :) I've gotten used to it, and as long as I know I'm looking at something isometric, it doesn't bother me to have the directions slightly skewed.That's a great intention and more power to you. :-P

Ksilyan, I think you simply fail to appreciate how long doing array operations on, say, 10,000 element arrays takes in Lua.

It doens't matter how slow the Z-Buffer is (on modern cards it's going to be hardware anyway, so it matters not), it's still going to be faster than drawing yourself.

Once I'm a bit more up-to-date on some coursework I may actually do a benchmark. =)

I never said Lua was fast. :) I made a guess that it would probably be fast enough for the kind of processing needed to draw a very simple isometric map, if the calculations are done cleverly.

Where are we getting 10,000 elements? And what kind of operations are you talking about? Besides, this is one of the reasons why typically one does not implement graphics libraries in high-level (much less scripting) languages. :-)

The `exits` table in that database that I'm using is 45163 records. And that's only one of the tables I'm drawing on from the db.

I'm, of course, not reading them all at the same time.

One of the zone's I'm reading (the reason I was just about to post anyway) uses 4609 of these.

See the scale I'm (we're) up against now?


Using the display list method, once we've crossed the initial barrier (see the time below *wince*), there is nothing done in the scripting language, so the speed of the script interpreter doesn't matter.

---

---

Anyway, the reason I was just about to post is that Tubby has managed to draw this map (in zMud) that the Zugg's Mapper can't actually render. *snickers*

Even if it had managed to render it without running out of resources, it would still have been 20,000x16,000ish (pixels). *snicker*

My engine, of course, had no problems drawing it, however, with a slight modification giving 1/25th scale. No loss of detail, though =)

It did take about 45seconds to load the data from the db though... I haven't run any profiling on the code yet, so I'm not sure if this is access, luacom, lua itself or my post processing.

I don't remember, but I think zMud adds a significant pause while it loads the db. Wonder if LuaSQL is any faster (assuming MDAC is the delay)?

So we're already better, before we even delve into 3d. =D

It seems to me that the number of rooms would matter more than the number of exits; at load, you would determine the layout of the rooms on the map (i.e. their coordinates), and then you no longer (really) need to care about exits.
Here's one problem with your display list method. If you ever need to add or move a room, or exits, you'll have to recalculate the whole display list. Surely you agree that that's not a great situation to be in?That seems unreasonably high... 3d games can load massive meshes in much less time. I wonder why it takes so long to load from the DB. Perhaps the DB API is just ... slow? Or maybe you're not reading optimally? Or perhaps the format itself is not a good format.

I still need an array of all of the exits to be able to draw the map...

Even if I was to save the exits in the rooms themselves, I'd still needed to to have selected all of the exits from the DB.



Think about it this way. We have this function here, rendermap, which does the raw rendering:


Our options for the main function in the render loop:
Either the non-display-list-way:

Or the display list way:


Afair setting up display lists is pretty fast, so.. if we change the map once every.. 5 frames, say? (Maybe 4 times a second.. 20 times a second.. ), by lines of code executed, 5 frames (with a change half way through):
Without using a display list: 5025 lines.
With using a display list: ~1050 lines.

Clear winner to me.


I think I have some free time booked up for friday afternoon, I'll have a look ;p


Edit: Grr, perhaps [] weren't the best choice for a forum dealing with c-type languges...

Faux: when do you expect to finish? I'd love to see your working mapper :P (as i tried to do it myself couple of times with crappy results :P )

lisev

Lisev, one of the main problems atm being what I'm playing with :)
Another being that there's no automapping.

---

0.015 seconds to process adolua.lua
0.016 seconds to open db
0.188 seconds to select
11.672 seconds to read object rows to table
63.625 seconds to do the room table, including multiple selects
0.015 seconds to index

Yeah, you can read. 45s must have been at a lower load on my system. (spec. at bottom).

Trying to do the heavy step without one select/room hung something pretty seriously. Maybe someone better at microsoft-sql could tell me a better way to do:
The other step ("only" 2183 records), however, is scarily slow. I may have another google for "luamdb", or have a go at selecting only the stuff I need, as apposed to everything and then =niling it.

Any other suggestions?

---

Edit:

Loading a simpler map:

Newstyle method:
0.015 seconds to process adolua.lua
0.016 seconds to open db
0.016 seconds to select
0.375 seconds to read object rows to table
0 seconds to do the room tablet
0.656 seconds to select the exits
0 seconds to index


Oldstyle method:
0 seconds to process adolua.lua
0 seconds to open db
0.015999999999622 seconds to select
0.40599999999904 seconds to read object rows to table
1.25 seconds to do the room table, including multiple selects
0 seconds to index

Twice as fast. Pity MDAC apparently hangs with long/complex queries.

---

Athlon XP 1800, 768MB ram, 120GB hdd.. etc.
Windowx xp sp2, MDAC 2.8.

Pretty obvious why games don't generally use ODBC to operate. lol Or at least not ActiveX. You might be better off finding a database of some sort that uses a simpler query method, not requiring parsing of commands, and is statically linked. i.e. you have to supply the link info for the dll, instead of having IUnknown give you the structure. Static libraries are bound to be much faster. And of course, and even better database solution is one that stores the actually 3D 'tree', so when you request rooms, it pulls them based on 'where' they are, not what order they are stored. I have no idea if there are any free databases that can do that though. If there are not, then I also don't know enough about z-buffers and others 3D trees to know how to design one. :( But, generally using something that was not designed specifically for the task you want to achieve is not going to work too well.

Of course, designing one is a lot less complicated than it might first look, since each room sits in a specific grid location, instead of with something like meshes, where there is no clearly defined grid. The code for such a tree is bound to be simpler as a result. Though maybe not....

Wrong. Now wouldn't that make my life easy.. :)


I'm using it 'cos z- does, and I want to read it's files.

The first version was based on SQL (with php), but I realised that most poeple don't have MySQL servers running on their pcs just for the sake of it. :p


I have an sql query for exactly the rooms I want to select, that's fine, and I can select only the associated exits, that's fine.

One that's faster to access from Lua, however...

Not true in the least... static vs. dynamic linking doesn't change the cost of executing the code, it merely requires an extra loading and relocation of the dynamic library at program startup.Well, they do, sort of. You'd have to run a layout algorithm of some sort, first. But then you'd have to run that every time you added a room, so there's not much gain to it.Obviously display lists save lines of code. That wasn't what I was disputing. I was disputing the wisdom of putting the wholemap into one display list. If you're curious, look at how e.g. Coin3D (OpenInventor) handles scene caching (that is, determining when to make a display list.)What exactly is slow? The query, or getting the results from the query? DBs like Oracle or MySQL can whizz over a 'mere' 2000 elements in a table, even 5,000 or 10,000 depending on what you're doing with it, and generally the hard part is in doing something useful with the results.

I'd have to see your full query to know if it was optimized, but sometimes you just have to do slow queries... often, the blame is to be laid on not the queries but the structure of the DB yourself.

Code is:


table.insert(t.. etc. is no faster.


Not to the degree that you can store them in a map[x][y] array, with x and y being integers under the width of the map in rooms. (ie. map[1][0] being the room 1 east of map[0][0])

---

---

Something to do with Lua isn't cleaning up properly.. I just had MUSH eating 100MB (96MB vm size) of ram. That's more than Opera and WinAMP put together. *scared* :p
And it ain't wxLua, the thing that I know crashes, because it wasn't loaded.

I suspect the culprit is DBRow, more than the table manipulation. It'd surprise me if a mere 1000 inserts (or however many you said it was) took 10 seconds.True. That's the fault of the MUD, though, that doesn't have regularized rooms.Maybe you're not clearing references properly so that the garbage collector can do its job? *shrug*

Takes around 1/4th of a second on my pc.

Now.. something faster. Anyone know how to use MDAC directly, and how to build Lua interfaces? No? Thought not.. :/


The only thing I know how to clean up is the provided function to close the database connection. And that isn't it, as far as I know? We're reaching the ends of my knowledge of Lua here.

Well, if you leave global variables around, they won't be cleaned up, either. The garbage collector is fairly straightforward; if there are no references to something it gets cleaned up.

As for the table speed, I was pretty sure the table wasn't to blame. Now we just have to write better DB interfaces. :-)

I'm trawling the MDAC SDK as I write this. Wish me luck. :p

I'm thinking of a custom extension that processes everything in C (++ so it's not my fault if it leaks) and just returns a lua table. See if that'll get the speed up a bit (ie. ignoring activex).

On the cleaning up thing, I'm =nil or ={}ing everything I know about, and every time I call this lump of code MUSH's memory usage goes up by ~2MB. It definitely isn't adding anything to anything..

Realoding the script file appears to have no affect on this continued memory gobble. I have no idea how to get MUSH to re-load the dll.. I assumed reloading the scirpt did this.

Changing language, for instance, has no effect, either.

It's always the programmer's fault if it leaks, unless you're using a garbage-collecting system. :P (Even then...)

As for your memory problems, I'm not sure what the issue is. You can explicitly tell Lua to garbage collect, I think; maybe you should try that.

I am :)


I'm not writing in C++, but I am using basically an exact copy of an MSDN article, so it's still not my fault =)

---

---

Progress report:
Using ODBC I can select at a rate of about 10,000 records/second (in c). Now, how slow can the Luainterface possibly be?

I'm aware that writing this whole thing in C is cheating, but I may call it LuaODBC or something, and release it as an extension, etc. etc. :p

Well, MSDN articles don't pretend to completely manage memory, rather, they just show the concepts, so... :-)Well... I'm not sure Lua is meant to do constant bouncing back and forth. It might be faster to have an interface that returned a Lua array of results, as opposed to the common paradigm of: while (row) { ... row = getrow() }.I don't think that's cheating... in fact, it seems to me that it's what you're supposed to do with Lua: write extensions to add functionality. Lua's libraries don't claim to do much, after all, in fact they claim to do very little.

Already planned. =)



First build is going to do all of the array processing in the dll, which defeats the point of using Lua.. but I intend to generalise it at some point ;p



Theoretically the "copy from the samples directory then build it yourself" ones should build without error or leak :)

I disagree. I don't think samples are meant to be full & complete, production-ready programs. Rather, I think they're meant to show the overall guidelines, how to get something running conceptually. In fact, I tend to expect the bare minimum in terms of leaks etc. from a sample, unless it explicitly claims to be a full, complete & production-ready piece of code. But I suppose that's just a personal opinion...

But why are you taking code from the MSDN anyhow? Are you using ODBC stuff from there? And are you sure the leak is there to begin with? :)

Okay, if you want to be technically accurate it's from the MDAC SDK. :p

But yeah, I'm using code from there, because I had (and still have) absolutely no idea what ODBC is ;p


If it is, it's not my problem ;p

ODBC is a driver for accessing databases, a sort of interface that lets you run SQL queries if you will. Generally it's a PITA to program a driver much less a DBMS (underneath the driver), which is why people very rarely write their own database interfaces. Generally, the drivers work just fine... The problem is of course making sure that the database you're accessing has an intelligent design to it geared towards whatever purpose you're trying to accomplish.

*nods, pretending to understand*

And the SQL language that it uses ishorrid. :p

--- Faus thge possibly very silightly intoxicated :P

There is only one "SQL language" (modulo different standard versions); in fact, SQL stands for "Simple Query Language". There are of course various implementations of SQL that implement the standard slightly differently. Did you mean that its implementation was bad? What were you referring to?

I had a query that I was running on the MDB that was ran and returned correct results, but wasn't valid as what I'd call SQL (having used it through php/mysql), and didn't execute on my MySQL server (with an identical copy of the db). Some kind of syntax error, I don't remmeber.

I've deleted the code witht he query in, so I can't paste it to you :/

In case you hadn't guessed yet, I learn by the "duct tape" method. :p

Well, different implementations do sometimes have ever so slightly different syntax. The major SQL flavors are MySQL, Oracle and ODBC. Oracle has its own quirks as well; but generally it's not too hard to get queries working for one or the other.So you'd learn how to do it, but how do you know you're doing it the right way? :-P

..right? :p

Nah, what I meant was I learn by leeching other people's code and beating it senseless (like, stripping it from c++ to c), then duct-taping it on to my project. Normally ends up with me having a pretty good knowledge of what's going on by the end of it..
If it works, too, that's a plus. :)



And Postgres, just so you don't get eaten by trolls. :p

Ah, yes, PostgreSQL, one mustn't forget it. :-)Yes, except when it doesn't. :P

Status report:

Gaaah.

Trying to find any kind of documentation on something that can be loaded with loadlib (not loadmodule) was fun.

I have a loadbale extension.. just trying to work out how to return a table :)

http://www.lua.org/pil/25.1.html - this explains both how to retrieve and return a table from/to Lua.

So how goes Faux with you mapper project? :) Finished/gave up/still working? :)

Progress report!

Apart from being busy, I've been working on the speed.

I've re-written the way it reads the exits. For normal-ish sized maps, this has decreased the load time by a factor of about 2 -> 4, getting close to un-noticable now.

For this reason (and the fact that I can't get it to create multiple-dimension tables) I've abandoned the luadb extension, until it's necessary.

For the Big Area that I was talking about before (took, say, 60 seconds to load), the load now fails. This is possibly because of the 37,199 character sql query it tries to run. It passes actually calling the query, but the loop to read the data appears to be too mcuh for it. Just for a laugh I put the query into mysql, and that hung too, so.. I'm not aiming to fix it.

Next on the to-do list is re-building wxlua with a more up-to-date compiler and fix it a bit, allowing me to actually kill the window (and wx). Now that'd be a luxury.



Edit:
And more progress! I've managed to get wxLua to build too. New verions of compilers have given it xp skin support, and I'm now getting some very strange problems when you try to destroy the windows (as apposed to nothing happening). This may actually be a Mush thing. More after sleep.

Hello

I see that you stopped posting on forum about progress on your mapper project. I bet you are either finished or just left it as it is ;)

I both cases, would you share with what you have done?
I would be thankful if you mail me the source code. (as I couln't find your email anywhere on forum and your web page)

Lisev