Gammon Forum : MUSHclient : Lua : Mapper! (Hehehehe.)

Register forum user name Search FAQ

Gammon Forum

Entire forum

MUSHclient

Lua

Mapper! (Hehehehe.)

Mapper! (Hehehehe.)

It is now over 60 days since the last post. This thread is closed. Refresh page

Pages: 1 2 3 4 5

Posted by

David Haley USA (3,881 posts)

Date

Reply #30 on Wed 19 Jan 2005 02:15 AM (UTC)

Message

Quote:
Like array processing in Lua?

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.

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

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. :)

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

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Faux United Kingdom (77 posts)

Date

Reply #31 on Wed 19 Jan 2005 04:16 AM (UTC)

Message

Quote:
...the order in which to render your objects...

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.

Quote:
Isometric engines...

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

Quote:
What do you mean? What I meant is that display lists save having to do e.g. trigonometric calculations...

I intend to save doing any calculation at all.

Faux, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/

Posted by

David Haley USA (3,881 posts)

Date

Reply #32 on Wed 19 Jan 2005 04:25 AM (UTC)

Message

Quote:
OpenGL provides a z buffer for a reason, y'know.

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.

Quote:
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.

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.

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

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.

Quote:
I intend to save doing any calculation at all.

That's a great intention and more power to you. :-P

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Faux United Kingdom (77 posts)

Date

Reply #33 on Wed 19 Jan 2005 11:33 PM (UTC)

Message

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. =)

Faux, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/

Posted by

David Haley USA (3,881 posts)

Date

Reply #34 on Thu 20 Jan 2005 12:24 AM (UTC)

Message

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

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. :-)

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by

Faux United Kingdom (77 posts)

Date

Reply #35 on Thu 20 Jan 2005 12:51 AM (UTC)

Amended on Thu 20 Jan 2005 12:54 AM (UTC) by Faux

Message

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?

Quote:
typically one does not implement graphics libraries in high-level (much less scripting) languages.

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

Faux, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/

Posted by

David Haley USA (3,881 posts)

Date

Reply #36 on Thu 20 Jan 2005 03:22 AM (UTC)

Message

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

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.

Quote:
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.

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?

Quote:
It did take about 45 seconds to load the data from the db though...

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Faux United Kingdom (77 posts) bio

Date

Reply #37 on Thu 20 Jan 2005 09:04 AM (UTC)

Amended on Thu 20 Jan 2005 09:10 AM (UTC) by Faux

Message

Quote:
It seems to me that the number of rooms would matter more than the number of exits...

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.

Quote:
Surely you agree that that's not a great situation to be in?

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


function rendermap()
ogl.glBegin(ogl.GL_TRIANGLES)
for i=0,1000
ogl.glVertex3f(vertex[i][0],vertex[i][1],vertex[i][2])
end
ogl.glEnd()
end

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


function mapframe:Paint(event)
rendermap()
end

Or the display list way:


function mapframe:Paint(event)
if (mapiscurrent)
ogl.glCallList(map);
else
-- Set up saving list stuff..
rendermap()
-- End saving list stuff..
ogl.glCallList(map);
mapiscurrent=true
end

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.

Quote:
Perhaps the DB API is just ... slow?

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, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/

Posted by

Lisev Poland (8 posts)

Date

Reply #38 on Thu 20 Jan 2005 03:59 PM (UTC)

Message

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

Posted by Faux United Kingdom (77 posts) bio

Date

Reply #39 on Thu 20 Jan 2005 04:14 PM (UTC)

Amended on Thu 20 Jan 2005 04:28 PM (UTC) by Faux

Message

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:

Select * from table where a=5 or a=6 or a=92 or a=288 or.. etc.

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.

Faux, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/

Posted by

Shadowfyr USA (1,786 posts)

Date

Reply #40 on Thu 20 Jan 2005 05:02 PM (UTC)

Message

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....

Posted by

Faux United Kingdom (77 posts)

Date

Reply #41 on Thu 20 Jan 2005 06:28 PM (UTC)

Message

Quote:
..since each room sits in a specific grid location..

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

Quote:
..don't generally use ODBC to operate..

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

Quote:
You might be better off finding a database...

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...

Faux, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/

Posted by

David Haley USA (3,881 posts)

Date

Reply #42 on Thu 20 Jan 2005 07:11 PM (UTC)

Message

Quote:
Static libraries are bound to be much faster.

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.

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

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.

Quote:
Without using a display list: 5025 lines.
With using a display list: ~1050 lines.

Clear winner to me.

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.)

Quote:
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?

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.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Posted by Faux United Kingdom (77 posts) bio

Date Reply #43 on Thu 20 Jan 2005 08:03 PM (UTC)

Message

Quote:
What exactly is slow?

Quote:
0.188 seconds to select
11.672 seconds to read object rows to table

Code is:


starttim=os.clock()
DBExec("select * from ObjectTbl where ZoneId = " .. param)

Note((os.clock()-starttim) .. " seconds to select")
starttim=os.clock()

t = DBRow()
ir_v = 0
while t ~= nil do
	rooms[ir_v] = t
	ir_v=ir_v+1
	t = DBRow()
end

Note((os.clock()-starttim) .. " seconds to read object rows to table")

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

Quote:
Well, they do, sort of.

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.

Faux, from Discworld. Feel free to come talk to me =)

http://faux.servebeer.com/

Posted by

David Haley USA (3,881 posts)

Date

Reply #44 on Thu 20 Jan 2005 08:18 PM (UTC)

Message

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

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.

Quote:
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])

True. That's the fault of the MUD, though, that doesn't have regularized rooms.

Quote:
Something to do with Lua isn't cleaning up properly.. I just had MUSH eating 100MB (96MB vm size) of ram.

Maybe you're not clearing references properly so that the garbage collector can do its job? *shrug*

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

137,235 views.

This is page 3, subject is 5 pages long: 1 2 3 4 5

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Comments to: Gammon Software support
Forum RSS feed ( https://gammon.com.au/rss/forum.xml )